Proposal for mitigating DoS attacks

Alex Bligh amb at
Mon Jul 12 10:10:29 UTC 1999

(some consolidated comments)

jcgreen at said:
> 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.

Leo Bicknell write:
> 	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.

jaitken at said:
>  if I as an attacker can find a way to generate thousands of these
> "victim" routes,

These miss the point. Only the victim (or their ISP) can put
themselves on the list. Everyone else applies the same route
filtering as they would normally (i.e. people can already abuse
BGP to put third parties on the list, and this thus suffers
from the same weakness as normal BGP (but no more) in terms
of unauthenticated adverts). It provides equivalent functionality
to letting originators of blocks put "temporary holes" in that

Also, please note that blocking the traffic (temporarilly) *helps*
you track the perpetrator, as you can (a) see all the traffic
sent to the loopback interface simply, and (b) tracing it
is *less* time critical as your network doesn't melt in
the mean time. This is not proposed as an alternative to
traceability - they work hand in hand.

I obviously have some rewording to do to make this clear.

deepak at sums this up when he writes:
> 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. 


jaitken at said:
[directed broadcast]
> This entire approach relies on many of those same people to perform
> adequate route filtering to avoid far worse consequences.

Thankfully BGP speakers are more clueful than most people running

However, the entire system currently is vulnerable to *any*
exploitation of unfiltered route announcements (sadly) - this
is no less vulnerable to that, and any fix would fix this too.

deepak at said:
> 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).

Hmmm - we do for one! Many block all routes longer than /24. Now
what I'm planning to do (as gated or some versions of it appear
unable to set communities) is interpret any /32 as something which
should be blackholed.

Alex Bligh
GX Networks (formerly Xara Networks)

More information about the NANOG mailing list