Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Methods to mitigate a flooding attack on a forwarding database

IP.com Disclosure Number: IPCOM000198812D
Original Publication Date: 2010-Aug-17
Included in the Prior Art Database: 2010-Aug-17
Document File: 2 page(s) / 172K

Publishing Venue

Motorola

Related People

Batta, Puneet: INVENTOR [+2]

Abstract

There are several hacking tools, such as void11 and mdk3 which have been built specifically for flooding the forwarding databases of networking devices. In some networks such as 802.11, this results in no new clients being able to send any packets. On wired networks this usually results in every frame to the new destinations being either flooded out of every available interface, drastically increasing network load, or resulting in dropped packets. There are also intrusion detection systems which can raise an alarm indicating the possibility that a forwarding database has been flooded (typically by looking at the rate of associations and comparing either with a configured threshold, or a historical average). However once a flood has been detected, either the system does nothing (assuming that the administrator would handle the fact that there was an alarm), or it essentially resets everything, clearing all tables, causing major disruption to the network. The methods described in this paper can be used to mitigate the effects of such a flooding attack, essentially allowing the network to heal itself, without impact legitimate clients.

This text was extracted from a Microsoft Word document.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 55% of the total text.

                   Methods to recover from a flooding attack on a forwarding database

             By Puneet Batta, Deepak Manoharan

Motorola, Inc.

Enterprise Wireless LAN

                   
ABSTRACT

There are several hacking tools, such as void11 and mdk3 which have been built specifically for flooding the forwarding databases of networking devices. These attacks typically result in disruption of service, wasted network resources and poor performance of the network.

This paper describes methods using which a system can either prevent such an attack, or automatically recover from it, essentially “self-healing” back to a normal state of operation, without impacting legitimate clients on the network.

 

                    PROBLEM

In some communication networks such as 802.11 an association flood attack results in no new clients being able to join the network or send any packets. On wired networks such attacks on ethernet switches usually result in every frame to the new destinations being either flooded out of every available interface, drastically increasing network load, and dropped packets.

 
Some intrusion detection systems can raise an alarm indicating the possibility that a forwarding database has been flooded (typically by looking at the rate of new entries being created and comparing either with a configured threshold, or a historical average). However once a flood has been detected, either the system does nothing (assuming that the administrator would handle the fact that there was an alarm), or it essentially resets everything, clearing all tables, causing major disruption to the network.

                    SOLUTION

This paper proposes five different techniques that can be used to prevent such an attack, or to recover from one. Some of the methods are protocol specific (applicable largely to 802.11 WLAN systems) while others are generic enough to be used in general networking devices.

1. Lowering the age-out interval of the FDB (forwarding database) entries after a flood: the typical age-out interval of forwarding database depends on the type of network and the topology. It can be anywhere from under a minute, to typically 30 minutes in wireless networks. When a flooding attack is detected, if the system would automatically change the timeout to a small value (60 seconds from 30 minutes) then the rogue entries (since they dont represent real data) would typically clear out on its own.

2. Attempting an identification exchange with...