Proposal for mitigating DoS attacks
amb at gxn.net
Mon Jul 12 10:10:29 UTC 1999
(some consolidated comments)
jcgreen at netins.net 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
jaitken at aitken.com 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 ai.net 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 aitken.com said:
> 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 ai.net 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
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.
GX Networks (formerly Xara Networks)
More information about the NANOG