"Meanwhile, U.S. government security officials are discussing the possibility of creating new regulations that would require federal agencies to buy Internet service only from ISPs that have DDoS
Source address verification at access layer and rate limiting icmp would be fine starts. -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of fingers Sent: Tuesday, October 29, 2002 1:12 AM To: nanog@merit.edu Subject: Re: ICANN Targets DDoS Attacks protection
on their networks, according to people familiar with the situation. Such a decision could place economic pressure on the other ISPs to follow suit, thereby improving Internet security."
just how would an isp stamp themselves with the "DDoS protected" rubber stamp? I'm just curious as to what the next sales person is going to request as a product/service they're going to want to charge customers for. best practices like filtering != 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
*********** REPLY SEPARATOR *********** On 10/29/2002 at 3:40 PM Valdis.Kletnieks@vt.edu wrote:
On Tue, 29 Oct 2002 22:25:44 +0200, Petri Helenius <pete@he.iki.fi> said:
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. -- Jeff Shultz Network Support Technician Willamette Valley Internet Not speaking for anyone but myself here.
On Tue, Oct 29, 2002 at 12:48:39PM -0800, Jeff Shultz wrote:
*********** REPLY SEPARATOR ***********
On 10/29/2002 at 3:40 PM Valdis.Kletnieks@vt.edu wrote:
On Tue, 29 Oct 2002 22:25:44 +0200, Petri Helenius <pete@he.iki.fi> said:
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 -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
*********** REPLY SEPARATOR *********** On 10/29/2002 at 3:54 PM Jared Mauch wrote:
On Tue, Oct 29, 2002 at 12:48:39PM -0800, Jeff Shultz wrote:
*********** REPLY SEPARATOR ***********
On 10/29/2002 at 3:40 PM Valdis.Kletnieks@vt.edu wrote:
On Tue, 29 Oct 2002 22:25:44 +0200, Petri Helenius <pete@he.iki.fi> said:
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. -- Jeff Shultz Network Support Technician Willamette Valley Internet Not speaking for anyone but myself here.
On Tue, 29 Oct 2002, Jeff Shultz wrote:
*********** REPLY SEPARATOR ***********
On 10/29/2002 at 3:54 PM Jared Mauch wrote:
On Tue, Oct 29, 2002 at 12:48:39PM -0800, Jeff Shultz wrote:
*********** REPLY SEPARATOR ***********
On 10/29/2002 at 3:40 PM Valdis.Kletnieks@vt.edu wrote:
On Tue, 29 Oct 2002 22:25:44 +0200, Petri Helenius <pete@he.iki.fi> said:
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
--On 29 October 2002 21:11 +0000 "Stephen J. Wilcox" <steve@telecomplete.co.uk> wrote:
As they say, if you dont set the rate limit too low then you wont encounter drops under normal operation.
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
On Tue, Oct 29, 2002 at 01:03:52PM -0800, Jeff Shultz wrote:
On 10/29/2002 at 3:40 PM Valdis.Kletnieks@vt.edu wrote:
On Tue, 29 Oct 2002 22:25:44 +0200, Petri Helenius <pete@he.iki.fi> said:
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 -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
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. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
## On 2002-10-29 19:55 -0600 Rob Thomas typed: RT> RT> Hi, NANOGers. RT> RT> ] ICMP? RT> RT> I have my own thoughts on ICMP filtering, which you will find here: RT> RT> http://www.cymru.com/Documents/icmp-messages.html RT> RT> I don't claim to have correct thoughts, however, so input and suggestions RT> are always welcome. :) If anyone could pick up a NANOG t-shirt for me, RT> 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 -- Regards, Rafi RT> RT> Thanks, RT> Rob. RT>
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. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
On Tue, 29 Oct 2002 12:48:39 PST, Jeff Shultz said:
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.
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.... -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech
On Tue, Oct 29, 2002 at 10:25:44PM +0200, Petri Helenius wrote:
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 -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
participants (10)
-
Alex Bligh -
fingers -
H. Michael Smith, Jr. -
Jared Mauch -
Jeff Shultz -
Petri Helenius -
Rafi Sadowsky -
Rob Thomas -
Stephen J. Wilcox -
Valdis.Kletnieks＠vt.edu