Proposal for mitigating DoS attacks
batsy at vapour.net
Wed Jul 14 02:15:35 UTC 1999
On Mon, 12 Jul 1999, Alex Bligh wrote:
: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.
Dissappearing someones network as a security measure is very effective
but is also an attack unto itself. I brought this up this week over
at BlackHat Briefings and referred to it as a DoE Attack (denial of
There are an ample number of security solutions available that
don't involve blackholing and should only be done in an
: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.
Depending on how far it is blocked. If it is only blackholed locally,
a traceroute from a looking glass is very effective.
: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.
AFAIK this could be accomplished by tagging the blackholed
route with no_export and it would not be propagated to external
: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.
Has anyone actually looked at automaticly parsing their bgp logs
with something akin to an IDS so that if something like this
comes over the wire, sirens will go off?
Chief Reverse Engineer
Superficial Intelligence Research Division
More information about the NANOG