All things related to multicast

["Mike Luby" <>]

-----Original Message-----
From: 

[mailto:]On
 Behalf Of Marshall Eubanks
Sent: Thursday, January 18, 2001 10:40 AM
To: Magnus Danielson
Cc: 
;
 
;
;
 
;
;
 
;
 
;

Subject: Re: MSDP Storm


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

I like:

- 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.)

... although I would prefer in the first a fraction of a second (say 0.5)
instead of a full second, and the second is more than liberal (I can't
imagine a specific end user receiver trying to join 500 sessions per second,
but perhaps if this is an intermediate server box receiving multicast this
might make more sense).  These restrictions also make sense, since it is the
access router that will have to deal with these, i.e., one box.

I don't like:

- 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).

Why would you want to put a limit like this, since in particular
(a) This is a global restriction, and limits the scalability of SSM
(b) There is no correlation between this (what I consider artificial
restriction) and the load on any particular box in the network.  In
particular, there could be millions of clients joining a group from
different parts of the network, but these joins are being handled by routers
distributed across the entire network.  And, the load that joins to a
particular group would be spread across the entire network infrastructure,
and this requirement would be subsumed by the first two restrictions.

What I would like to see is that if there is rate limitation, then it is per
box (the first two restriction you mentioned would be of this type) and not
some artificial global restriction that couldn't be enforced (there is no
point in the network that would feel such a load in SSM, maybe this would
make more sense for ISM with the RP as the global bottleneck) and has no
correlation with overwhelming some particular part of the network.

Ok, I'm SSM biased, and I'm seeing things colored by that.  Maybe a global
limitation would make sense for ISM because of the RP, but there must not be
such a global restriction for SSM, else it defeats the attractiveness of
massive scalability.

Mike