Subject: Re: MSDP Storm

From: Marshall Eubanks <[email-masked]>
Date: Thu, 18 Jan 2001 13:39:44 -0500

Magnus Danielson wrote:

> From: Bill Nickless <[email-masked]>
> 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 : [email-masked]     [email-masked]

http://www.on-the-i.com http://www.buzzwaves.com

---

From: Magnus Danielson <[email-masked]>
Date: Fri, 19 Jan 2001 13:54:39 +0100

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

> Section 19 of the MSDP draft is typical :

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.

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

> 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

---

From: Magnus Danielson <[email-masked]>
Date: Fri, 19 Jan 2001 17:30:18 +0100

From: Marshall Eubanks <[email-masked]>
Subject: Re: MSDP Storm
Date: Fri, 19 Jan 2001 10:00:33 -0500

> Hello Magnus;

Dear Marshall,

> Correct, although a mboned BCP might not be a bad idea.

IMHO Mboned is the correct IETF WG for such a BCP. I just didn't imply the WG
to do the BCP in question.

Cheers,
Magnus

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 19 Jan 2001 10:00:33 -0500

Hello Magnus;

> looser. A simple filter could (and should) block that.

I do not know, but this is a good point. I can see no reason not to
filter TCP.

-- 

                                   Regards
                                   Marshall Eubanks

   Multicast Technologies, Inc.
   10301 Democracy Lane, Suite 201
   Fairfax, Virginia 22030
   Phone : 703-293-9624          Fax     : 703-293-9609     
   e-mail : [email-masked]     http://www.on-the-i.com

---

From: Jared Mauch <[email-masked]>
Date: Fri, 19 Jan 2001 10:55:29 -0500

On Fri, Jan 19, 2001 at 10:50:15AM -0500, Marshall Eubanks wrote:
> Dear Magnus;
> My guess is that the numbers will be the hard part. It is easy, after
> all,  to say
> 
> MSDP neighbors SHALL limit the number of Session Announcements flooded out.
> 
> But it is not transparent (to me, at least) what that limit should be.
> Most people running a RP with MSDP will want guidance as to what limit
> should be
> used and/or what limits are reasonable. The same can be said for IGMP
> and PIM.
	
	Rate-limiting MSDP messages or doing a per-peer SA limit
would be good.. Similar to the way we in the operational world can limit
the number of prefixes received, we should be able to limit the maximum
number of SA's that we receive from a peer.

	I can determine that currently there are about 1200 SA's
so I can limit each of my eMSDP peers to have only 1200 SA's from them
to avoid the 12k SA's I was seeing earlier this week from port scans
of 227/8

	- Jared

-- 
Jared Mauch  | pgp key available via finger from [email-masked]
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.
END OF LINE  | Manager of IP networks built within my own home

---

From: Jon Crowcroft <[email-masked]>
Date: Fri, 19 Jan 2001 15:36:06 +0000

>>to do the BCP in question.

non serious:

until we get bidir pim and v6 and remove the need for msdp, best
common practice, at least according to many (but not all) ISPs, 
outside of shared media domains (lans,
wireless, satellite, pure optical cores), appears to be not to use multicast :-)

aside:

would be neat if someone wrote an RTSP/IGMP gateway...

 cheers

   jon

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 19 Jan 2001 10:50:15 -0500

Dear Magnus;

-- 

                                   Regards
                                   Marshall Eubanks

---

From: Magnus Danielson <[email-masked]>
Date: Fri, 19 Jan 2001 17:47:17 +0100

From: Jon Crowcroft <[email-masked]>
Subject: Re: MSDP Storm
Date: Fri, 19 Jan 2001 15:36:06 +0000

Jon,

> wireless, satellite, pure optical cores), appears to be not to use multicast :-)

Certainly, certainly... why in the heavens would such a complex system which is
potentially hitting on all core routes while having most questionable user
implications be deployed?

Serious side:

If more people knew about it and actually used it, we just might have better
a better situation. Dreams, dreams, dreams...

> would be neat if someone wrote an RTSP/IGMP gateway...

Do you volonteer?

(Allways ask someone who proposes some work ;)

Cheers,
Magnus

---

From: Philip Pishioneri <[email-masked]>
Date: Fri, 19 Jan 2001 11:19:19 -0500

> number of SA's that we receive from a peer.

Since my site is on an edge, we get most MSDP messages from one peer, so
that type of limit wouldn't help as much.

How about maximums based on AS and/or net/mask?

-Phil

---

From: Chris Wedgwood <[email-masked]>
Date: Sat, 20 Jan 2001 19:59:50 +1300

On Fri, Jan 19, 2001 at 03:36:06PM +0000, Jon Crowcroft wrote:

CacheFlow have somethuing like this in their media streaming code I
think.

  --cw

---

From: Magnus Danielson <[email-masked]>
Date: Mon, 22 Jan 2001 10:14:05 +0100

From: Marshall Eubanks <[email-masked]>
Subject: Re: MSDP Storm
Date: Fri, 19 Jan 2001 10:50:15 -0500

Dear Marshall,

> MSDP neighbors SHALL limit the number of Session Announcements flooded out.

Right, please note what I said above... "If specific number 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.", that is IF we find it necessary.
Also, since those numbers would be a Best Current Practice, we say that they
are open for changes if the best current practice changes.

Your wording above is correct for the MSDP ID/RFC regardless weither there are
an BCP or not.

Further, I rather propose a dynamic method in which you look back at running
statistics of say 60 days and only accept say an excess of 10 % over the
extrapolated curve. Something like that. The exact details we can work out, but
the need to change numbers becomes far less and the method may be better suited
to survive time and exponential growth if the statistical analysis and
extrapolation is well selected. In addition to this you could have a hard
limit as an option, but I think doing something like this limits the excess in
relation to what the box should expect to handle as a normal case.

> used and/or what limits are reasonable. The same can be said for IGMP

Certainly. I dont like hard limits like those, they are very coarse means of
control and needs attention to keep handling the normal case. Thus, a too
tight limit may hurt your normal buissness and require manual update on a
regular basis. Better to find a suitable method of doing this by automatic
means if we could do so.

We can however consider to standardize filters such as proposed. However, we
should be carefull not to bite our fannies or get our squeeker dysfunctional
since rate-limiting a single box at IGMP level could work against the intended
working if that box happends to be a application gateway or playback server.
There are a few notable applications which could generate many legal IGMP
joins.

Cheers,
Magnus