Is it common practice for ISPs to rate limit UDP, Multicast and ICMP on a
customer connection to reduce the effects of various DOS attacks? On the
backbone?
TIA,
Thomas
Some providers do rate-limit ICMP at the public exchange points.
But they tend to only limit echo-request and echo-reply
unreachables, p-mtu and other fun icmp messages are not
limited by these.
I'm not aware of anyone that would limit udp traffic. As DNS
is udp, it would not be wise to rate-limit udp flows.
As far as multicast goes, I'm not aware of anyone running
native multicast that would limit the traffic. Those still using
DVMRP may have multicast rate-limits in place as to not have a massive
bandwidth sucking sound coming from their general direction.
- jared
* jared@puck.Nether.net (Jared Mauch) [Tue 13 Nov 2001, 18:11 CET]:
As far as multicast goes, I'm not aware of anyone running
native multicast that would limit the traffic. Those still using
DVMRP may have multicast rate-limits in place as to not have a massive
bandwidth sucking sound coming from their general direction.
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.
Apart from not wanting to point fingers, the names of some of these
network operators escape me at the moment too, even though I believe
they were posted here at the time.
Regards,
-- Niels.
There were a few bugs that were related
to that.
1) unices would allow tcp connections (syns) to multicast space
2) routers would create (S,G) for that, causing SA storms in MSDP
(there is now a sa-limit command so you can prevent getting these from
msdp peers)
3) some routers running MSDP would have their CPU overloaded
due to poor time managment of cpu resources.
Obvious ways to prevent that was to drop tcp to 224/4 at the edges
where it was easy. This does make sense as there is limited application
for tcp connections to 224/4.
- Jared
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).
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