Hello, Am 08.10.2014 um 16:42 schrieb Job Snijders:
If you think this is a terrible idea and want to express all that is wrong with it, tell me that too, I can take it.
I support the RTBH idea. I also set up https://wiki.rtbh.me/ for this some time ago and there is also a discuss mailing list where already 65 people are subscribed. Currently there is not much discussion on the list, but you all can change this ;-) Also there is no other content besides the mailing list in the wiki right now. I have removed it because somebody thought that it may be confusing for some people on the list as he wanted to use it for a general RTBH discussion instead of my project. I will try to restore it in the next days...
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.
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. 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.
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.
Both approaches have their downsides: you can make any AS or AS-SET a member of your AS-SET and thereby gain a degree of control on the RTBH server, and for $500/year you can register any route-object you want in RADB.
Allowing ASN to blackhole a prefix based on AS sets is dangerous from my point of view. In the RIPE database you can add any AS to your AS set without verification. Ok, it doesn't make much difference because most IP transit providers also filter on the AS set, but a worldwide announced /24 prefix is much more visible than a /32 blackhole route that is only announced to the participants. My idea was that an ASN can only announce more specifics prefixes (not just /32) from officially registered routes. Downstream ASN should also be able to define their upstream ASN who may blackhole their prefixes if they do not set up their own session to the RTBH route servers. Most IP transit providers have an RTBH service for their customers that these downstream ASN could use. Usually they do not offer such a service for peers. This is the useful part here. 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 ;-)
Might I suggest an alternative approach, without central validation or need for a clearing house:
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.
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? Regards, Chris -- Individual Network Berlin e.V. : support@in-berlin.de : vorstand@in-berlin.de Tel +49-30-45494343 ::: Fax +49-30-45494344 ::: Web https://www.in-berlin.de/ IN-Berlin e.V. : Christian Seitz (1. Vors.) : Lehrter Str. 53 :: 10557 Berlin Amtsgericht Charlottenburg 95 - VR 15669 Nz ::::::: USt.Ident-Nr. DE188894648