Sander, On Mon, May 20, 2013 at 03:57:47PM +0200, Sander Steffann wrote:

...

i) whether these concerns are at least potentially valid (I am convinced they are); The concerns are based on: a) the majority of network operators using rPKI and dropping unsigned or invalid routes

If this is not the case, rpki serves no useful (security) purpose and its implementation is pointless.

b) legislators giving power to law enforcement so that they can force a Dutch entity (the RIPE NCC) to withdraw resources from its members

Wrong. The NCC must (and will, see Axel's recent message) comply with a court order or injunction. Possibly any court order from an EU member state, these are enforceable across borders, TTBOMK. Neither legislation nor law enforcement need be involved, it could be anyone (BREIN, GEMA, a pissed-off individual with money and lawyers) and the right judge. This does not even consider an attack from a non-legal actor, such as a compromised CA.

c) legislators forcing network operators all over the world to keep doing (a) even in the event of abuse by law enforcement

Nobody needs to *force* operators to do anything, they will probably not even notice a route missing from a few hundred thousand or, indeed, care that TPB is no longer reachable unless someone complains loudly.

show how to adjust local-pref based on rPKI while still accepting all routes. This is the network operator's choice!

True, but the security gain is nil to low if routes with invalid/ non-existing ROAs aren't dropped. While some operators may use ROAs to adjust localpref, IMO the "lazy default" and most-widely used implementation will be "drop invalid/missing" and this is the case I base my argument on.

The RIPE NCC will only comply with such requests if a Dutch Court order is served by a Dutch LEA, as well as a binding order from law-enforcement or regulatory authorities that are operating as required under Dutch criminal and administrative law (such as the Public Prosecution Department, the Police, the Fiscal Intelligence and Investigation Service).

The NCC will comply with a valid court order as prescribed by law, or the officers will go to jail for contempt until it does.

If the Dutch legal system gets so bad that they require disproportional measures to be taken by the RIPE NCC then I think we have bigger issues and should move the RIPE NCC to a different country.

It already is (not just in .nl), please remember the various TPB-blocking orders served to ISPs in .nl, .ie, .uk and so on. Moving the NCC would have little effect unless it'd be to a non-EU jurisdiction. The only way to solve this would be to have a distributed trust-anchor in multiple jurisdictions, so that a single point of failure/attack does not exist. I've already indicated that I would support a RPKI policy if this requirement was met, but not until then.

I see no need at this point to take other steps, as I don't see (a), (b) and (c) happen simultaneously. If your concerns should approach reality (laws enabling remote control of the RIPE NCC, laws enforcing a very specific usage of rPKI, etc) then we should take steps. Until there is evidence that those concerns are more than fear, uncertainty and doubt we should not act on them.

And unless you deign to take these concerns seriously and even *consider* steps to mitigate them, I will remain, in opposition, your, Sascha Luck

Sander, On Mon, May 20, 2013 at 04:57:33PM +0200, Sander Steffann wrote:

Please read the legal statement from the NCC I linked to. You are contradicting it. If you have better legal advice than the RIPE NCC's own lawyers then please contact the NCC.

I *have* taken legal advice and it does not contradict the NCC statement at all. According to Regulation 44/2001 http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:32001R0044:EN:NO... a judgment from a member state must be declared enforceable in the member state where it applies. This is pretty automatic, certainly not very complicated. Once the declaration of exequatur is issued, it'll have the same force as a dutch judgment which the NCC will (must) comply with. Note this is civil law, not criminal.

Ah, ok. But since your assumption is invalid (there is no default, and the quick-start examples which would probably be used for such a "lazy default" are completely different from what you assume) then your case isn't very interesting to discuss any further.

There may not be a default *yet*, but there will be and it will be "drop if invalid/missing" because that is much easier to understand ifor the decision-makers than localprefs, metrics, etc. rgds, Sascha Luck

On Mon, May 20, 2013 at 06:23:16PM +0200, Sander Steffann wrote:

