[AG-TECH] this week's multicast fun ('ramen' and MSDP SA storms)

[Lisa Childers]

Tony,

Thanks so much for this writeup!  Its very helpful to have this background
information.

Lisa

-----Original Message-----
From: owner-ag-tech at mcs.anl.gov [mailto:owner-ag-tech at mcs.anl.gov]On
Behalf Of Tony Rimovsky
Sent: Thursday, January 18, 2001 9:28 AM
To: ag-tech at mcs.anl.gov
Cc: jeffr at ncsa.uiuc.edu
Subject: [AG-TECH] this week's multicast fun ('ramen' and MSDP SA
storms)


[anyone who has more/better information, please feel free to follow
up.  This is an attempt to explain what is going on and to give people some
context for moo discussions, etc.  Parts of it are technically simplified
because I don't really want to try and give a detailed description of some
of the routing details right now.]

This past weekend, a new toolkit for breaking into linux hosts emerged.
There was nothing particularly new in the kit.  However, "Ramen" uses a
port scaning tool in a way that is (probably unintentionally)causing router
problems.  This has reportedly been disrupting service at several I2
campuses as well as the Abilene network.

Ramen's port scanner is fed addresses from a program that randomly
generates a sequential list of addresses.  The goal is to quickly connect
to this random list of addresses to find vulnerable ftp servers.

The interesting bit is that the address generator considers some portion of
the multicast address space when it makes its selection.  When multicast
address space is used, the port scanner rapidly sends packets to a list of
multicast (or group) addresses, just like it would any list of unicast
destinations.

The current multicast routing infrastructure uses a protocol called MSDP to
share information about what sources are using which multicast
groups.  This is done by sending 'source-active' or SA messages between
routers.  MDSP participating routers are generally configured to pay
attention to each SA it receives and to cache the results in memory.

When the ramen port scanner starts going through multicast address space, a
new SA is generated for each address in the list.  The result is a table
maintained in the routers that looks something like the following:

         (source address, multicast group address)
         (171.64.48.112, 237.64.120.187)
         (171.64.48.112, 237.64.120.188)
         (171.64.48.112, 237.64.120.189)
         (171.64.48.112, 237.64.120.190)
         (171.64.48.112, 237.64.120.191)

When ramen first appeared over the weekend, Abilene reported seeing about
50,000 SA's in about 5 minutes time.  That was done by only two compromised
hosts at one site.  That load is continuing to cause problems on many of
the routers involved in the access-grid project, including the Abilene
core.  The problem is compounded by the fact that ramen is actually a worm,
and an increasing number of compromised hosts are running the same programs.

Vendors are starting to come out with some band-aids for this, but this
issue may persist for a while as folks start to deal with MSDP scaling
issues that this has forced to the front burner.

You can see plots showing the huge jumps in the number of active multicast
groups corresponding with this at:
http://www.caida.org/tools/measurement/Mantra/session-mon/session-mon.html