All things related to multicast

[Marshall Eubanks <>]

I proposed all of this 2 years ago at the IETF, and was shot down.

http://www.multicasttech.com/papers/DOS_mboned_ietf_50.pdf.gz
or
http://www.multicasttech.com/papers/DOS_mboned_ietf_50.ppt.gz

has a fairly thorough description of the state DOS problems. (If I 
missed anything, please
let me know...)

Marshall

On Monday, February 10, 2003, at 01:12 PM, John Kristoff wrote:

> I wanted to get my thoughts from the wg meeting earlier this week into
> the archive.  It seems people were interested in these sorts of
> problems, but it wasn't entirely clear to me how important they are that
> people want to set about addressing them.
>
> The problems with MSDP state are well known and some knobs have already
> been added by vendors to reduce impact there.  However, there are also
> potential problems with IGMP and PIM state.  PIM being probably the more
> critical protocol to be concerned about initially.
>
> Within a PIM domain, an attacker or broken application could generate
> packets destined to 224/4 networks.  Presuming no PIM filters in place,
> significant PIM state could be put into PIM domain routers.  If nothing
> else, state gets setup between the first hop PIM router and the RP for
> registration messages.  If packets to these addresses are repeated or
> purposely kept active, PIM routers in between almost certainly become
> victim to state attacks as well.
>
> Note, the problem lies in the fact that end hosts can create (and
> destroy?) forwarding state in internetwork devices, something unicast
> routing does not inherently allow.  I'm ignoring layer 2 table address
> flooding on LAN bridges/switches, which is another problem.
>
> My initial thought was that knobs could be added to limit and/or rate
> limit the number of PIM registers for any unique source IP.  Timers
> could also be used to aggressively time-out state.
>
> Similarly, IGMP requests to join a group could be used to cause IGMP
> state at edge routers and possibly to cause a 'pull' flooding attack.
> Similar knobs to limit and/or rate limit IGMP messages could be used.
>
> Thoughts?
>
> John

T.M. Eubanks
Multicast Technologies, Inc
10301 Democracy Lane, Suite 410
Fairfax, Virginia 22030
Phone : 703-293-9624       Fax     : 703-293-9609
e-mail : 

http://www.multicasttech.com

Test your network for multicast :
http://www.multicasttech.com/mt/
 Status of Multicast on the Web  :
 http://www.multicasttech.com/status/index.html