On Thu, Sep 30, 2004 at 04:47:30PM -0400, Mark Kasten wrote: > Richard A Steenbergen wrote: > > >That said, it is still absolutely silly that we can't standardize on a > >globally accepted blackhole community. A provider with many transit > >upstreams who wishes to pass on blackhole routes for their customers could > >quickly find themselves with some very messy configs and announcements > >trying to get everyones' specific blackhole community in place. I know > >we've all been tossing this idea around for a number of years, but if it > >hasn't been done already will someone please get this put into a draft > >already. > > > > The problem with this is authentication. I can authenticate prefixes my > customers advertise me (as much as currently possible anyway). I can't > authenticate a prefix coming in from a peer that is not filtered. If an > ISP were to accept any prefix with 65535:666 as a triggered blackhole, > how do you trust that? As much as I agree that a global blackhole > community would be nice, that's a big gotcha with potential liability > attached.
You can't authentication a prefix coming in from a peer that says to route a /24 to them any better or any worse. What difference does it make if you route the traffic to them and they blackhole it, or if you blackhole it locally based on their routing information? If it is a leak or a malicious route, you track it down and plug it the same way you do with an existing route that doesn't have the blackhole community set. I'm not saying that those methods are perfect by any means, but adding a global blackhole community at least changes nothing from the status quo. -- Richard A Steenbergen <[EMAIL PROTECTED]> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
