Re: Rate limiting UDP,Multicast,ICMP

[Hank Nussbacher <hank () att net il>]

At 14:12 13/11/01 -0500, Robert Beverly wrote:

Due to Ramen I was forced to rate limit msdp as follows:

interface Tunnel2
 ip pim bsr-border
 ip pim sparse-mode
 rate-limit input access-group 180 32000 8000 8000 conform-action transmit 
exceed-action drop
 ip sap listen
!
access-list 180 permit tcp any any eq 639
access-list 180 permit udp any any eq 639

and:
ip msdp sa-filter in n.n.n.n list 111
access-list 111 deny   ip any host 224.0.2.2
access-list 111 deny   ip any host 224.0.1.3
access-list 111 deny   ip any host 224.0.1.24
access-list 111 deny   ip any host 224.0.1.22
access-list 111 deny   ip any host 224.0.1.2
access-list 111 deny   ip any host 224.0.1.35
access-list 111 deny   ip any host 224.0.1.60
access-list 111 deny   ip any host 224.0.1.39
access-list 111 deny   ip any host 224.0.1.40
access-list 111 deny   ip any 239.0.0.0 0.255.255.255
access-list 111 deny   ip 10.0.0.0 0.255.255.255 any
access-list 111 deny   ip 127.0.0.0 0.255.255.255 any
access-list 111 deny   ip 172.16.0.0 0.15.255.255 any
access-list 111 deny   ip 192.168.0.0 0.0.255.255 any
access-list 111 permit ip any any

-Hank

> Rate limiting multicast packets would not have prevented state from
> being instantiated, nor would it have prevented the MSDP SA flooding
> that ensued from this worm.  Some vendors provide facilities to
> rate limit MSDP SA messages (actually rate limiting traffic to the
> MSDP port 639).
>
> On Tue, Nov 13, 2001 at 06:37:41PM +0100, Niels Bakker wrote:
> > I'm sure that the operators of the networks that were massively hindered
> > when some worms started scanning random hosts in 224/4 (that's what you
> > get if you don't understand IP and just use a random number generator to
> > get something resembling an IP address) were rate-limiting packets to
> > multicast addresses pretty quickly.  All those new sessions (one UDP
> > packet to a multicast address) created state in lots of routers
> > throughout their networks.  Dropping TCP to 224/4 of course also helps
> > in this particular case.