Re: Sasser potential to cause routing problems

[Doug Pearson <dodpears () INDIANA EDU>]

A useful approach to filtering suggested on the wg-multicast () internet2 edu mailing list is to filter inbound TCP at 
edge interfaces to the address range 224.0.0.0/4 (effectively the whole multicast range 224.0.0.0 through 
239.255.255.255). Multicast does not support TCP. This filter could (should?) be added to the standard permanent 
"sanity filters" at network edges.

Regards,

Doug Pearson
Research and Education Networking ISAC
http://www.ren-isac.net
Watch Desk 24x7: +1(317)278-6630


At 01:30 PM 5/3/2004 -0500, Doug Pearson wrote:
> Internet2 Abilene engineers have reported from circumstantial evidence that it appears W32/Sasser[1] is scanning into 
> multicast address space, potentially causing problems for network routers. Within a network that supports multicast, 
> the first packet sent to a multicast address creates a Multicast Source Discovery Protocol (MSDP) state in the edge 
> (closest to source) router. The state information is passed upstream, ultimately to core backbone routers, and is 
> maintained in state tables all along the path. The Abilene network is seeing a substantial rise in MSDP state 
> information. Although Abilene routers haven't been adversely affected yet, it's possible that smaller routers, e.g. 
> campus systems and backbones, could see adverse affects from increased CPU utilization and memory allocation, e.g. 
> difficulty in maintain routing states, unresponsive terminal and SNMP, crash/hang, etc.
>
> Once MSDP state has been created at the edge there's no way for upstream routers to discriminate between good and bad 
> state information. For networks running multicast, high CPU utilization and the size of the MSDP state table are 
> problem indicators. When routing stability is threatened, options for remedy are cumbersome and service affecting: (1) 
> filter inbound 445/tcp at all router edge interfaces that face sources of worm scanning; (2) limit the amount of MSDP 
> state that can be received from downstream; and (3) turn off multicast. And of course there's always option 4 - get 
> those infected hosts cleaned.
>
> At least one major US university reports having turned multicast off. The worm scanning into multicast space and the 
> resulting growth of MSDP state was causing route stability problems due to memory allocation.
>
> Regards,
>
> Doug Pearson
> Research and Education Networking ISAC
> http://www.ren-isac.net
> Watch Desk 24x7: +1(317)278-6630
>
> **********
> Participation and subscription information for this EDUCAUSE Discussion Group discussion list can be found at 
> http://www.educause.edu/cg/.

--

Doug Pearson; Indiana University; dodpears () indiana edu
Phone: 812-855-3846; ViDeNet: 0018128553846
PGP: http://mypage.iu.edu/~dodpears/dodpears_pubkey.asc

**********
Participation and subscription information for this EDUCAUSE Discussion Group discussion list can be found at 
http://www.educause.edu/cg/.