Is there a line of defense against Distributed Reflective attacks?
Having researched this in-depth after reading a rather cursory article on the topic (http://grc.com/dos/drdos.htm), only two main methods come to my mind to protect against it. By way of quick review, such an attack is carried out by forging the source address of the target host and sending large quantities of packets toward a high-bandwidth middleman or several such. To my knowledge the network encompassing the target host is largely unable to protect itself other than 'poisoning' the route to the host in question. This succeeds in minimizing the impact of such an attack on the network itself, but also acheives the end of removing the target host from the Internet entirely. Additionally, if the targetted host is a router, little if anything can be done to stop that network from going down. One method that comes to mind that can slow the incoming traffic in a more distributed way is ECN (explicit congestion notification), but it doesn't seem as though the implementation of ECN is a priority for many small or large networks (correct me if I'm wrong on this point). If ECN is a practical solution to an attack of this kind, what prevents its implementation? Lack of awareness, or other? Also, are there other methods of protecting a targetted network from losing functionality during such an attack? Insights welcome. Brad -- // -- http://www.BRAD-X.com/ -- //
This type of DRDOS (Distributed Reflective Denial of Service Attack) is well commonly-known to both network operators, and as well as many script-kiddies. By forging the source IP address of the attack to the victim's IP, and attacking internet backbone routers, this creates an immediate, devastating, yet very effective attack. Backbone routers, seeing this as legitimate packets simply reply back to the victim. I guess the question is, what are the internet backbones doing these days to evade the outcome of reflected DoS attacks? Are they simply going to let their routers be the middleman to kick off innocent hosts? SYN cookies and various other methods to control DoS attacks are only used by smart ISP's.. And considering most ISP's do not even care about egress filters, I don't believe any of these methods will work for quite some time to come. -hc
Having researched this in-depth after reading a rather cursory article on the topic (http://grc.com/dos/drdos.htm), only two main methods come to my mind to protect against it.
By way of quick review, such an attack is carried out by forging the source address of the target host and sending large quantities of packets toward a high-bandwidth middleman or several such.
To my knowledge the network encompassing the target host is largely unable to protect itself other than 'poisoning' the route to the host in question. This succeeds in minimizing the impact of such an attack on the network itself, but also acheives the end of removing the target host from the Internet entirely. Additionally, if the targetted host is a router, little if anything can be done to stop that network from going down.
One method that comes to mind that can slow the incoming traffic in a more distributed way is ECN (explicit congestion notification), but it doesn't seem as though the implementation of ECN is a priority for many small or large networks (correct me if I'm wrong on this point). If ECN is a practical solution to an attack of this kind, what prevents its implementation? Lack of awareness, or other?
Also, are there other methods of protecting a targetted network from losing functionality during such an attack?
Insights welcome.
Brad
On Thu, 16 Jan 2003, hc wrote:
This type of DRDOS (Distributed Reflective Denial of Service Attack) is well commonly-known to both network operators, and as well as many script-kiddies.
By forging the source IP address of the attack to the victim's IP, and attacking internet backbone routers, this creates an immediate, devastating, yet very effective attack. Backbone routers, seeing this as legitimate packets simply reply back to the victim.
I guess the question is, what are the internet backbones doing these days to evade the outcome of reflected DoS attacks? Are they simply going to let their routers be the middleman to kick off innocent hosts?
SYN cookies and various other methods to control DoS attacks are only
Because syn cookies are available on routing gear??? Either way syn cookies are not going to keep the device from sending a 'syn-ack' to the 'originating host'.
used by smart ISP's.. And considering most ISP's do not even care about egress filters, I don't believe any of these methods will work for quite some time to come.
-hc
Because syn cookies are available on routing gear??? Either way syn cookies are not going to keep the device from sending a 'syn-ack' to the 'originating host'.
True.. At least it will have some stop in the amount of attacks. It is quite unfortunate that it is impossible to control the 'ingress' point of attack flow. Whenever there is a DoS attack, the only way to drop it is to null route it (the method you have devised) over BGP peering, but that knocks the victim host off the 'net... :-( -hc
On Thu, 16 Jan 2003, hc wrote:
Because syn cookies are available on routing gear??? Either way syn cookies are not going to keep the device from sending a 'syn-ack' to the 'originating host'.
True.. At least it will have some stop in the amount of attacks.
It is quite unfortunate that it is impossible to control the 'ingress' point of attack flow. Whenever there is a DoS attack, the only way to drop it is to null route it (the method you have devised) over BGP peering, but that knocks the victim host off the 'net... :-(
Sure, but this like all other attacks of this sort can be tracked... and so the pain is over /quickly/ provided you can track it quickly :) Also, sometimes null routes are ok.
Christopher L. Morrow wrote:
On Thu, 16 Jan 2003, hc wrote:
Because syn cookies are available on routing gear??? Either way syn cookies are not going to keep the device from sending a 'syn-ack' to the 'originating host'.
True.. At least it will have some stop in the amount of attacks.
It is quite unfortunate that it is impossible to control the 'ingress' point of attack flow. Whenever there is a DoS attack, the only way to drop it is to null route it (the method you have devised) over BGP peering, but that knocks the victim host off the 'net... :-(
Sure, but this like all other attacks of this sort can be tracked... and so the pain is over /quickly/ provided you can track it quickly :) Also, sometimes null routes are ok.
How quickly is quickly? Often times as has been my recent experience (part of my motivation for posting this thread) the flood is over before one can get a human being on the phone. What kinds of mechanisms exist for keeping track of the origins of something of this nature? -- // -- http://www.BRAD-X.com/ -- //
On Thu, 16 Jan 2003, Brad Laue wrote:
Christopher L. Morrow wrote:
On Thu, 16 Jan 2003, hc wrote:
Because syn cookies are available on routing gear??? Either way syn cookies are not going to keep the device from sending a 'syn-ack' to the 'originating host'.
True.. At least it will have some stop in the amount of attacks.
It is quite unfortunate that it is impossible to control the 'ingress' point of attack flow. Whenever there is a DoS attack, the only way to drop it is to null route it (the method you have devised) over BGP peering, but that knocks the victim host off the 'net... :-(
Sure, but this like all other attacks of this sort can be tracked... and so the pain is over /quickly/ provided you can track it quickly :) Also, sometimes null routes are ok.
How quickly is quickly? Often times as has been my recent experience (part of my motivation for posting this thread) the flood is over before one can get a human being on the phone.
Once the call arrives and the problem is deduced it can be tracked in a matter of minutes, like 6-10 at the fastest...
What kinds of mechanisms exist for keeping track of the origins of something of this nature?
Normally that's not very productive as they are mostly owned boxes that will be rebuilt and reowned in days :(
Normally that's not very productive as they are mostly owned boxes that will be rebuilt and reowned in days :(
I agree, keeping track of the attacks would not be very useful nor helpful. I bet if more ISP's would implement egress filtering on their border routers, it'd help quite a bit. Of course, egress filters don't solve the issue. But considering most script kiddies' intelligence level is limited, it will help at least a bit. :-) The problem with egress filtering is that it's mostly applicable at the end tier2+ level, not at the backbones, which means a lot of ISP's who are oblivious on what it is (or some cases where egress filter breaks their network setup). -hc
On Thu, 16 Jan 2003, hc wrote:
Normally that's not very productive as they are mostly owned boxes that will be rebuilt and reowned in days :(
I agree, keeping track of the attacks would not be very useful nor helpful. I bet if more ISP's would implement egress filtering on their border routers, it'd help quite a bit. Of course, egress filters don't solve the issue. But considering most script kiddies' intelligence level
Egress filters are a distraction... today you don't have to spoof. These are the red herring of 'security'. THOUGH, all that said, having all networks, CUSTOMER NETWORKS, filtered as close to end systems as possible would be a nice thing :) As Rob Thomas points out 80% (or some huge number) of attacks are spoofed source attacks. Every leaf network should be able to do the minimum urpf strict on all ether or gig link... that way you don't even have to take the hit of a acl to process the inbound traffic :) This is most definitely best done as close to the end machines as possible though, the traffic loads there are just much more managable... and it reduces the possible spoofage to the lowest limit possible.
is limited, it will help at least a bit. :-) The problem with egress filtering is that it's mostly applicable at the end tier2+ level, not at the backbones, which means a lot of ISP's who are oblivious on what it is (or some cases where egress filter breaks their network setup).
Hmm, but the smaller the network the easier to filter it is... right?
CLM> Date: Fri, 17 Jan 2003 05:16:43 +0000 (GMT) CLM> From: Christopher L. Morrow CLM> Egress filters are a distraction... today you don't have to CLM> spoof. These are the red herring of 'security'. They're one component, but not the cure-all. With an increasing number of "h4x0r3d" hosts, anti-spoofing's importance certainly diminishes. However... CLM> Hmm, but the smaller the network the easier to filter it CLM> is... right? ...you said it. From an equipment standpoint, anyway. Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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.
According to hc <haesu@towardex.com>
Of course, egress filters don't solve the issue. But considering most script kiddies' intelligence level is limited, it will help at least a bit. :-) The problem with egress filtering is that it's mostly applicable at the end tier2+ level, not at the backbones, which means a lot of ISP's who are oblivious on what it is (or some cases where egress filter breaks their network setup).
On the subject of "help a bit", if service providers were to require, by default, either an egress filter (correctly configured) on the CPE router or an ingress filter on their own customer aggregation router it might do some good ... Cheers. -travis
-hc
On Fri, 17 Jan 2003 04:29:07 GMT, "Christopher L. Morrow" said:
How quickly is quickly? Often times as has been my recent experience (part of my motivation for posting this thread) the flood is over before one can get a human being on the phone.
Once the call arrives and the problem is deduced it can be tracked in a matter of minutes, like 6-10 at the fastest...
Yes, but *YOUR* crew has a reputation for having a clue. I'm willing to bet that "once the call arrives" is a challenge for a lot of smaller ISPs that don't even *HAVE* a security team, and "the problem is deduced" is a challenge for the ones that have a team that don't have a clue. We see a *LOT* of postings here "anybody know a clueful at XYZ, we've been DDoS'ed for 36 hours".... -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech
On Fri, 17 Jan 2003 Valdis.Kletnieks@vt.edu wrote:
On Fri, 17 Jan 2003 04:29:07 GMT, "Christopher L. Morrow" said:
How quickly is quickly? Often times as has been my recent experience (part of my motivation for posting this thread) the flood is over before one can get a human being on the phone.
Once the call arrives and the problem is deduced it can be tracked in a matter of minutes, like 6-10 at the fastest...
Yes, but *YOUR* crew has a reputation for having a clue. I'm willing to
We appreciate the kind words :)
bet that "once the call arrives" is a challenge for a lot of smaller ISPs that don't even *HAVE* a security team, and "the problem is deduced" is a challenge for the ones that have a team that don't have a clue.
This gets down to something I've harped on for a while now... if you drive a car you must have a license and pass a test. If you run a network on the internet you really should have 24/7 security clued person(s) available to stop/track/mitigate security issues.
We see a *LOT* of postings here "anybody know a clueful at XYZ, we've been DDoS'ed for 36 hours"....
Yup, and its a shame that that is the case :( Perhaps they should become UUNET customers and then they can just call us? :) People move for cheap bandwidth alot, I wonder how the value proposition works out when you are down and paying SLA's to your customers due to a hosted dalnet server getting attacked for 36 hours?
Yup, and its a shame that that is the case :( Perhaps they should become UUNET customers and then they can just call us? :) People move for cheap bandwidth alot, I wonder how the value proposition works out when you are down and paying SLA's to your customers due to a hosted dalnet server getting attacked for 36 hours?
Everything is always the $$$ issue... :) -hc
My previous experience with UUNET security team was excellent dealing with DoS. I am not here to point fingers, but my DoS-response experience with various Tier-2/3 level ISP's was like talking to some K-12 teacher who barely knows what internet is. It really takes hours to get thru and reach a competent engineer on the phone. And that's the major frustration of a LOT customers getting DoSed/DDoSed/DrDoSed off the planet everyday. -hc Valdis.Kletnieks@vt.edu wrote:
On Fri, 17 Jan 2003 04:29:07 GMT, "Christopher L. Morrow" said:
How quickly is quickly? Often times as has been my recent experience (part of my motivation for posting this thread) the flood is over before one can get a human being on the phone.
Once the call arrives and the problem is deduced it can be tracked in a matter of minutes, like 6-10 at the fastest...
Yes, but *YOUR* crew has a reputation for having a clue. I'm willing to bet that "once the call arrives" is a challenge for a lot of smaller ISPs that don't even *HAVE* a security team, and "the problem is deduced" is a challenge for the ones that have a team that don't have a clue.
We see a *LOT* of postings here "anybody know a clueful at XYZ, we've been DDoS'ed for 36 hours"....
At 12:00 AM 17-01-03 -0500, Valdis.Kletnieks@vt.edu wrote: nsp-security now has 277 members and gets many of these warnings and alerts. For further details: http://puck.nether.net/mailman/listinfo/nsp-security -Hank
We see a *LOT* of postings here "anybody know a clueful at XYZ, we've been DDoS'ed for 36 hours".... -- Valdis Kletnieks
What kinds of mechanisms exist for keeping track of the origins of something of this nature?
Normally that's not very productive as they are mostly owned boxes that will be rebuilt and reowned in days :(
We could automate the tracing process, like *57 customer initiated trace on the telephone network ($5 per use). But then what? You can track the sources as quickly as you can, but part of the question becomes how long and how many sources do you keep blocked once you have tracked them. Is it one strike and you're out forever. If 80% of the attacks are not spoofed, why not create yet another RBL and keep adding more and more addresses? If you remove the filter after the attack stops, it will just come back or they'll choose a different victim. Do we need te equivalent of a dog bite law for computers. If your computer attacks another computer, the owner is responsible. File a police report, and the ISP will give the results of the *57 trace to the local police. The police can then put down the rabid computer, permanently.
Do we need te equivalent of a dog bite law for computers. If your computer attacks another computer, the owner is responsible. File a police report, and the ISP will give the results of the *57 trace to the local police. The police can then put down the rabid computer, permanently.
Good in theory... in practice police has more important things to do. Like catching pot smokers. --vadim
Vadim Antonov wrote: Caution this won't program a router:
The police can then put down the rabid computer,
permanently. Good in theory... in practice police has more important things to do. Like catching pot smokers.
Not -=too=- much problem soon, thanks to the USA "Patriot" act. In conjunction with the new Mother^^^^^^HomeLand Security design, The DEA will be considered part of the HomeLand Security team. This means they will have access to all the "extra-constitutional" monitoring/invasion of privacy activity that we deploy against citizens^^^^^^^^^terrorists for "National Defense", in such "Patriotic" programs as "CoinTelPro". I.E.: Tap your phone, monitor your email/internet activity, "sneak and peak" into your house, access you financial transactions, (bank and credit card), access your doctor's files, question your lawyer, arrest you without "Miranda", incarcerate you indefinitely without a phone call, or a trial, and finally and best of all, the brand new "Torture a confession" information gathering methods... (See: Chavez v Martinez ) ....all without a -=warrant=-. (I hear "probable cause" has actually been -stretched- to include "politically active people". It seems such people -change- the laws, and government, hence are a matter of "National Security". So, therefore, being a Democrat now qualifies you for "CoinTelPro", just like Nixon originally decided in "Watergate".) After all, Homeland security will be sharing it's data with every member of the Division, as part of it's charter, and the Intelligence Agencies will be used to gather it, (-=against=- theirs). It's a matter of "National Security", you know. Gotta Keep you safe from those Pot Smokers, after all! Why, We can't have "Saddam Bin Laden" hiding out in North Korea with "Nuclear Plague" devices, and doing "doobs" with an American Citizen.. plotting our Mass Destruction, Now can we ?! ;) PPS: Don't worry "Citizen", the Executive Branch funded Churches will have plenty of -=other=- things for you to do, that are wholesome, and healthy..... Like egg tossing, and gunny sack races, in the "Name of Jesus". - The Church Lady :P
--vadim
"Only Criminals don't want to be monitored" - Nazi Youth Slogan. http://www.aclu.org http://www.whitehouse.org
On Fri, 17 Jan 2003, Vadim Antonov wrote:
Do we need te equivalent of a dog bite law for computers. If your computer attacks another computer, the owner is responsible. File a police report, and the ISP will give the results of the *57 trace to the local police. The police can then put down the rabid computer, permanently.
Good in theory... in practice police has more important things to do. Like catching pot smokers.
HAHAHAHA :) Very funny. Seriously though, police can't remove access to the system for individuals simply because they didn't turn off whatever MS thing turns on port 445 by default... This gets back to the drivers' license for internet access/computer use. A nice idea, not practical and not enforcable :( And... not the solution to most of the problems. Keep in mind that a majority of the attacks are NOT against 'high profile' sites/customers... so many times a null route is a perfectly acceptable solutions.
Sure, but this like all other attacks of this sort can be tracked... and so the pain is over /quickly/ provided you can track it quickly :) Also, sometimes null routes are ok.
How quickly is quickly? Often times as has been my recent experience (part of my motivation for posting this thread) the flood is over before one can get a human being on the phone.
Once the call arrives and the problem is deduced it can be tracked in a matter of minutes, like 6-10 at the fastest...
So if one wants to create a really nasty, largely untrackable problem, one just needs to mount a set of attacks that last 3-4 minutes at a time? This is a very bad band-aid. The solution is amazingly simple - make it uneconomical to have unprotected networks, the same way as it is uneconomical for businesses that rely on internet for critical communications not to have a firewall in place when purchasing business interruption insurance. Alex
] Because syn cookies are available on routing gear??? Either way syn ] cookies are not going to keep the device from sending a 'syn-ack' to the ] 'originating host'. Agreed. SYN cookies also won't drain a pipe full of malevolent packets. Any response the target is able to send during a TCP amplification attack is a bonus prize, but is not required for the attack to succeed. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
On Thu, 16 Jan 2003, Brad Laue wrote:
Having researched this in-depth after reading a rather cursory article on the topic (http://grc.com/dos/drdos.htm), only two main methods come to my mind to protect against it.
By way of quick review, such an attack is carried out by forging the source address of the target host and sending large quantities of packets toward a high-bandwidth middleman or several such.
To my knowledge the network encompassing the target host is largely unable to protect itself other than 'poisoning' the route to the host in question. This succeeds in minimizing the impact of such an attack on the network itself, but also acheives the end of removing the target host from the Internet entirely. Additionally, if the targetted host is a router, little if anything can be done to stop that network from going down.
One method that comes to mind that can slow the incoming traffic in a more distributed way is ECN (explicit congestion notification), but it doesn't seem as though the implementation of ECN is a priority for many small or large networks (correct me if I'm wrong on this point). If ECN is a practical solution to an attack of this kind, what prevents its implementation? Lack of awareness, or other?
Doesn't ECN depend on 'well behaved' traffic? In other words, wouldn't it require the hosts sending traffic to slow down? So... even if the hosts slowed down, 10,000 hosts still is a high traffic rate at the end point. :(
Also, are there other methods of protecting a targetted network from losing functionality during such an attack?
Insights welcome.
Brad
-- // -- http://www.BRAD-X.com/ -- //
Christopher L. Morrow wrote:
On Thu, 16 Jan 2003, Brad Laue wrote:
[ .. ]
Doesn't ECN depend on 'well behaved' traffic? In other words, wouldn't it require the hosts sending traffic to slow down? So... even if the hosts slowed down, 10,000 hosts still is a high traffic rate at the end point. :(
Good point. I suppose another basic but effective method of prevention would be egress filtering. An increasing minority of network providers are instituting it, but it doesn't seem like it will be a widespread thing in the near-term. -- // -- http://www.BRAD-X.com/ -- //
Good point.
I suppose another basic but effective method of prevention would be egress filtering. An increasing minority of network providers are instituting it, but it doesn't seem like it will be a widespread thing in the near-term.
Yes, but egress filtering is only effective by far. Anyone can forge the source to an IP address that belongs to one of the /16's a provider advertises. It will help of course, but really not The solution... Or is there one? -hc
On Fri, 17 Jan 2003, hc wrote:
Good point.
I suppose another basic but effective method of prevention would be egress filtering. An increasing minority of network providers are instituting it, but it doesn't seem like it will be a widespread thing in the near-term.
Yes, but egress filtering is only effective by far. Anyone can forge the source to an IP address that belongs to one of the /16's a provider advertises.
filter close to the end host, this limits (mostly) to the local /24 or /25 or /2(>5)...
It will help of course, but really not The solution... Or is there one?
haha, there isn't one :( since even with no spoofing you can muster an army of 100,000 IIS servers still scanning for nimda :(
On Fri, 17 Jan 2003 00:03:56 EST, hc said:
It will help of course, but really not The solution... Or is there one?
In this industry, anybody who advertises The Solution should automatically be considered a snake oil salesman. There's no One Great Answer, because there's more than one question. There's a LOT of things that would help: Ingress filtering Egress filtering Clued incident response teams Systems not shipped insecure by default. etc etc etc. You've heard them all, I've said them all, they all address parts of the problem. Nothing addresses all of it. Ingress/egress filtering would help in some cases of a DDoS packet flood. Ingress/egress filtering doesn't do squat when Nimda is on a burn. -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech
Doesn't ECN depend on 'well behaved' traffic? In other words, wouldn't it require the hosts sending traffic to slow down? So... even if the hosts slowed down, 10,000 hosts still is a high traffic rate at the end point. :(
Yes, for ECN to work the sending host must honor the slowdown request/ It does happen transparently for most types of sockets, however the attacker can and will disable ECN with a single syscall. Alex
On Thu, Jan 16, 2003 at 08:48:03PM -0500, Brad Laue mooed:
By way of quick review, such an attack is carried out by forging the source address of the target host and sending large quantities of packets toward a high-bandwidth middleman or several such.
One method that comes to mind that can slow the incoming traffic in a more distributed way is ECN (explicit congestion notification), but it doesn't seem as though the implementation of ECN is a priority for many
No. ECN is, first and foremost, an optimization for TCP so that it doesn't have to drop packets before cutting its rate back when there's congestion in the network. A zombie or malicious host would just ignore the ECN bit - and the attacks you're describing never reach the point where a host's flow control is involved. You might be thinking of source quench, but that's really not an option with today's networks. Some other conventional alternatives have been discussed already (ingress/egress filtering, etc). Some less conventional options: [Warning: Some researchy stuff ahead] a) Mazu and Arbor provide products that can detect and optionally shape traffic to avoid DDoS attacks. Must be installed in-line to shape, and can't (AFAIK) shape at really really high line speeds. But for reasonable things like, maybe gigabit and under, I think they can provide pretty reasonable protection. Don't quote me for sure on the rates. b) Ioannidis and Bellovin proposed a mechanism called "Pushback" for automatically establishing router-based rate limits to staunch packet flows during DoS attacks. [NDSS 2002, "Implementing Pushback: Router-Based Defense Against DDoS Attacks"] c) I stole some ideas from a sigcomm paper this year ("SOS: Secure Overlay Services") to propose a proactive DDoS resistance scheme I term Mayday. The basic idea is that you pick some secret attributes of your packets - destination port, destination address, etc. - and only allow packets with "the right values" through. You then tell that secret to someone like Akamai, and have them proxy all requests to you. Then you ask your upstream to proactively deny all packets without the magical values. http://nms.lcs.mit.edu/papers/mayday-usits2003.html It's a little weird, but I'd be willing to bet that one of the big overlay providers like Akamai could actually pull it off. The advantage of this approach is that you can implement it without fixing the whole world, unlike egress filters. The downside is that you need someone with lots of nodes. I'd be interested in hearing folk's comments about the mayday paper, btw, since I have to babble about it at a conference in a month. ;-) -Dave -- work: dga@lcs.mit.edu me: dga@pobox.com MIT Laboratory for Computer Science http://www.angio.net/ I do not accept unsolicited commercial email. Do not spam me.
On Fri, Jan 17, 2003 at 01:11:14AM -0500, David G. Andersen mooed:
b) Ioannidis and Bellovin proposed a mechanism called "Pushback" for automatically establishing router-based rate limits to staunch packet flows during DoS attacks. [NDSS 2002, "Implementing Pushback: Router-Based Defense Against DDoS Attacks"]
I should have been a bit more accurate here. The proposal for pushback is actually earlier than the implementation paper I cited above: "Controlling High Bandwidth Aggregates in the Network. Ratul Mahajan, Steven M. Bellovin, Sally Floyd, John Ioannidis, Vern Paxson, and Scott Shenker. July, 2001." and it also included an internet-draft: http://www.aciri.org/floyd/papers/draft-floyd-pushback-messages-00.txt I believe that Steve Bellovin gave a talk about it at NANOG 21: http://www.research.att.com/~smb/talks/pushback-nanog.pdf -Dave (I'll learn not to send mail past midnight some day) -- work: dga@lcs.mit.edu me: dga@pobox.com MIT Laboratory for Computer Science http://www.angio.net/ I do not accept unsolicited commercial email. Do not spam me.
participants (13)
-
alex＠yuriev.com -
Brad Laue -
Christopher L. Morrow -
David G. Andersen -
E.B. Dreger -
Hank Nussbacher -
hc -
Richard Irving -
Rob Thomas -
Sean Donelan -
Travis Pugh -
Vadim Antonov -
Valdis.Kletnieks＠vt.edu