Source address verification at access layer and rate limiting icmp would
be fine starts.
Source address verification at access layer and rate limiting icmp would
be fine starts.
these are "best practices" and not "DDoS Protection" imho
Source address verification at access layer and rate limiting icmp would
be fine starts.
Why would you like to regulate my ability to transmit and receive data
using ECHO and ECHO_REPLY packets? Why they are considered
harmful?
I�m all for source address verification though.
Pete
Smurf.
> Source address verification at access layer and rate limiting icmp would
> be fine starts.
>
Why would you like to regulate my ability to transmit and receive data
using ECHO and ECHO_REPLY packets? Why they are considered
harmful?
I've found (as others have) that if you take a typical customer
interface or even infrastructure/peer interface, you don't see normal
packet rates over 2Mb/s of icmp echo+echo-reply (oc3, oc12 and gig-e
to exchange for example).
Go in and do a rate-limit (and tell it to transmit if exceeded
so it doesn't stop your traffic) on your router to check what your
typical rate is. you'd be surprised how much this will help
mitigate smurf/icmp attacks. It can take a 100Mb/s attack and
limit it to 2Mb*<number-of-ingress-peer-interfaces> which is likely
to be smaller than 100Mb/s. Yet still allow you to determine
the source interface by the unusual traffic spike/pps spike as wlel
as the rate-limit/car/whatever drops.
I�m all for source address verification though.
As am i.
- Jared
*********** REPLY SEPARATOR ***********
Why would you like to regulate my ability to transmit and receive
data
using ECHO and ECHO_REPLY packets? Why they are considered
harmful?Smurf.
Okay. What will this do to my user's ping and traceroute times, if
anything? I've got users who tend to panic if their latency hits 250ms
between here and the moon (slight exaggeration, but only slight).
I just love it when I've got people blaming me because the 20th hop on
a traceroute starts returning * * * instead of times.
that's icmp ttl expired messages.
- jared
So you rate limit it to several/second or something appropriate for the normal
traffic levels. You don't allow ping/traceroute to broadcast addresses.
If you have users with that critical a latency requirement, you should ALREADY
be doing traffic shaping and rate limiting to help ensure it. You might
want to check if your site is listed in any of the usual Smurf-amp databases,
and clean things up if you are - being used as a Smurf amp will shoot your
latency all to hell....
*********** REPLY SEPARATOR ***********
*********** REPLY SEPARATOR ***********
>
>> Why would you like to regulate my ability to transmit and receive
data
>> using ECHO and ECHO_REPLY packets? Why they are considered
>> harmful?
>
>Smurf.
>Okay. What will this do to my user's ping and traceroute times, if
anything? I've got users who tend to panic if their latency hits
250ms
between here and the moon (slight exaggeration, but only slight).
I just love it when I've got people blaming me because the 20th hop
on
a traceroute starts returning * * * instead of times.
that's icmp ttl expired messages.
I know that, and I try to explain it to my customers... but it doesn't
answer the first part of the question - what will throttling ICMP do to
ping and traceroute times? My gut reaction is that it will a. slow them
down and/or b. discard a lot of them making the circuit look unreliable
to ping. But I don't know enough about the underlying technology to be
sure of that.
As they say, if you dont set the rate limit too low then you wont encounter
drops under normal operation.
Steve
>> >
>> >> Why would you like to regulate my ability to transmit and receive
>> data
>> >> using ECHO and ECHO_REPLY packets? Why they are considered
>> >> harmful?
>> >
>> >Smurf.
>> >
>>
>> Okay. What will this do to my user's ping and traceroute times, if
>> anything? I've got users who tend to panic if their latency hits
250ms
>> between here and the moon (slight exaggeration, but only slight).
>>
>> I just love it when I've got people blaming me because the 20th hop
on
>> a traceroute starts returning * * * instead of times.
>
> that's icmp ttl expired messages.I know that, and I try to explain it to my customers... but it doesn't
answer the first part of the question - what will throttling ICMP do to
ping and traceroute times? My gut reaction is that it will a. slow them
ICMP?
Or only icmp echo and icmp echo-reply messages?
In a well behaved router, nothing. Obviously if you have
a 7500 or older GSR linecards that are incapable of doing this due to
design problems from day one in pps rates and feature path, there
may be a hit.
I'm not saying rate-limit anything other than echo+reply.
down and/or b. discard a lot of them making the circuit look unreliable
to ping. But I don't know enough about the underlying technology to be
sure of that.
Once again, i'd like to see (other than a performance
checking customer) generate more than 2Mb/s of icmp.echo and icmp.echo-reply
packets that are legit and not part of a DoS. This is quite rare.
Do your own stats and test your hardware.
- jared
Hi, NANOGers.
] ICMP?
I have my own thoughts on ICMP filtering, which you will find here:
http://www.cymru.com/Documents/icmp-messages.html
I don't claim to have correct thoughts, however, so input and suggestions
are always welcome. 
If anyone could pick up a NANOG t-shirt for me,
that would be welcome as well.
Thanks,
Rob.
On Tue, Oct 29, 2002 at 04:11:49PM -0500, Jared Mauch's all...
> Once again, i'd like to see (other than a performance
> checking customer) generate more than 2Mb/s of icmp.echo and icmp.echo-reply
> packets that are legit and not part of a DoS. This is quite rare.little blip in the internet, and all your intelligent customers running
linux use their leet tools to figure out whats wrong. They all run
mtr vs their preferred sites. Mtr generates one ICMP packet (~80 bytes?)
of traffic PER hop in the trace. A route of 20+ hops, means 1600 bytes/s
per customer (thats 12.8Kbps). 150 customers later you got 2Mbps of
traffic (2Mb/s is 2 megaBIT per second right? you didnt mean 2 mega BYTES
per second? in which case *8).Is 150 customers a large number?
And there are lots of nice graphical traceroute tools for windoze as well
of course, dont know their packet load in full operation however.Silly me, sometimes I leave mtrs running. I've found 2-3 going all at
once at times. <slap!/>Why is ICMP rate limiting on ECHO and ECHO reply going to stop all DOS
attacks? What are they going to do about UDP floods? (Are they proposing
I don't recall saying it will stop all DoS attacks.
It will help minimize them.
Please discontinue imagination. You obviously don't understand how
traceroute works by sending udp packets and getting icmp ttl expired
messages back which are not icmp {echo,echo-reply}. Come back when you do
understand how it works. /sigh
that DDOS attacks are all smurf based? They've just found a solution to 1996's
problems? Amazing!)
They're not, but there is still a large amount of things that
just do ping -f <10.2.3.4> and similar types of attacks. If you know
what your usual patterns are, it's easy to notice what is out of
place.
Addressing just the issue of how traceroute works, I'll point out that
(a) Most or all flavors of traceroute distributed by Microsoft use ICMP
ECHO instead of UDP for the outbound packets (the old issue of some
stacks not sending ICMP errors in response to any ICMP being not much
of an issue these days, Microsoft's non-traditional method works almost
as good as the traditional UDP method), and (b) A Microsoft traceroute
is what most customers will be using.
FWIW, I don't think rate limiting ICMP is likely to have a negative
impact. I also don't think it's a good idea, though -- it might help
to identify or prevent some problems in the short term, but in the long
run, it's a race we can't win -- if everyone limits ICMP, people will
launch DDos attacks with, say, packets to 80/tcp -- rate limiting that
is more problematic. ICMP rate limiting isn't anywhere near a big
enough win, from my perspective, to justify adding complexity to the
network, and having to remember, when troubleshooting strange problems,
that ICMP is no longer forwarded just like any other packet.
-- Brett
Brett! Long time, no hear, now that the Nortel/Bay newsgroup has
pretty much wound down. Like Usenet in general.
Addressing just the issue of how traceroute works, I'll point out that
(a) Most or all flavors of traceroute distributed by Microsoft use ICMP
ECHO instead of UDP for the outbound packets [...]
...And I rather like that method. It's sad, but I'll not allow
random high-port UDP to my stations.
FWIW, I don't think rate limiting ICMP is likely to have a negative
impact. I also don't think it's a good idea, though -- it might help
to identify or prevent some problems in the short term, but in the long
run, it's a race we can't win [...]
Hmmm. Agreed.
Peter E. Fry
## On 2002-10-29 19:55 -0600 Rob Thomas typed:
Hi, NANOGers.
] ICMP?
I have my own thoughts on ICMP filtering, which you will find here:
http://www.cymru.com/Documents/icmp-messages.html
I don't claim to have correct thoughts, however, so input and suggestions
are always welcome.
that would be welcome as well.
Hi Rob
I find it hard to believe You have no thoughts about:
1) rate-limiting ICMP
2) passing ICMP "statefully"
(that is for example ICMP echo reply only accepted in reply to an ICMP echo)
3) DoS problems related to ICMP unreachables
Hi, Rafi!
How's things?
] I find it hard to believe You have no thoughts about:
Oh, you know me; I have a thought about everything.
] 1) rate-limiting ICMP
This is covered in the Secure IOS Template, though it likely should be
added to the ICMP filtering list as well. I very much like the example
posted by Jared, so I may steal that as well (*waves to Jared*).
] 2) passing ICMP "statefully"
] (that is for example ICMP echo reply only accepted in reply to an ICMP echo)
Ah, yeah... I've seen a lot of problems with stateful inspection of
ICMP flows. In short, I've not seen it work consistently. Enlightenment
is welcome.
] 3) DoS problems related to ICMP unreachables
This is also covered in the Secure IOS Template; I recommend disabling
them. Barry has already given me the syntax to rate limit them, which
is something I need to add to the Secure IOS Template. I need more
time and more coffee.
http://www.cymru.com/Documents/secure-ios-template.html
Thanks,
Rob.
It would be useful if [vendor-du-jour] implemented rate-limiting
by hased corresponding IP address.
IE:
hash=gethash(source);
if (!hash) {hash=gethash(dest)}
if (hash) ratelimiton(bucket(hash);
That way you could (on transit interfaces) specify a paltry limit
of (say) 10kb/s of ICMP (per (hashed) source/destination), even
when there was 'naturally' hundreds of Mb/s of ICMP flowing
through the interface in a non DDoS environment. And if
an IP gets DDoS'd (or sources a DDoS), the ratelimit would
only affect that IP (oh, and any hash equivalents) only.
As, for these purposes, dropping large numbers of relatively
inactive hash entries wouldn't be painful, I would have thought
this would be unlikely to suffer from the self-similarity
properties that made Netflow hard - but perhaps not.
Alex