Is there a line of defense against Distributed Reflective attacks?

Steven M. Bellovin smb at research.att.com
Sat Jan 18 23:11:30 UTC 2003


In message <20030117062954.GK61038 at 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:
>
>  http://www.research.att.com/~smb/talks/pushback-nanog.pdf

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)





More information about the NANOG mailing list