I just read the Regulation you mentioned but I fail to see how this would even apply to anything mentioned in this discussion...

That's why I asked a lawyer. In simple words: The NCC is vulnerable to court orders from anywhere within the EU.

...

...

Ah, ok. But since your assumption is invalid (there is no default, and the quick-start examples which would probably be used for such a "lazy default" are completely different from what you assume) then your case isn't very interesting to discuss any further.

[citation needed]

...

There may not be a default *yet*, but there will be and it will be "drop if invalid/missing" because that is much easier to understand ifor the decision-makers than localprefs, metrics, etc.

Ok, now you are making even more unfounded assumptions. Please stop

Well, if you can see the future any better than I, please enlighten us. rgds, Sascha Luck

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

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.

yep

(Or, I am, but there's nothing I can do about that, except take extra care about what government to elect.)

dunno about where you live. but where i vote the choices are not great.

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.

i agree that this is a threat. and that is what i was trying to say in november '11. i hope that you will find that the operational recommendations in draft-ietf-sidr-origin-ops-20.txt helpful to explain why prudent operation ameliorates this issue. folk should not be dropping announcements which are marked NotFound. randy

I keep seeing/hearing this when RPKI is discussed. While strictly true, the way I've understood this, it will also defeat one of the main purposes of RPKI, namely to be able to defend against certain route hijacking or route leak events, where more-specific routes are propagated and accepted.

In order to defend against that type of events, due to the "longest matching prefix always wins, irrespective of BGP attributes" behaviour (which isn't a trait of BGP but of how our routers look up forwarding entries), you cannot have your router configured to install RPKI- invalid prefixes in your forwarding table.

from draft-ietf-sidr-origin-ops-20.txt Sec 5. Routing Policy Operators should be aware that accepting Invalid announcements, no matter how de-preffed, will often be the equivalent of treating them as fully Valid. Consider having a ROA for AS 42 for prefix 10.0.0.0/ 16-24. A BGP announcement for 10.0.666.0/24 from AS 666 would be Invalid. But if policy is not configured to discard it, then longest match forwarding will send packets to AS 666 no matter the value of local preference. As origin validation will be rolled out incrementally, coverage will be incomplete for a long time. Therefore, routing on NotFound validity state SHOULD be done for a long time. As the transition moves forward, the number of BGP announcements with validation state NotFound should decrease. Hence an operator's policy SHOULD NOT be overly strict, and should prefer Valid announcements, attaching a lower preference to, but still using, NotFound announcements, and dropping or giving a very low preference to Invalid announcements. as you point out, that latter is ill advised, and i have a fix in my edit buffer for the next rev as follows: Merely de-preffing Invalids is ill-advised, see previous paragraph. randy

From http://en.wikipedia.org/wiki/Terrorism Common definitions of terrorism refer only to those violent acts which are intended to create fear (terror); are perpetrated for a religious, political or, ideological goal; and deliberately target or disregard the safety of non-combatants (civilians). ... The concept of terrorism may be controversial as it is often used by state authorities (and individuals with access to state support) to delegitimize political or other opponents. In this sense, the American (and other) press have become non-violent terrorists, creating and maintaining public fear for profit. It has been said that the last decade++ of the US Government has done so to further enrich the top 0.001. Analogously, fear is being used to prevent me, as an operator, from protecting my network in a manner that I choose and which only affects my network. Mis-origination occurs daily, and there have been no known abuses of ROAs. Yet there are those who would use unrealistic fear to prevent you and me from using them to improve protection of our networks. Yes, the 'Dutch Court attack' could be used against me. But it is far more likely that some net black hat or idiot will mis-originate my prefix. And yes, like everything else on the Internet, some perp will figure out how to abuse it. But it should be *my* choice whether or not to use a ROA to protect it. When the people with guns and lawyers want to take you off the net, they will, and they have. Two weeks ago, the USG took 7,000 Syrian domains out. The other year 120,000! Ask MegaDownload if they had problems with ROAs. Can we please try to be somewhat realistic about how vulnerable we are to black helicopters? And I am aware of the issues in issuing a ROA. It was I who presented the issues in http://archive.psg.com/110502.ripe-bgpsec-policy.pdf in the RIPE meeting in May 2011, which started all this anti-RPKI noise. The costs for me to issue and maintain a ROA are negligible, and the costs for others to validate my announcements are impressively small. The system was designed with incremental deployment, various levels of reliance, many flavors of disabling in routers, etc. If I wish to trust it, that is *my* prerogative. Please do not place a complicated bureaucracy of fear in my way. Please do not tell me how I must run my network. randy

On Mon, May 20, 2013 at 11:02:20PM +0700, Randy Bush wrote:

Analogously, fear is being used to prevent me, as an operator, from protecting my network in a manner that I choose and which only affects my network. Mis-origination occurs daily, and there have been no known abuses of ROAs. Yet there are those who would use unrealistic fear to prevent you and me from using them to improve protection of our networks.

It doesn't affect just *your* network. I affects *all* networks, and some of them I care more about than yours. Note that I don't propose to delete the source code and to burn the standard docs. Nobody stops you from certifying your own resources and advertising any ROAs you want.

Please do not tell me how I must run my network.

Please don't tell me that I must place the responsibility for the reachability of *my* network into the hands of a vulnerable SPOF. And as for calling me a terrorist - that is a compliment these days, from your lot. best, Sascha Luck

* Sascha Luck

I'm afraid that every objection made to 2008-08 (which proposal failed to achieve consensus) applies exactly the same to this proposal. Rather than re-iterating every argument here again, I refer to the original thread re. 2008-08:

http://www.ripe.net/ripe/mail/archives/address-policy-wg/2011-May/005737.htm...

If I read it correctly, the linked to argument is against RPKI as a whole. However, 2013-04 isn't a question on whether we should do RPKI or not, but whether or not our *existing* RPKI stuff should be extended to include non-members. I think it should. If we're doing something to begin with, we shouldn't be doing it half-arsed. So I support the policy. I've got one question though. What is the rationale for the requirement that «the Internet resources reside within the RIPE NCC service region»? I don't see the reason for this. IMHO, any PI/legacy space issued/maintained by the RIPE NCC should be eligible for certification under this policy, no matter where on (or off!) the planet it's being used. Tore

On Mon, May 20, 2013 at 04:42:35PM +0200, Tore Anderson wrote:

If I read it correctly, the linked to argument is against RPKI as a whole. However, 2013-04 isn't a question on whether we should do RPKI or not, but whether or not our *existing* RPKI stuff should be extended to include non-members.

It's not against rpki as a whole but the implementation as it is. Which was, after 2008-08 failed to achieve consensus, brought in by (close) membership vote which raised some disquiet within the community at the time. It seems that the Board has decided to put this to the community for PI/Legacy space again, the idea is presumably that, if 2013-04 gains community backing, the same can then be done again for PA space since it would "merely harmonise policy". rgds, Sascha Luck

On 20/05/2013 17:55, Sascha Luck wrote:

It seems that the Board has decided to put this to the community for PI/Legacy space again, the idea is presumably that, if 2013-04 gains community backing, the same can then be done again for PA space since it would "merely harmonise policy".

Just to clarify. The board merely declined to extend PI/Legacy RPKI without community guidance. 2013-04 arose spontaneously from the community, it was not "put to the community" by the board (or anyone other than the author). This may seem to be splitting hairs but it is the difference between inviting someone to dinner and feeding them if they turn up at the front door uninvited. Nigel

* Erik Bais

...

I've got one question though. What is the rationale for the requirement that «the Internet resources reside within the RIPE NCC service region»? I don't see the reason for this. IMHO, any PI/legacy space issued/maintained by the RIPE NCC should be eligible for certification under this policy, no matter where on (or off!) the planet it's being used.

The intention is to provide the services for end-users / organizations within the RIPE NCC service region. That the resources itself are used outside the region can't and I think we shouldn't want to restrict.

I'll see how to rephrase that before the review.

IMHO we should not restrict this to end users / organisations within the RIPE NCC service region, as it is legitimate for organisations located outside of the NCC's service region to hold address space registered in the RIPE NCC's registry. I think the natural scope of this policy would be all resources that are maintained in in the RIPE NCC's registry. So how about simply «The Internet resources reside within the RIPE NCC registry»? Tore

Hi Tore,

...

I'll see how to rephrase that before the review.

IMHO we should not restrict this to end users / organisations within the RIPE NCC service region, as it is legitimate for organisations located outside of the NCC's service region to hold address space registered in the RIPE NCC's registry.

I think the natural scope of this policy would be all resources that are maintained in in the RIPE NCC's registry.

So how about simply «The Internet resources reside within the RIPE NCC registry»?

That sounds usable to me Tore. Regards, Erik Bais

Hi, On 12 jun 2013, at 10:47, Dan Luedtke <maildanrl@gmail.com> wrote:

Sander wrote:

...

Yes, securing routing is desperately needed. I totally agree! For this reason alone I support any proposal that gives me as PI holder the chance to sign my routes. +1

Signing contracts without reading fine print is risky..

...

So how about simply «The Internet resources reside within the RIPE NCC registry»? I support that too. Tores off-planet argument made me thinking about

Tore wrote: pictures I've seen from the international space station. Whose region are they in anywhere? They probably change reagions multiple times a day.

Pretty sure they are using dark space. ;) Near earth communication could just random RIR based on dice or whatever. Geographic place of origin isn't all that important to RIR membership, is it? [1] For deep space communication, IP and especially TCP doesn't work so well. [2] Instead, DTN, with a more purposeful Bundle Protocol is used instead. [3, 4] Guess Vint knows more :) I'd like this to work, because either the good or the bad people should get off this planet. (I'd like to think the good are many more, so perhaps best if the bad ones just leave :) ) Best, Martin [1] http://tools.ietf.org/html/rfc5522 [2] http://en.wikipedia.org/wiki/Interplanetary_Internet [3] http://www.mitre.org/work/tech_papers/2010/09_5229/09_5229.pdf [4] http://tools.ietf.org/html/rfc4838

