(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.