Proposal for mitigating DoS attacks

I'd invite comments on an idea I had to mitigate the effect of
Denial of Service attacks. I've outlined it below.

This technique serves to help the packet kiddies achieve their goals.
Why not use the same technique to blackhole the relay networks? Maybe
having their Internet access die a couple times would convince them to
fix their networks.

If I were an ISP, I think I'd have issues with allowing third parties to
blackhole traffic in my own network. I don't think this does anything
to fix the political issues of inter-provider cooperation.. it just
provides an easier technical solution.


I'm not sure the issue is with a third party being able to
block traffic, but rather with who controls that ability. Blocking
has been around in many forms, eg the RBL/MAPS, ORBS and other services.
Technical differences of the problem aside, at least a subset of the
Internet is willing to "give up control" to another organization in
order to realize a greater benefit.

  Having said that, part of the reason these people succeed is
that there is a single, well known point of control. If an address
is on the RBL it is fairly easy to go to one point and look it up,
and you know who to contact to get it removed.

  Back to Alex's proposal. The problem here is that if a route is
blocked, the best method you have to track it back is the AS path. Now,
while you may have good relationships with your peers and be able to get
information out of them, you probably do not have good relationships
with ISP's 4-5 AS's down in the food chain. It would not be obvious
where to look, or who to call to answer the question "why is this
network on the list?" It would also not be obvious who to call to get
the "victim" network removed if it were placed there in error. In
essence, this returns us to the situation we have today with poor

  I have to wonder if a centralized database for this sort of
thing could work. Like the RBL BGP feed, there would be a "Bad
IP Things" feed (the BIT Bucket Feed? :-). It would come from a single
ASN, and anyone who wants to participate would peer with that AS. In
order to make it real time, member networks would go through some
"approval" process that would allow them to add entries to this via a
web or e-mail based system in "real time". Every entry would be logged
with when it was entered, who entered it, and so forth in a single place
that is easy to query.

  Having this centralized database might also lead to other
interesting results, like scanning for patterns (repeat offenders,
attacks from different IP's that always happen at the same time) that
would help shut down the real offenders.

  It's an interesting idea, all in all. I give it a one in
five chance of going somewhere, which by Internet standards is pretty
good! :slight_smile:

I could have read too little/too much into the original proposal, but it
was my understanding that providers would only be able to blackhole
routes in their _OWN_ announcement. I.e. "Don't send traffic to my host
a.b.c.d". Which would in turn pass through that provider's upstreams to
their peers.

My understanding is that when the originator of the announcement decides
they want to see traffic to that host again, they will just withdraw the
announcement. He specifically stated that this is to supplement a system
of already good peer/customer filters as an added feature, not a new
function. Think of it as one's own blackhole.

Therefore, customer "A" can blackhole yahoo or customer "B" or another
customer on another network because their upstream is already practicing
very good peer/customer filters.

At the peer level I see this as a difficult thing to police, with many
downstream customers announcing their routes through multiple providers.
For example I can think of a few networks I have seen that buy transit
from a company we peer with, who in turn also buys transit from a company
we peer with. It is very hard to keep prefix/address filters accurate for
an organization like this.

I think its great from a customer/transit provider level, however, I don't
know of any transit providers that do prefix length filtering on their
customer announcement. (if they do announcement filtering at all). So (in
theory) one could announce the /32s of all the addresses in a /24 (less
the one to be blackholed) today and achieve the same effect with their
provider. This is of course, a much more BGP/router memory intensive

I think its a good idea.

Deepak Jain