All things related to multicast

[Marshall Eubanks <>]

Magnus Danielson wrote:

> From: Bill Nickless 
> <>
> Subject: Re: MSDP Storm
> Date: Wed, 17 Jan 2001 18:11:05 -0600
>
> > >BUT, it seems to me that at base this is not a MSDP issue - it is an IGMP
> > >issue. Wouldn't it make more sense (although, alas, more work) to rate
> > >limit IGMP joins ?
> >
> > Good question.
> >
> > I agree with Dave Meyer's comment, that the general problem is a lack of
> > rate limiting on routing protocols subject to flooding, including
> > MSDP.  Should we include IGMP in this list of protocols that should be 
> > rate
> > limitable?  I'm not sure.
>
> I think you really should do plumbing in both IGMP and MSDP in this case.
> If the IGMP plumbing fail (intentionally or unintentionally disabled/broken)
> on one box, then you need the plumbing in MSDP anyway. The MSDP saves your
> network and whoever is behind that... IGMP plumbing is just the "first wave"
> wall. If that falls, the network would fall, that's why MSDP also needs
> attention.
>
> Rate-limiting is just one of many tools.
>
> This is really why there is a Security section in them RFCs. We really 
> should
> consider putting some standard plumbing in there...
>
> Cheers,
> Magnus

I would agree. Mischievously, I would point out that there is an IGMP v3 RFC 
grinding along :
 <draft-ietf-idmr-igmp-v3-05.txt>
AND a MSDP draft grinding along as well :
<draft-ietf-msdp-spec-06.txt>

Section 19 of the MSDP draft is typical :
---------------------------------
19. Security Considerations

   An MSDP implementation MAY use IPsec [RFC1825] or keyed MD5 [RFC1828]
   to secure control messages. When encapsulating SA data in GRE,
   security should be relatively similar to security in a normal IPv4
   network, as routing using GRE follows the same routing that IPv4 uses
   natively. Route filtering will remain unchanged. However packet
   filtering at a firewall requires either that a firewall look inside
   the GRE packet or that the filtering is done on the GRE tunnel
   endpoints. In those environments in which this is considered to be a
   security issue it may be desirable to terminate the tunnel at the
   firewall.

---------------------------------
There is NOTHING in either draft about limiting DOS type attacks.

Just to throw out a specific suggestion : wouldn't it make sense to include 
SHOULDS (at least) about rate limiting
- number of joins allowed per second to a SPECIFC (S,G) from a SPECIFC 
receiver or source (at, say, 1 per second).
- number of joins allowed per second (for all (S,G) from a SPECIFIC receiver 
or source)
(at, say, 500 per second, and no more than 1000 in a 10 second period.)
- total number of joins to any specific group, or any specific source (i.e., 
to a (*,G) or a (S,*)) from all attached sources / receivers
  (at, say, no more than 1000 in a ten second period).

And similar numbers for SA setups in MSDP ?

This might limit vast multiparty games or videoconferences a little, but 
would not hinder any SSM type aps I
can think of at all. The numbers I gave may be too lenient; I was just trying 
to get some thinking about this started.

--
                                 Regards
                                 Marshall Eubanks


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.on-the-i.com http://www.buzzwaves.com