All things related to multicast

[Marshall Eubanks <>]

The limits were elaborated on in IETF 51

http://www.multicasttech.com/papers/ietf_51_mboned_tme.pdf.gz
http://www.multicasttech.com/papers/ietf_51_mboned_tme.ppt.gz

Marshall

On Monday, February 10, 2003, at 01:47 PM, Marshall Eubanks wrote:

> 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