All things related to multicast

[Marshall Eubanks <>]

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