Proposal for mitigating DoS attacks

Sat Jul 10 19:02:37 UTC 1999

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 
operation.

I think its a good idea.

Deepak Jain
AiNET 

On Sat, 10 Jul 1999, Leo Bicknell wrote:

> 
> On Sat, Jul 10, 1999 at 12:34:59PM -0500, Jon Green wrote:
> > 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
> communication.
> 
> 	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! :-)
> 
> -- 
> Leo Bicknell - bicknell at ufp.org
> Systems Engineer - Internetworking Engineer - CCIE 3440
> Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
> 
> 