Re: Report on Legal Barriers to RPKI Adoption

[Ben Maddison via NANOG <nanog () nanog org>]

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-rpki-client-1-15b74e7a3f65