|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Proposal for mitigating DoS attacks
On Mon, 12 Jul 1999, Alex Bligh wrote: :[email protected] 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. :[email protected] 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. :[email protected] 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. : :[email protected] 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
|