Re: Report on Legal Barriers to RPKI Adoption

[Ben Maddison via NANOG]

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  on behalf of Nathalie Trenaman 

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 mailto:j...@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 
mailto:cs...@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. W

Re: Report on Legal Barriers to RPKI Adoption

[Nathalie Trenaman]

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  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  > 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 

Re: Report on Legal Barriers to RPKI Adoption

[Job Snijders]

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  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

Report on Legal Barriers to RPKI Adoption

[Christopher S. Yoo]

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. 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