Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Proposal for mitigating DoS attacks

  • From: batz
  • Date: Tue Jul 13 21:00:50 1999

On Mon, 12 Jul 1999, Alex Bligh wrote:

:jcgreen@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
existance) .

There are an ample number of security solutions available that 
don't involve blackholing and should only be done in an 
emergency. 

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

AFAIK this could be accomplished by tagging the blackholed
route with no_export and it would not be propagated to external
peers. 


:jaitken@aitken.com 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
:routers.

haha. 

: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@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
:> 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? 


--
batz
Chief Reverse Engineer 
Superficial Intelligence Research Division
Defective Technologies







Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.