(some consolidated comments) 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.
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. Now, while you may have good relationships with your peers and be able to get information out of them, you probably do not have good relationships with ISP's 4-5 AS's down in the food chain. It would not be obvious where to look, or who to call to answer the question "why is this network on the list?" It would also not be obvious who to call to get the "victim" network removed if it were placed there in error. In essence, this returns us to the situation we have today with poor communication.
jaitken@aitken.com said:
if I as an attacker can find a way to generate thousands of these "victim" routes,
These miss the point. Only the victim (or their ISP) can put themselves on the list. Everyone else applies the same route filtering as they would normally (i.e. people can already abuse BGP to put third parties on the list, and this thus suffers from the same weakness as normal BGP (but no more) in terms of unauthenticated adverts). It provides equivalent functionality to letting originators of blocks put "temporary holes" in that advert. Also, please note that blocking the traffic (temporarilly) *helps* you track the perpetrator, as you can (a) see all the traffic sent to the loopback interface simply, and (b) tracing it is *less* time critical as your network doesn't melt in the mean time. This is not proposed as an alternative to traceability - they work hand in hand. I obviously have some rewording to do to make this clear. 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. 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. 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. -- Alex Bligh GX Networks (formerly Xara Networks)