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. My understanding is that when the originator of the announcement decides they want to see traffic to that host again, they will just withdraw the announcement. He specifically stated that this is to supplement a system of already good peer/customer filters as an added feature, not a new function. Think of it as one's own blackhole. Therefore, customer "A" can blackhole yahoo or customer "B" or another customer on another network because their upstream is already practicing very good peer/customer filters. At the peer level I see this as a difficult thing to police, with many downstream customers announcing their routes through multiple providers. For example I can think of a few networks I have seen that buy transit from a company we peer with, who in turn also buys transit from a company we peer with. It is very hard to keep prefix/address filters accurate for an organization like this. 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). So (in theory) one could announce the /32s of all the addresses in a /24 (less the one to be blackholed) today and achieve the same effect with their provider. This is of course, a much more BGP/router memory intensive operation. I think its a good idea. Deepak Jain AiNET On Sat, 10 Jul 1999, Leo Bicknell wrote:
On Sat, Jul 10, 1999 at 12:34:59PM -0500, Jon Green 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.
I'm not sure the issue is with a third party being able to block traffic, but rather with who controls that ability. Blocking has been around in many forms, eg the RBL/MAPS, ORBS and other services. Technical differences of the problem aside, at least a subset of the Internet is willing to "give up control" to another organization in order to realize a greater benefit.
Having said that, part of the reason these people succeed is that there is a single, well known point of control. If an address is on the RBL it is fairly easy to go to one point and look it up, and you know who to contact to get it removed.
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.
I have to wonder if a centralized database for this sort of thing could work. Like the RBL BGP feed, there would be a "Bad IP Things" feed (the BIT Bucket Feed? :-). It would come from a single ASN, and anyone who wants to participate would peer with that AS. In order to make it real time, member networks would go through some "approval" process that would allow them to add entries to this via a web or e-mail based system in "real time". Every entry would be logged with when it was entered, who entered it, and so forth in a single place that is easy to query.
Having this centralized database might also lead to other interesting results, like scanning for patterns (repeat offenders, attacks from different IP's that always happen at the same time) that would help shut down the real offenders.
It's an interesting idea, all in all. I give it a one in five chance of going somewhere, which by Internet standards is pretty good! :-)
-- Leo Bicknell - bicknell@ufp.org Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org