On Wed, 8 Oct 2014 16:42:38 +0200 Job Snijders <job@instituut.net> wrote:

Just like chicory, personally I don't like it. Yes, Cymru has build a reputation as clearing house for redistribution of security related information. But... (aside from any local safety net filter), it's quite a leap to allow a single entity to inject blackholes for any prefix.

Hi Job, Thanks for your comments. I'm aware of some other projects, including another one, much more elaborate, talked about in another session at NANOG this week. Do note, UTRS does not allow a single entity to inject black holes for any prefix, only a limited number of /32's for their own prefixes. The presentation and the information page I linked to have some additional details.

IXPs could offer BGP or API triggered ACLs which are inserted into the peering fabric and only affect the participant's peering port(s). This way, any blackholing (either correctly applied or malicious) only affects the initator of that blackhole and nobody else. Advantages are that aclserver does not require peers to cooperate with each other and no validation is required.

I've heard of some IXPs recently offering this service, sounds great. It has also been suggested we might talk to ISPs how to RTBH to their customers and see if there was a way for those routes to be passed further along, perhaps to something like UTRS for further dissemination. I'm not sure that would work, but it was an interesting idea too. Thanks for your comments, John

information. But... (aside from any local safety net filter), it's quite a leap to allow a single entity to inject blackholes for any prefix.

Spamhaus has been distributing their DROP list by BGP for years. The world hasn't ended, and I can't recall the last time it had a plausible false positive. http://www.spamhaus.org/drop/ R's, John

On Wed, Oct 08, 2014 at 04:42:38PM +0200, Job Snijders wrote:

There are various flavors at the moment in terms of validation (please correct me if I am wrong): The Polish blackholing project only allows blackholes which fall within the set of prefixes which an ASN originates, the DE-CIX BS service accepts anything that is a subset of your AS-SET.

There is also "dynamic validation" approach: blackhole route is considered valid for injection if and only if there is a covering less-specific route with the best-path pointing to the same exit point as blackhole route. (definition of "exit point" can vary from "next ASn is the same we received blackhole from" to "both as-path and next-hops must be the same and aggregate route must be marked as customer's one"). This approach has its downside too: it requires you to run task-specific bgp speaker. Worse yet, usually you have to write that speaker :) -- In theory, there is no difference between theory and practice. But, in practice, there is.

Hi Christian, On Thu, Oct 09, 2014 at 10:58:05PM +0200, Christian Seitz wrote:

<snip>

Why is there no validation required when this is done by an IXP? "All peers are my customers and I do trust them"? What about private peerings via PNIs?

Validation is not required because the requester can only affect his or her own peering ports. Conceptually the IXP participant sets an ACL, just not on their own ingress routerport but on the egress port just across the crossconnect, this prevents congestion of said crossconnect. Modern switching/routing equipment used in IXPs can do far more then mere L2 switching. Lots of chipsets these days allow you to apply combined layer-3 + layer-2 ACLs, an example would be "Discard traffic if (destination IP is A && destination MAC is B)". The blackhole route is announced to a special network component which I dub the "ACL Server". The ACL Server is operated by the IXP (exabgp + customizations?). The ACL Server takes the prefix and associated origin (origin is a static lookup table based on source IP or ASN, IXPs know who their members are) and then inserts a layer3+layer2 ACL into their switching fabric. If the IXP, on every ingress port, have a ACL that says "drop traffic to this IP if the dest MAC address corresponds with the originator of the ACL request", the ddos traffic doesn't even hit the IXPs backbone, and only affects the peering participant who requested the ACL to be inserted. So the blackhole route only lives inside the IXP's switching fabric so to speak, as an ACL only applicable to the participant itself. Regarding implementation: some IXPs might have to screenscrape/expect to apply ACLs on their switches with clogin, others will just convert the announcement and insert flowspec or sdn rules in the fabric. It is the IXP's job to sanitize the ACL trigger in such a way that it only applies to the peering ports of the participant requesting it. I hope this clarifies a bit. Kind regards, Job

I understand the concerns but it seems to me that there are already plenty of ways for any large government to black hole whatever they want and they do not need UTRS to do so. The only thing stopping (most) governments from doing this regularly are fears of turning the Internet into another arms race. It's a stigma thing like the different between launching the first nuke vs. being the responder. We all know they do a lot of cyber stuff out there but it is mostly behind a veil of deniability. First, if they have access to a tier 1 carrier (or at least enough carriers to make an impact) in their jurisdiction they could just order that carrier to do it with whatever court system (or not) is required. Most large governments also have enough connectivity to bury a route by brute force. The only thing stopping (most) governments from doing this regularly are fears of turning the Internet into another arms race and possibly losing easy access to that resource. We all know they do a lot of cyber crime stuff out there but it is mostly behind a veil of deniability. There has actually been more black hole events that occur by accident or as part of denial of service attacks than government launched. The global routing structure of the Internet has always been highly cooperative and vulnerable to a bad actor at a lot of points. My only real concern with UTRS is designing a system that cannot be gamed or exploited to turn it into a very effective DoS weapon system. I admit that I don't know enough about how it works to make that decision yet. Steven Naslund Chicago IL

Subject: Re: Unwanted Traffic Removal Service (UTRS)

On Thu, 09 Oct 2014 22:58:05 +0200 Christian Seitz <chris@in-berlin.de> wrote:

...

What I do not like at this UTRS idea is that I cannot announce a prefix via BGP. Somebody has to inject it for me. I would like to announce it in real time and not with delay because of manual approval.

While true today, it might not be true for long. It requires code to be written in order to perform the desired verification we want before blindly passing along an announcement. Code we're not motivated to write if there is >insufficient interest in UTRS. Interest is looking good, so the code may soon follow. In other words, this a valid complaint, but it may have a limited life span.

...

One problem that I also see here is that this single entity could be forced by someone (eg. government) to blackhole some prefix. If this ever happens such a project will have to be terminated.

I've heard this once before too. I admit we probably can't provide a satisfactory answer to some who will be so distrustful of government or influence peddling to win them over, but I'll try to offer a response that I hope is >fairly reasonable and satisfies the majority, and presumably any of the actual participants.

There are legal questions, maneuvers and responses that might be interesting to speculate on, but I'll say simply this. Team Cymru, while established and operated within the U.S., is a global organization with team members outside >of the U.S. and we rely heavily on the cooperation of global partners to do what we do. If we could be compelled to announce a black hole by someone, government or otherwise, the cooperation and inherent trust we might have with >the Internet community is probably gone and we are likely finished as an organization. It would be counter to our very existence and so on that basis I hope most would agree is extremely unlikely to occur. Now if someone came up to >me with a gun to my head and said type the equivalent of "ip route foonet mask 192.0.2.1" or die, I might just type it out of self preservation.

...

We also had some DDoS attacks via IPv6. I think it's important to also have such a service for IPv6. Starting with IPv4 is ok and better than nothing, but IPv6 should not be on the roadmap for 2018 ;-)

You are only the second person I've heard from to explicitly state as such. This is actually not terribly hard to do and I'm pretty certain could be done way before 2018. Simple to start, careful and necessary improvements as we >go.

Thanks for your comments Chris,

John