Proposal for mitigating DoS attacks

batz batsy at
Wed Jul 14 02:15:35 UTC 1999

On Mon, 12 Jul 1999, Alex Bligh wrote:

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

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
existance) .

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

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
Defective Technologies

More information about the NANOG mailing list