All things related to multicast

[Bill Nickless <>]

-----BEGIN PGP SIGNED MESSAGE-----


>It's actually pretty easy to simulate. Grab a copy of hping2, and fire off 
>a SYN packet to the FTP port of an arbitrary multicast address - that's 
>more or less what synscan is doing.
>Piece of cake. And of course that's a Really Bad Thing. . .

I agree, and posted these two notes to the MSDP working group a short time 
ago:

>Date: Wed, 03 Jan 2001 17:39:34 -0600
>To: Beau Williamson 
><>
>From: Bill Nickless 
><>
>Subject: Re: MSDP SA mandatory caching
>Cc: 
>
>Sender: 
>
>Precedence: bulk
>X-Archive: ftp://ns.uoregon.edu/mailing-lists/msdp.archive
>X-Subscribe: 
>
>X-Unsubscribe: 
>
>
>
>At 04:32 PM 1/3/2001 -0800, Beau Williamson wrote:
> >I think we can make the argument that the amount of state that needs to be
> >stored will continue to be well below any problem levels.  This is
> >particularly true if you consider the effects of SSM deployment which will
> >not require MSDP.
>
>I will agree with you, if you add the word 'legitimate' before the word
>'state.'
>
>Consider this theoretical denial of service attack.
>
>A legitimately configured, but compromised source S transmits a handful of
>bogus (but properly formed) packets on many groups, (224.0.1.0),
>(224.0.1.1), .... (224.0.1.255), ... (224.0.2.255), ... ( 224.0.255.255),
>... ( 224.1.255.255), .. (224.255.255.255), and so on.
>
>Each handful of packets causes PIM-SM state in the local DR to be created,
>and an MSDP SA to be generated at the RP.
>
>Just in the 224.0.0.0/8 address space I see 24 bits of potential groups,
>which implies roughly 16 million MSDP SAs that could be generated by a
>single source.  That assumes, of course, that a single source can transmit
>on all its illegitimate groups often enough to refresh each MSDP SA before
>it times out.  It also assumes that the site where the attack is launched
>can support a dangerous number of (S,G)s in the DR and RP.
>
>As we've seen, DoS attacks can be launched from dozens or hundreds of
>possibly (otherwise) legitimate sources, distributed across many
>sites.  Plus, a compromised host could potentially forge (S,G) packets
>where S is all legitimate addresses on its local subnet.
>
>(No, I haven't yet written the few-dozen lines of Perl code to try this,
>mostly because I haven't had time to set up a couple of MSDP speakers in an
>isolated test network.)
>
>I submit that an MSDP implementation that isn't caching SAs is immune from
>memory exhaustion under such an attack.  An MSDP implementation with a
>limited cache size, not following the old RPF rules, will end up flooding
>the bogus SAs that it receives from all of its peers that don't make it
>into the cache.

And in response to another comment shortly thereafter:

>Message-Id: 
><4.3.2.7.2.20010103182256.0297aae8@localhost>
>Date: Wed, 03 Jan 2001 18:34:18 -0600
>To: Beau Williamson 
><>
>From: Bill Nickless 
><>
>Subject: Re: MSDP SA mandatory caching
>Cc: 
>
>Sender: 
>
>Precedence: bulk
>X-Archive: ftp://ns.uoregon.edu/mailing-lists/msdp.archive
>X-Subscribe: 
>
>X-Unsubscribe: 
>
>
>At 06:17 PM 1/3/2001 -0800, Beau Williamson wrote:
> >Bill,
> >
> >These DoS attacks are not just a problem for MSDP.  They need to be
> >addressed at another level that solves both the MSDP SA state DoS problem
> >as well as general router state in the network.  For example, this can
> >also affect SSM in the same way.
> >
> >Don't get me wrong, I think you have a valid concern re:SA
> >State.  However, I don't think it is any bigger problem for MSDP as it is
> >for other aspects of multicast in general.
>
>The unique vulnerability of MSDP, as I see it, is that a single
>unprivileged user of any host on an MSDP-enabled network can generate
>virtually unlimited amounts of global state.  (That is, the globally cached
>MSDP SAs.)
>
>Contrast that with a miscreant trying to inject lots of bogus BGP routes
>into global state.  There, it requires a misconfigured router at the edge
>of an Autonomous System.  Even then, there are mechanisms in place to
>dampen this.  (prefix filters, as-path length comparisons, routing
>registries, etc.)
>
>I was going to argue that SSM is invulnerable to this class of attack,
>until I realized that a bad guy could send lots of (s,g) joins towards
>bogus sender addresses, again creating lots of state in the intervening
>networks towards the bogus address.
>
> >My point is that in order to solve the problems we are seeing now wrt SA
> >storms, it is necessary for the routers to use the SA-Hold-Down-Timer
> >function.  This in turn effectively requires you to maintain SA state. So
> >if you agree that the SA storm problem must be fixed, then we have to
> >maintain SA state.  (If you don't believe that we have a real problem with
> >MSDP SA Storms, hopefully some others on the list will chime in and relate
> >some of the issues we have had recently.)
>
>I completely agree: let's fix the problems we're seeing now.  You have my
>full support, and I truly believe that fixing the problems people are
>suffering from is the best way to move forward.

===
Bill Nickless    http://www.mcs.anl.gov/people/nickless      +1 630 252 7390
PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7     


-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>

iQCVAwUBOmYjC6wgm7ipJDXBAQGyoAQAg88qW0UCqOSoZWvVfN8O0kqZNzLZSUqi
WJavMPxd50KiOpv1MU/0XwigTR/GUoIlW/kLiMapskY4Cojk16cX5ofB88YcfikN
Ax1I0uCHx4iFmiuzLmJxdvt+4bRMCnLTO2oT9/pFe+1aFLIAOVGnwlvqYjTmU8n+
7i6hOOdOeX8=
=tFRM
-----END PGP SIGNATURE-----