Proposal for mitigating DoS attacks

------- Blind-Carbon-Copy

X-Mailer: exmh version 2.0.2 2/24/98

-----BEGIN PGP SIGNED MESSAGE-----

Thus an oft-used response to an attack is to block traffic either to, or
from, particular IP addresses. In the case of attacks involving forged
source IP addresses, or reflected attacks such as SMURF, the only way to
easilly block these attacks to prevent collateral damage, is to prevent
all traffic from reaching the IP address concerned (filtering) until the
attack has ceased (either as a consequence of a parallel act of tracing,
or otherwise).

While I like the idea of your proposal, I see it as not working because it
trusts information generated by the attacker that is not necessarily
relevant to the success of the attack.

As I am familiar with it, the smurf is generally successful not by flooding
the target hosts LAN, but rather its upstream network connection.
Infrastructure to take that one host off of the net quickly isn't going to
help if its network thats being attacked. If this proposal becomes widely
accepted, it will only succeed in getting someone to modify the exploit to
allow the attacker to input a netmask, randomly flooding every IP sharing
the same link. The effect will basically be the same, as far as I can tell.

The information that you can trust is that your attacker will cause large
quantities of ICMP echo-reply (or sometimes UDP) packets to enter your
network from amplifier source addresses. The options I see are to either:

- - Rate-limit or block ICMP echo-reply traffic, as close to the source as
  possible. This may be only at your network ingress, but it might be
  interesting to see if the backbones really need to allow more than 5-20%
  of the bandwidth of any link as ICMP echo-reply.

- - Rate-limit or block traffic from amplifier source addresses. If a
  significant portion of the 'net were simply unavailable to these networks
  until they turned off directed-broadcast, they would get fixed much
  faster. A BGP RBL-style feed would be the most easily maintainable, but
  one could even just write a script to take the top 100 off of netscan.org
  and add them access-lists.

                   Aaron Hopkins
                   aaron@cyberverse.com
                   Chief Technical Officer, Cyberverse Inc.

How outlandish would it be (and I realize it'd have to be done in the
router software and all that implies) to just turn on source routing
on particular types of packets (e.g., ICMP) and, optionally, strip it
as it went out the edge routers? Would this really add all that much
to the total bandwidth? I haven't looked at the overhead, but with a
max diameter of, say, 16 it'd be 64 (16x4) bytes plus whatever
overhead per (ICMP) packet, and that's pretty much a worst case. Then
packets could be easily analyzed at the target router and immediately
traced right back to the first "responsible" router very near the
source, probably at the origin site in most cases, bypassing any need
to trace in between.

And yes I mean all the time, not just when there's an attack in
progress.

But if it were stripped back to a regular ICMP packet before it went
out, e.g., a customer's T1 it wouldn't impose any burden on the
customer's last mile bandwidth, other than whatever processing is
involved in the router they're attached to, but I'll assume that's
insignificant from the point of view of that customer under normal
conditions.