Is there a line of defense against Distributed Reflective attacks?

Mailman List Mirror (Read Only)
1

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)

2

The reality is its not 750 zombies, its generally one person controlling
750 zombies attacking you.

The firefighter approach is not a complete solution. Putting out the
fire is only part of the answer. You also need to stop the arsonist
from setting more fires and improve the building codes to reduce the risk.

We need to do more than just waiting for complaints and putting in more
and more null routes all over the network. On the other hand, ingress
filtering is not a complete solution either. There are some things some
networks can do easier than other networks. But there isn't just one fix
which will work for everyone, or which will solve the problem. Null
routes alone didn't solve the spam problem, and I doubt it will solve the
DDOS problem.

So how do we
   1) Make end-user systems less vulnerable to being compromised
   2) Track and stop DDOS quickly when it does happen
   3) Find and convict the true attacker

3

Date: Sat, 18 Jan 2003 21:22:14 -0500 (EST)
From: Sean Donelan

1) Make end-user systems less vulnerable to being compromised

With consumers, "cheap and easy" usually wins. More often than
not, I hear "I don't care if someone breaks into my computer or
my email, because I don't have anything private". One of our
customers knowingly had the ILOVEYOU virus for I can't remember
how many months. (Gotta love the rejected mail logs on _that_
one.)

With essentially one desktop OS, there's not a huge amount of
pressure to make a better product. How many known bugs were in
the fraction of Windows source code involved in the antitrust
case? My memory fades, but it seems code quality in the most
popular OS is not the highest priority.

2) Track and stop DDOS quickly when it does happen

Is it TCP/80 DDoS, or did you just get slashdotted? (I suppose
that goes along with #3, below.)

3) Find and convict the true attacker

IOW, find the "magic packet" someone used to bring 10,000 zombies
to life.

Question: Just how often do people need end-to-end IP traffic?
I'm not suggesting blocking it; that would be bad. But look at
AOL's proxied Web and email service... most people are none the
wiser. Perhaps end-to-end traffic should be blocked at the edge
until <???>.

And, oh yeah, "shut off the malicious and clueless" has worked
just great for stopping spam, hasn't it? As Chris Morrow and
others so often and aptly mention -- technical problem or social
malady?

Eddy