[arin-tech-discuss] [arin-announce] Resource Public Key Infrastructure (RPKI) Now Available to ARIN Customers

[David Farmer]

On 10/15/12 20:04 , John Curran wrote:
> On Oct 15, 2012, at 5:32 PM, Jay Borkenhagen <jayb at braeburn.org> wrote:
>
>> OK, I'll bite:
>>
>> When an ARIN resource holder publishes ROAs in ARIN's RPKI, it is
>> clear that they want the entire RPKI universe to be able to see those
>> ROAs and all the supporting records, to reduce the likelihood that
>> networks around the world will believe hijack attempts.
>>
>> Requiring 'those wishing to validate RPKI information' to click
>> 'accept' or to take any other explicit action only gets in the way of
>> achieving that goal.
>>
>> Therefore: please publish the ARIN TAL openly to maximize the utility
>> of the RPKI to ARIN's resource holders.
>
> Jay -
>
>    It is very important that relying parties are aware and agree
>    to the conditions associated with the RPKI service, and it is
>    equally important that ARIN have a legally valid record of this
>    consent.  It does mean one additional step for relying parties
>    to undertake when setting up their RPKI infrastructure, but it
>    only has to be done once.
>
>    Without a record of consent to the RPKI relying party agreement,
>    ARIN would not be able to offer RPKI services at all.
>
> FYI,
> /John

John,

I recognize ARIN's need for terms and conditions with this, especially 
for entities that don't have any other relationship with ARIN other than 
using the TAL to validate RPKI data.  However, I am also sympathetic to 
Jay's request too.

I'm generally not allowed to agree to terms and conditions on behalf of 
my employer, I'm sure this is common.  I'm sure ARIN has this issue when 
dealing with its providers too.  So, this separate agreement represents 
an extra barrier to implementing RPKI validation for my and in expect 
many other organizations too.

Maybe a middle ground solution could be to package or optionally 
integrated this and other service specific terms and conditions with or 
into the RSA or LRSA, so that they can be reviewed and agreed to all at 
once by an organization if they so desire.  This is a common tactic my 
organization likes to use.  However, it has to be balanced against 
including terms and conditions for service we will never use either.

In particular this agreement has separate clauses for Indemnification 
and Governing Law, Jurisdiction, Etc... differing from those in the RSA 
and LRSA.  If we could just add these service specific clauses into the 
RSA and/or LRSA it might be easier in many situations.  Another possible 
solution could be a version of the agreement that is an addendum to the 
RSA or LRSA, only including the service specific clauses and using the 
general terms and conditions from the RSA or LRSA already in place.

One way or another, I think I'll be able to make something work with 
ARIN, we already have an RSA and LRSA.  But, thinking about this more 
generally, will we need to do a separate similar agreements with each of 
the other RIRs too?  I know you can't speak for the other RIRs, but if 
you generalize this, it becomes a really ugly issue fast.  Wasn't the 
RIR system created to help deal with these kinds of issues?  The idea of 
everyone having to execute agreements with all 5 RIRs just to validate 
the trust seems wrong, and a legal nightmare.  I know my legal counsel 
will not like the idea of doing 4 other agreement, especially from 
around the world.