In message <20030117062954.GK61038@lcs.mit.edu>, "David G. Andersen" writes:
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:
Here are the citations to the published papers: # Ratul Mahajan, Steven M. Bellovin, Sally Floyd, John Ioannidis, Vern Paxson, and Scott Shenker, Controlling High Bandwidth Aggregates in the Network, Computer Communications Review 32:3, July 2002, pp. 62-73. http://www.research.att.com/~smb/papers/pushback-CCR.ps # John Ioannidis and Steven M. Bellovin, "Implementing Pushback: Router-Based Defense Against DDoS Attacks", NDSS, February 2002. http://www.research.att.com/~smb/papers/pushback-impl.ps The publication dates notwithstanding, Mahajan et al. came first. As for the I-D -- we haven't had the cycles to work on it. There's reason to hope that activity will pick up. Re: I'm not sure its all that practical. I don't see that its helpful if it turns off services 'automatically' In theory, it doesn't turn off the service to all comers; it turns off the service along pipes from which the attack is coming. Just how good a job it will do at stopping collateral damage will depend on how far back there are pushback-enabled routers. If an ISP deployed it, but didn't speak pushback to its neighbors, clients on that same ISP's network should be able to access the service, as could peers who weren't the source of the garbage. But if some peer is sending an OC-12's worth of DDoS packets -- yes, all clients (or transit users) of that peer would be shut out. ICMP traceback is the subject of the IETF itrace working group. draft-ietf-itrace-03.txt just came out yesterday. The SPIE hash-based traceback is a much cooler idea, but it has some practical limitations, including the need to do the trace in more or less real-time (once the hash table fills up, it becomes useless), and the need for very large amounts of very fast memory on the tracing routers. There was an IETF BoF on it, but the folks behind it haven't been pushing it much. (Randy, do you know the status of it?) Both itrace and hash-based trace have some technical issues. itrace can handle only DoS-type attacks, since it's statistical in nature; hash-based traceback can, in theory, trace a single packet. But the real problem with either idea is this: suppose that you know, unambiguously and unequivocally, that 750 zombies are attacking you. What do you do with that information? --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book)