Best regards

Dan

-- Dan Luedtke http://www.danrl.de

http://www.ripe.net/ripe/mail/archives/address-policy-wg/2011-May/005737.htm...

I still don't understand how what this message describes is a change. The concerns also apply to the status quo. I have to use a central database in order to get my prefixes routed by my upstreams. All the best, Dave -- Dave Wilson, Project Manager HEAnet Limited, Ireland's Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin 1 Registered in Ireland, no 275301 tel: +353-1-660 9040 web: http://www.heanet.ie/ fax: +353-1-660 3666

s/If/When/g On Mon, 2013-05-20 at 18:27 +0200, Gert Doering wrote:

When the black helicopters force the RIPE NCC to remove a route6: object, the (former) owner of this object will have issues with his prefix as well...

[ remove / change / reroute / issue ROAs / whatever ] On Mon, 2013-05-20 at 15:57 +0200, Sander Steffann wrote:

When the Dutch legal system gets so bad that they require disproportional measures to be taken by the RIPE NCC then I think we have bigger issues and should move the RIPE NCC to a different country.

+1. Obviously, and not only due to RPKI, a classic deterring safe-guard is required: a) Define what "disproportional" is -- think long and hard about this and cover all ground with clear definitions -- minimize what's left up to interpretation towards zero. b) Create a stand-by infrastructure which will take over when the current system has failed on a). Then communicate to the power-abusers and enemies of a free and open Internet, resilient against centralized censorship flaws: - "This is what will happen. Your attack will fail. We continuously invest resources into research to furthering our guard against your attacks and it will be hugely disproportionately counter-productive of you to even try it." It doesn't get much more bottom-up than this. :-) Best, Martin

