ARIN's RPKI Relying agreement

John Curran jcurran at
Thu Dec 4 17:39:06 UTC 2014

On Dec 4, 2014, at 11:35 AM, Christopher Morrow <morrowc.lists at> wrote:
> ...
> Maybe it would be helpful for the ARIN Counsel to document in a more
> public way (than the RPA) what the concerns are and how that
> translates into 'different risk than the publication of whois data' ?

This is apparently being discussed on two different lists (PPML and 
NANOG) at the same time, so apologies for the cross-posting...

The reason that the RIRs have disclaimer of warranty and indemnification clauses 
for RPKI services is actually quite simple: despite striving to deliver highly available 
RPKI services, you are supposed to be using best practices in use of the service, 
and this include recognizing that failures can occur and such should not result in 
operation impact (i.e. exactly the opposite of your “my routing decisions are affected 
and breakage happens” statement in your prior email.)   Specifically, your RPKI 
deployment approach should be following known operational best practices for 
RPKI, such as those in RFC 7115 / BCP 185, "Origin Validation Operation Based 
on the Resource Public Key Infrastructure (RPKI)” - 
   “… Local policy using relative preference is suggested to manage the uncertainty 
    associated with a system in early deployment; local policy can be applied to
    eliminate the threat of unreachability of prefixes due to ill-advised certification 
    policies and/or incorrect certification data. “

Note that the claims that could ensue from an operator failing to follow best practices
and then third-parties suffering an major operational outage is likely to be large and
extremely protracted, with potential for endangering the registry itself due to the nature 
of litigation and its requirement to actually go to all the way to trial in order to be able 
to then introduce evidence and prove that the RPKI services were operating properly 
at the time of the event.  If the RIRs did not seek indemnification for use of the RPKI 
services, then all of their other registry services could potentially be put at risk due to 
the need to defend errant litigation, even presuming perfect RPKI service delivery.  
Undertaking that risk to the other services that everyone else presently rely upon 
(Whois, reverse DNS) is not reasonable particularly during this time when the RPKI 
parties are supposed to be deploying via conservative routing preference practices.

ARIN does make the expectations very clear and explicit in its agreements, and that
is different from the other RIRs.  Again, are the other RIR RPKI non-warranty and 
indemnification clauses equally problematic for you, or is the fact that they are 
implicitly bound address your concerns?  This has come up before on the NANOG 
mailing list (see attached) but it was unclear if the outcome was an expectation that
all RIRs should drop these clauses, or that ARIN should make agreement to them 
be implicit.


John Curran
President and CEO

> ===
> Begin forwarded message:
> Subject: Re: APNIC RPKI TAL agreement
> From: John Curran <jcurran at>
> Date: October 16, 2014 at 7:30:48 PM EDT
> Cc: Wes George < at>, Randy Bush <randy at>, "Geoff Huston" <gih at>
> To: Michael Sinatra <michael at>
>> On Oct 16, 2014, at 3:19 PM, Michael Sinatra <michael at> wrote:
>> Hi John:
>> At NANOG 62, you mentioned that APNIC has a similar agreement as ARIN to
>> use its trust-anchor locator (TAL), but that it is not a click-through
>> agreement like ARIN's.  I have searched using basic google-foo for this
>> agreement, and have also looked on APNIC's certificate rsync server
>> (which also has an HTTP interface) and I can't find it.  Can you, or any
>> other recipient of this message who is familiar with the APNIC
>> agreement, point me in the right direction?
> Michael - 
> Review <> 
> wherein there is a limitation of liability and requirement that a recipient of any digital certificate 
> will indemnify APNIC against any and all claims by third parties for damages of any kind arising 
> from the use of that certificate. (last two bullets)
> /John
> John Curran
> President and CEO
> ===

More information about the NANOG mailing list