North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: Proposal for mitigating DoS attacks
- From: batz
- Date: Tue Jul 13 21:00:50 1999
On Mon, 12 Jul 1999, Alex Bligh wrote:
:> 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.
:email@example.com 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
:> 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.
:> 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