Re: Effective ways to deal with DDoS attacks?
It seems to me that the real issue in defending against an attack of this type of differentiating between legitimate traffic and zombie traffic.
Exactly. And while with today's DDoS attacks this is often not so hard, tomorrow's floods will be more carefully crafted so that there are no telltales that can be cheaply used to filter them out. Steve Bellovin and colleagues (me being one of them) have been working on a scheme called "Pushback", in which routers detect traffic aggregates that are burdening one of their links, and send pushback messages upstream to their peers responsible for the bulk of the traffic, asking them to rate-limit the aggregates. The key idea is that the upstream peers then monitor which of *their* upstream peers are responsible for the bulk of the traffic they're now rate-limiting, and send them pushback messages in turn, too. In this fashion, the pushback propagates out to the edge of the network (or the ISP's cloud, if that's the limit of pushback deployment). While there is still collateral damage in terms of any legitimate traffic that happens to enter from the same edge as the attack traffic will be subject to the same rate-limiting, *other* legit traffic that comes from other locations will escape the effects of the rate-limiting; so collateral damage is a lot less than if you just blindly rate-limit the aggregate. There are a number of issues concerning identifying aggregates, timing out the rate-limiting, etc. It's also not clear to what degree Pushback will work in the face of an extremely diffuse attack (see my next message). But it's at least a start on a solution that doesn't require uniform filtering of visibly distinct traffic. Pushback is described at: http://www.icir.org/pushback/ - Vern
On Tue, 7 May 2002 vern@ee.lbl.gov wrote:
It seems to me that the real issue in defending against an attack of this type of differentiating between legitimate traffic and zombie traffic.
Exactly. And while with today's DDoS attacks this is often not so hard, tomorrow's floods will be more carefully crafted so that there are no telltales that can be cheaply used to filter them out.
Steve Bellovin and colleagues (me being one of them) have been working on a scheme called "Pushback", in which routers detect traffic aggregates that are burdening one of their links, and send pushback messages upstream to their peers responsible for the bulk of the traffic, asking them to rate-limit the aggregates. The key idea is that the upstream peers then
1) rate-limits aren't going to solve anything. 2) I'm pretty sure most providers aren't going to let customers determine traffic engineering methods on their networks 3) if this is NOT done in a secure manner I bet I can make www.whitehouse.com disappear... :) -Chris
CLM> Date: Tue, 7 May 2002 21:43:10 +0000 (GMT) CLM> From: Christopher L. Morrow CLM> 1) rate-limits aren't going to solve anything. If -- big if -- the sources could be throttled... but they'd have to be so slow that they were effectively shut off. Maybe it would be easier to give more power to TCP congestion control. Maybe similar functionality in ICMP. Maybe something in IP itself. Did somebody say "ECN"? Frankly, if ECN were "widely enough" deployed, one could assume ECN-ignoring devices to be rogue, and act upon that. Right now one does it at layer 9. A lower layer isn't out of the question. (See remarks re point #3.) CLM> 2) I'm pretty sure most providers aren't going to let CLM> customers determine traffic engineering methods on their CLM> networks BGP communities... 3356, 3561, 4006, 3549, and several smaller providers offer selective prepends... if there were more edge clue, I think that more would follow. Many more honor MEDs, and virtually all provide local-pref knobs... The big pain in something like this would be state. Hence why some sort of pushback sounds reasonable; determine the other endpoints, and communicate with edge devices. Keep state out of the core. *sits and prepares to listen to how big UU's edge is* "We can't do it because Vendor X doesn't offer it" is not the right answer. If it's feasible, the question is _why_ Vendor X doesn't offer capable hardware. (I'm leaving it at that, as this message already relates to several flame wars.) Yes, that would be a big chore for a 1x000-class router with tons if subinterfaces. But where do those subinterfaces originate? Might the true edge device be the... switch? Let's say that it takes $5000 of hardware to provide this service on a DS3. When I go shopping, will I be willing to pay five grand extra for a DS3 that has better DDoS control? (Hint: How much bandwidth will I lose otherwise?) Better yet, let's say I colo at a place that charges for traffic. Will I pay a bit extra for an outfit that has my best interests in mind? Perhaps I don't care how big the ice cream cone is if it doesn't have a nice flavor. The world's biggest ice cream cone just might not be enough of an offering, especially if the cow is having trouble producing milk. CLM> 3) if this is NOT done in a secure manner I bet I can make CLM> www.whitehouse.com disappear... :) If BGP is not done in a secure manner I bet I can make any site disappear. -- Eddy Brotsman & Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.
participants (3)
-
Christopher L. Morrow -
E.B. Dreger -
vern＠ee.lbl.gov