Report on Legal Barriers to RPKI Adoption

Thu Jan 3 20:51:56 UTC 2019

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 at law.upenn.edu<mailto:csyoo at 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/.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20190103/82ae6154/attachment.html>