As many of you know, the prospects for widespread RPKI adoption grew more promising in 2018. Cloudflare issued route origin authorizations ("ROAs") to cover 25% of its prefixes, including its 1.1.1.1 resolver and DNS servers. NTT began treating RPKI ROAs as if they were IRR route(6)-objects. Google announced its intention to begin filtering routes in early 2019. The Mutually Agreed Norms for Routing Security now has over 100 network operators signed on. Still, as 2019 begins, many worry that legal issues are hindering RPKI adoption. This is especially true for North American networks, which have a comparatively low percentage of IPv4 space covered by ROAs, and whose ROAs are comparatively underutilized by parties using RPKI-based route origin validation ("ROV") to inform their routing decisions. My coauthor (David Wishnick) and I have spent the past year delving into the legal issues surrounding RPKI. Today, we are publicizing our report on how the network operator community should address these issues. It is available here<https://ssrn.com/abstract=3308619>. If you are interested in the future of routing security, we encourage you to read it (or its Executive Summary). We've tried to keep the legalese to a minimum. RPKI was a major topic of discussion at NANOG 74 and ARIN 42 in Vancouver. Going forward, we expect to continue a fruitful dialogue about how the network operator community can reduce the legal barriers to RPKI adoption. 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. Second, because the legal risks faced by ARIN in an RPA-free world are ultimately uncertain, it would also be reasonable for ARIN to maintain the RPA for the purposes of contractually allocating risks to the parties best positioned to reduce and mitigate them. If ARIN keeps the RPA, ARIN should consider removing the RPA's indemnification clause, instead relying solely on the RPA's disclaimers of warranties and limitations of liability, or at least reducing the indemnification clause's scope to eliminate the problem of moral hazard. 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. 3. The network operator community and ARIN should broadly publicize ARIN's policy of revising various RPA clauses for government entities that are prohibited from agreeing to them. 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. 6. As a general alternative, the Internet community should consider whether to develop a separate corporate entity that would be responsible for operational aspects of RPKI repository provision. That corporation could conduct such activities for the North American region, or on a worldwide basis. Regarding the ROA-issuance side of the equation, the principal legal obstacles stem from the terms and conditions found in ARIN's Registration Services Agreement ("RSA"), Legacy Registration Services Agreement ("LRSA"), and RPKI Terms of Service. Regarding these, the report recommends the following: 1. ARIN should consider adopting a pathway to provide RPKI services that would explicitly refrain from altering the existing balance of property and transferability rights associated with IP address allocations. 2. The network operator community and ARIN should broadly publicize ARIN's policy of revising certain RSA/LRSA and RPKI Terms of Service clauses for government entities that are prohibited from agreeing to them. ARIN should also begin presenting the RPKI Terms of Service to newly-onboarded members alongside their RSA/LRSA, so that organizations spend less time dealing with legal issues overall. Separately, the report recommends that the network operator community consider whether to encourage companies and the federal government to include RPKI adoption in procurement best practices or requirements. In tandem with recommendations designed to encourage adoption, the report also makes two recommendations concerning operational readiness for widespread RPKI deployment. Specifically: 1. To reduce any legal risks associated with RPKI, the network operator community should focus on adopting operational best practices. No system is 100% reliable across all contingencies; as a result, operators should prepare for outages and other headaches. RPKI implementations should be resilient in the face of such contingencies. 2. The five RIRs should work to ensure readiness for widespread RPKI adoption and strive to publicize deeper details on their service-level intentions to the Internet community. This research is supported by NSF Award No. 1748362. The contents of the report represent our independent views, not those of the NSF. Any mistakes, of course, are also ours alone. Christopher S. Yoo John H. Chestnut Professor of Law, Communication, and Computer & Information Science Founding Director, Center for Technology, Innovation and Competition University of Pennsylvania Law School 3501 Sansom St. Philadelphia, PA 19104-6204 (215) 746-8772 (o) (215) 573-2025 (f) csyoo@law.upenn.edu<mailto:csyoo@law.upenn.edu> http://www.law.upenn.edu/faculty/csyoo/ For more information on the Center for Technology, Innovation and Competition, see https://www.law.upenn.edu/institutes/ctic/.
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> 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-...
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> 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 <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 <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-... <https://medium.com/@jobsnijders/a-proposal-for-a-new-rpki-validator-openbsd-rpki-client-1-15b74e7a3f65>
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-...
participants (4)
-
Ben Maddison -
Christopher S. Yoo -
Job Snijders -
Nathalie Trenaman