Re: Report on Legal Barriers to RPKI Adoption

[Nathalie Trenaman <nathalie () ripe net>]

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-rpki-client-1-15b74e7a3f65 
> <https://medium.com/@jobsnijders/a-proposal-for-a-new-rpki-validator-openbsd-rpki-client-1-15b74e7a3f65>