Sander, On Mon, May 20, 2013 at 07:26:40PM +0200, Sander Steffann wrote:
That's why I asked a lawyer. In simple words: The NCC is vulnerable to court orders from anywhere within the EU.
I understand that if anyone in the EU enters into an agreement with the RIPE NCC then they can bring the RIPE NCC to court if they break the agreement. I still fail to see how this affects the case where governments want to tell the RIPE NCC to take a certain action...
Governments will find a way, as an ultima ratio regum they can send tanks or a drone. That is not really what I am worried about. (Or, I am, but there's nothing I can do about that, except take extra care about what government to elect.) The abuse that I am trying to address here is that someone (be it an IP troll or just a pissed-off individual with money and lawyers will be able to get a civil court order requiring the NCC to withdraw resources and/or certificates and this court order, wherever it is issued will have legal force. Yes, this can happen today, for all I know it has already. However, right now, this will not result in an immediate loss of routing for the prefix(es) concerned. With an rpki implementation where the NCC is the trust root and validation is pretty much automatic, it can and will. To put it in 2 sentences: 1) I don't want a top-down hierarchy imposed on the DFZ, and in its current form this is what rpki certs + ROAs will do. 2) I don't want the NCC (or the ITU or anyone else, for that matter) to be the singular Routing Authority for the entire service region.
In random order: http://www.ripe.net/lir-services/resource-management/certification/router-co... http://www.cisco.com/en/US/docs/ios-xml/ios/iproute_bgp/command/bgp-m1.html#... http://lacnic.net/documentos/lacnicxv/rpki/2BGP-Origin-Validation.pdf http://m.apnic.net/__data/assets/pdf_file/0008/38258/RPKI_Deployment_LACNIC.... http://www.juniper.net/techpubs/en_US/junos12.2/topics/topic-map/bgp-origin-...
And from http://www.cisco.com/en/US/docs/ios-xml/ios/iproute_bgp/configuration/xe-3s/...: "You can allow an invalid prefix to be used as the BGP best path, even if valid prefixes are available. This is the default behavior."
OK, I concede it is not, currently, the default practice. It would be pretty insane too, given that verification is barely implemented anywhere and if it is it's probably not in production...
I'm not the one claiming "There may not be a default *yet*, but there will be". *You* claim to see the future -> *you* provide evidence.
I didn't claim to see the future, but I still think, once widely deployed, invalid or missing ROAs will be dropped - it would be reasonable, seeing as a (hijacked) longer prefix should still win over a shorter one with better localpref. Easiest way to avoid this is to just drop the invalid one. rgds, Sascha Luck