Hi Sander, On Mon, 2013-05-20 at 20:37 +0200, Sander Steffann wrote:

Hi Martin,

...

On Mon, 2013-05-20 at 15:57 +0200, Sander Steffann wrote:

...

When the Dutch legal system gets so bad that they require disproportional measures to be taken by the RIPE NCC then I think we have bigger issues and should move the RIPE NCC to a different country.

That is NOT what I wrote. Do not twist what I say for your own (ab)use. Sander

The first line of my email was the regex expression that I applied to what you wrote, s/If/When/g. Let me show you how it works: anticimex@galileo:/tmp$ cat sander_quote.txt On Mon, 2013-05-20 at 15:57 +0200, Sander Steffann wrote:

If the Dutch legal system gets so bad that they require disproportional measures to be taken by the RIPE NCC then I think we have bigger issues and should move the RIPE NCC to a different country.

anticimex@galileo:/tmp$ sed -e 's/If/When/g' sander_quote.txt On Mon, 2013-05-20 at 15:57 +0200, Sander Steffann wrote:

When the Dutch legal system gets so bad that they require disproportional measures to be taken by the RIPE NCC then I think we have bigger issues and should move the RIPE NCC to a different country.

I suggest to get back on topic and address the remainder of my email. Best, Martin

Hi Sander, On Mon, 2013-05-20 at 20:55 +0200, Sander Steffann wrote:

