Mailing List Archive: NANOG: users

Limiting ICMP

Index | Next | Previous | View Threaded

drew.weaver at thenap

May 17, 2008, 8:53 PM

Post #1 of 5 (503 views)
Permalink

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

_______________________________________________
NANOG mailing list
NANOG [at] nanog
http://mailman.nanog.org/mailman/listinfo/nanog

kgasso-lists at visp

May 17, 2008, 10:12 PM

Post #2 of 5 (480 views)
Permalink

Re: Limiting ICMP [In reply to]

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

_______________________________________________
NANOG mailing list
NANOG [at] nanog
http://mailman.nanog.org/mailman/listinfo/nanog

jtk at centergate

May 21, 2008, 2:15 PM

Post #3 of 5 (434 views)
Permalink

Re: Limiting ICMP [In reply to]

On Sat, 17 May 2008 23:53:00 -0400
Drew Weaver <drew.weaver [at] thenap> 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

robt at cymru

May 21, 2008, 2:18 PM

Post #4 of 5 (436 views)
Permalink

Re: Limiting ICMP [In reply to]

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 [at] thenap> 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/

sean at donelan

May 23, 2008, 4:23 PM

Post #5 of 5 (443 views)
Permalink

Re: Limiting ICMP [In reply to]

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?

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads