[NANOG] Limiting ICMP

Hi there,

I'm wondering if anyone else has run into this/has heard of/(is responsible for)/knows the reason behind large IP providers limiting ICMP on outbound connections to the same amounts regardless of the size of the circuit?

        Apparently after one of our upstream providers switched to Juniper for some of their equipment their engineers recommended that they limit ICMP on all customer facing connections to 5mbps. I understand that preventing DDoS is important but why A) would they apply the same rule to our OC-48 that they apply to someone else's T1/DS-3 and B) why is that a requirement for Juniper gear?

(do people still DDoS with ICMP these days? I see a lot of what looks like udp.pl and hardly any ICMP attack traffic anymore)

Sorry as usual if i'm off-topic.


Drew Weaver wrote:

(do people still DDoS with ICMP these days? I see a lot of what looks like udp.pl and hardly any ICMP attack traffic anymore)

We saw a small attempted attack using ICMP a few weeks ago, but as you've mentioned I've mostly been seeing UDP floods (and the occasional TCP SYNflood still).

I do feel the need to comment that more and more lately I've been running into extremely frustrating situations where useful ICMP and UDP traffic was being filtered bidirectionally, not just rate-limited. I think my favorite incident so far of this was a host that returned an ICMP UNREACHABLE (with a "filtered" code) in response to an ECHO REQUEST to itself.



I might be partially responsible for furthering some of that activity.
I've done this sort of thing on initial ingress facing links (e.g. LAN
segments with client-oriented systems) and it was me who provided the
sample configs for the cymru junos template for limiting udp and icmp.

Perhaps I mentioned it on a mailing list or in some internal documentation
somewhere, but the way I've done it is typically to limit those two IP
protocols (and sometimes other things like multicast) to some fraction
of a percent on a edge LAN ingress link speed, which is not in the
template. Egress, aggregate and peering/Internet facing links shouldn't
have these limits (yes, kind of a pain to manage if you're not good at
router config management). Unfortunately I didn't provide all that
detail to the cymru folks at the time and as I'm sure they are aware
those templates are quite a bit outdated now and could easily take some
heavy revisioning.

In the environments where I've done this, my experience was that it was
an acceptable practice at the time and in a couple cases it did help the
net upstream when something went wrong (e.g. this did stop some real
DoS traffic for me more than once). I made use of protocol counters or
some monitoring tools to ensure they were not unnecessarily dropping
valid packets. Your mileage may vary of course, as it apparently does?


Yep, agreed, we need to update those docs. The basic ICMP filtering guide still resides here, and comments are welcome:


John Kristoff wrote:

Welcome to the wonderful world of deciding on "defaults." Unfortunately, the people most likely to be negatively affected by defaults are also people least likely to know the consequences of those defaults.

Is it better to set defaults conservatively and allow people who want
more to expand them? Or better to set defaults liberally and allow
people who want less to reduce them?