About the "Obviously, and not only due to RPKI, a classic deterring safe-guard is required": I don't find this obvious at all.

Again, what you said (no sed): On Mon, 2013-05-20 at 15:57 +0200, Sander Steffann wrote:

If the Dutch legal system gets so bad that they require disproportional measures to be taken by the RIPE NCC then I think we have bigger issues and should move the RIPE NCC to a different country.

I am really interested in hearing how you think the decision model should work here: - What are "disproportional" measures? - What should be the triggering mechanism for actually moving the RIPE NCC to another country (possibly outside of the EU) ? If you don't see the above "obvious" it appears you haven't follow the thought behind your quote (and mis-quote) through... Please do so. Burying the head in the sand and wishing "disproportional measures" (yet to be defined) will not happen, is not an appropriate approach. Waiting until they do happen (IF they happen! - which I personally see close to 100%) is very bad stewardship of the Internet. In many European countries the past 15 years, we've seen an (never-ending?) erosion of privacy protections and the various interests who see censorship as a solution to $PROBLEM is hardly diminishing in political influence. We've already seen the Dutch police forward a US court order to the RIPE NCC. The (or some) LEA's obviously know how the RIPE NCC works and what it can do with its central repository/record of Who-has-what-IP, and I very much hope it is public knowledge on this list what some LEA's intentions or desires are with regards to centralized control via the RIR's, in particular the RIPE NCC. RPKI in this respect is entirely a non-issue! It's equivalent to TLS to whois.ripe.net, ie. merely the transport - not the data source. Having backups of the central information systems and clear rules of their abuseability, to guard against the [by me, _completely_] expected coming slippery slope, however, is entirely the core issue and a quite obvious thing to implement. Best, Martin

Sander, On Mon, May 20, 2013 at 09:52:06PM +0200, Sander Steffann wrote:

...

- What should be the triggering mechanism for actually moving the RIPE NCC to another country (possibly outside of the EU) ?

Silly things like I described above. I never seriously thought of moving the RIPE NCC to a different country though. The line you quote was meant as hypothetical case.

A realistic solution to this issue is not to have to move the NCC (except in really extreme circumstances), a solution could be to have a distributed trust-root (maybe the other RIRs, maybe trusted 3rd parties or a combination thereof). An operator can then choose to trust some, but not other, roots or accept a majority decision). The important feature is that there is no single point where an attack succeeds. This avoids the fatal flaw that a single trust-root implementation represents and, to an extent, preserves the distributed nature of the DFZ. Indeed, this would remove my *only* point of contention. Kind Regards, Sascha Luck