Hi all, Thanks Christopher and co-authors for this document. The issues that you have highlighted are critical to ensuring that SOV and other future applications of the RPKI can be deployed in production without becoming serious latent risk to the Internet community and RIR system. As a case in point with respect to your recommendations regarding the RPA, we, AS37271, have announced that we will implement strict SOV (i.e. dropping Invalids) as of 1 April 2019. As things stand today, we will not be making use of the ARIN TAL. We have arrived at this decision primarily because we are not willing to be bound by the indemnification clause (paragraph 7) of the RPA. In our assessment, the potential (and unbounded) liability that we could be exposed to under that clause presents a substantial business risk, and that it is inappropriate given the nature of the service and the role of an RIR in providing authoritative data on the allocation of number resources. I believe problems also exist in other sections of the RPA, and my strong preference would be for ARIN to dispense with it altogether. However, if paragraph 7 were to be removed, we would likely be inclined towards accepting it. Since the RPA imposes substantial obligations and risks on the relying party, I also believe that putting convenience methods (such as click-through acceptance during install of RP software packages) in place will simply encourage users to agree to accept those risks without fully understanding them, thus storing up unintended legal risks for Internet operators in the future. I therefore welcome Job and Nathalie's assertions that there is little interest in the community of RP software developers to implement these "features". This mail is already plenty long enough, but I am happy to discuss in more detail, either on- or off-list, if others are interested. Cheers, Ben Maddison Director Workonline Communications (Pty) Ltd ________________________________________ From: NANOG <nanog-bounces@nanog.org> on behalf of Nathalie Trenaman <nathalie@ripe.net> Sent: 08 January 2019 12:40:33 To: Job Snijders Cc: David Wishnick; Christopher S. Yoo; nanog@nanog.org Subject: Re: Report on Legal Barriers to RPKI Adoption Dear all, After reading the report, I agree with Job it was well written and a must-read for everyone with an interest in RPKI, even outside the ARIN region. Well done! As RIPE NCC is maintaining validator software, I would like to comment on point 2: 2. Developers of RPKI validation software should consider integrating acceptance of ARIN's RPA into their software workflows. ARIN recently enabled this possibility, and developers should deliberate on whether to capitalize on the opportunity. To put it bluntly: item 2 is not going to happen. We've discussed this extensively in the OpenBSD community (who are working on a new RPKI Validation implementation [source: rpki-client]), and concluded that collecting explicit consent to the RPA on behalf of ARIN is undesirable and without precedent. This doesn't exist for DNSSEC, TLS certificates, or IRR data - and we're not going to make an exception for ARIN and encumber each and every OpenBSD or rpki-client(1) installation. I checked the temperature in the room of the other relevant RPKI Validation implementations, and it appears that *nobody* is planning to integrate acceptance of ARIN's RPA into their installation process. I concur that for the RIPE NCC Validator this is something we don't want to implement. Having said that, we do hear from our users that the current setup, where we point users to the ARIN TAL, is not optimal to say the least. Users simply don't understand why the other TALs automatically are installed and the ARIN TAL isn't, so we follow the discussions in the ARIN region closely. Best regards, Nathalie Trenaman RIPE NCC Op 6 jan. 2019, om 17:02 heeft Job Snijders <job@ntt.net<mailto:job@ntt.net>> het volgende geschreven: Dear Christopher, David, NANOG community, Thank you for your research and report. I found the report quite readable (not having a legal background) and well structured. Definitely edifying and worth the read! In this mail I'll reply specifically to a few points from the executive summary (and snip the rest). For those of you who don't want to create a SSRN account here is a copy of the report: http://instituut.net/~job/SSRN-id3309813.pdf On Thu, 3 Jan 2019 at 23:53, Christopher S. Yoo <csyoo@law.upenn.edu<mailto:csyoo@law.upenn.edu>> wrote: Here is a summary of our recommendations: On the ROV side of the equation, the principal legal hindrances have to do with the terms and conditions governing access to the RPKI repository offered by ARIN in its Relying Party Agreement ("RPA"), and in the manner it has employed to ensure the agreement is binding. Regarding ROV: 1. The goal of widespread ROV counsels in favor of ARIN reviewing its current approach to repository distribution, embodied in the RPA. We conclude that two paths would be reasonable. First, ARIN should consider dropping the RPA altogether. This would remove the most significant legal barriers to widespread utilization of the ARIN RPKI repository. I'm happy to see suggestions that dropping the RPA is a viable path. In December 2018 we've measured that around TWENTY percent of the networks deploying RPKI based Origin Validation are missing the ARIN TAL [source: benjojo]. This is an extremely worrying number, as it means that ARIN ROAs are worth far less than RIPE, APNIC, AFRINIC, or LACNIC ROAs. I believe the root cause for ARIN being an outliner is absence of the ARIN TAL in the common RPKI Validation softwares. The absence of the ARIN TAL in software distributions can be directly attributed to the existence of the RPA and applicable contract doctrines. If no changes are made to the current situation, I expect the 20% number to remain the same or even grow, effectively making ARIN's RPKI services unsuitable for the purpose of securing routing. 2. Developers of RPKI validation software should consider integrating acceptance of ARIN's RPA into their software workflows. ARIN recently enabled this possibility, and developers should deliberate on whether to capitalize on the opportunity. To put it bluntly: item 2 is not going to happen. We've discussed this extensively in the OpenBSD community (who are working on a new RPKI Validation implementation [source: rpki-client]), and concluded that collecting explicit consent to the RPA on behalf of ARIN is undesirable and without precedent. This doesn't exist for DNSSEC, TLS certificates, or IRR data - and we're not going to make an exception for ARIN and encumber each and every OpenBSD or rpki-client(1) installation. I checked the temperature in the room of the other relevant RPKI Validation implementations, and it appears that *nobody* is planning to integrate acceptance of ARIN's RPA into their installation process. 4. In addition to the important step ARIN has already taken to enable third-party software developers to integrate RPA acceptance into their software workflows, ARIN should consider reducing the barriers to third-party service development imposed by the RPA's prohibited conduct clause. Specifically, ARIN should consider methods for allowing approved developers to make use of RPKI information as an input into more sophisticated services. 5. Separately, ARIN should consider revising the prohibited conduct clause to allow broader distribution of information created with RPKI as an input for research and analysis purposes. To provide context for the above two paragraphs, at this point in time it's unclear whether BGPMon's WHOIS, NLNOG's IRRExplorer, and the various "RPKI to IRR" services are violating the RPA. I believe it to be highly undesirable for this uncertainty to persist, nor would it be acceptable to require each and every (potential) innovator or researcher to sign contracts with ARIN. ARIN members would be significantly worse off if these services stop using the ARIN TAL. Finally, ARIN members should realize that the majority of ASNs on the Internet are *outside* North America and are not ARIN members. We want *all* networks to be able to honor ARIN RPKI ROAs. BGP hijacks and misconfigurations don't know borders. It's not reasonable to require Dutch, Indian, Russian and Chinese networks to enter into a contractual agreement with ARIN in order to protect the ARIN members. This is why we need things to work properly out of the box, just like was done with DNSSEC. Reform is needed. Kind regards, Job [benjojo]: https://blog.benjojo.co.uk/post/state-of-rpki-in-2018 [rpki-client]: https://medium.com/@jobsnijders/a-proposal-for-a-new-rpki-validator-openbsd-...