Report on Legal Barriers to RPKI Adoption

Job Snijders job at
Sun Jan 6 16:02:35 UTC 2019

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:

On Thu, 3 Jan 2019 at 23:53, Christopher S. Yoo <csyoo at> 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

Kind regards,


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the NANOG mailing list