All things related to multicast

[Magnus Danielson <>]

From: Marshall Eubanks 
<>
Subject: Re: MSDP Storm
Date: Thu, 18 Jan 2001 13:39:44 -0500

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

Right, and then the above text is even beyond what I anticipated.

My point is partly that this is one of those ugly things which nobody wants to
care about but everybody eventually suffers from. The WGs and ID editors
didn't caugth on why it has made a requirement to have this chapter.

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

The actual numbers should never be put into that RFC. If specific numbers are
required, then you should have a separate RFC also running as a BCP to detail
it and updates can be made according to need.

Generic filters and adaptive functions may be directly specified.

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

Like allways, picking one single number is allways a tradeoff thing.

BTW. In this case of the worm... didn't the scanner try to connect to TCP?
I mean, trying to do TCP on _ANY_ multicast address is just bound to be a
looser. A simple filter could (and should) block that.

Cheers,
Magnus