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
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. Cheers, --Kameron
On Sat, 17 May 2008 23:53:00 -0400 Drew Weaver <drew.weaver@thenap.com> wrote:
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?
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? John
Yep, agreed, we need to update those docs. The basic ICMP filtering guide still resides here, and comments are welcome: <http://www.cymru.com/Documents/icmp-messages.html> John Kristoff wrote:
On Sat, 17 May 2008 23:53:00 -0400 Drew Weaver <drew.weaver@thenap.com> wrote:
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?
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?
John
-- Rob Thomas Team Cymru The WHO and WHY team http://www.team-cymru.org/
On Wed, 21 May 2008, John Kristoff wrote:
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?
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?
participants (5)
-
Drew Weaver -
John Kristoff -
Kameron Gasso -
Rob Thomas -
Sean Donelan