All things related to multicast

["Mike Luby" <>]

Hi Marshall,

I agree with what you say below, thanks for clarifying. I would only add
that once I thought about it a bit more I would be happy if the first
requirement, i.e., SPECIFIC receiver trying to join a SPECIFIC (S,G), was
rate limited at even once per something like 10 seconds, so your once per
second suggested restriction is more than ok.

Michael Luby

-----Original Message-----
From: Marshall Eubanks 
[mailto:]
Sent: Thursday, January 18, 2001 12:44 PM
To: Mike Luby
Cc: Magnus Danielson; 
;
 
;
;
 
;
;
 
;
 
;
;
 

Subject: Re: MSDP Storm


Hi Mike;

Mike Luby wrote:

> --
>
> <SNIP>
>
> I like:
>
> - number of joins allowed per second to a SPECIFC (S,G) from a SPECIFC
> receiver or source (at, say, 1 per second).

I was thinking of a zombie doing a DOS aimed at its first hop router. I see
no reason to sit
there and hammer away at your first hop with a join.


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

This, of course, was aimed at a SSM DOS attack.


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

I was really thinking IGMP here, not MSDP - I was thinking of a LAN with
one or more zombies on it doing a port scan or something similar. This
is what would stop the RAMEN worm attack.

I suspect that there will need to be something added to PIM as well - all
the PIM v2 revised
draft says is
------
6.  Security Considerations

All PIM control messages MAY use IPsec [6] to address security concerns.
The authentication methods are addressed in a companion document [7].
Keys may be distributed as described in [8].
------
I see  no reason a PIM router should encapulate and pass to the RP 15,000
packets,
each on a different group, from one source in a few minutes. I see no reason
why the RP should accept them.
If a RP was turned into a zombie, I see no reason why other RP's should
accept and forward
these SA's.

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

Every rate limit (IMHO) has to be PER router. Routers cannot be assumed to
know what others
are doing.


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

I did not intend a global limitation. Sorry if I was unclear.

>
>
> Mike




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