[arin-ppml] RPKI Relying Agreement

[John Curran]

On Dec 5, 2014, at 3:09 PM, William Herrin <bill at herrin.us> wrote:
> From my perspective, we're looking at one of two possibilities here:
> 
> 1. The risk is overblown, ARIN counsel's version of "This product not intended for use as a dental drill." That means: go tell counsel to give you the best options available with publication to anonymous recipients as a core requirement. 
> 
> 2. The risk is correctly assessed. McDonalds scalding coffee just waiting for someone to get burned. Best guess, that means abandon RPKI altogether, seek legislation protecting the publishers of RPKI data or cede the function to a separate organization capable of managing the risk.
> 
> Which is it? Need a sanity check. That means finding precedent: some kind of general publication comparable to RPKI relying party data which has been around long enough to build up a record of litigation.

Bill - 
 
    You’d think that would be a reasonable approach, but legal issues
    generally don’t work that way.  Instead, they hinge on the specific 
    circumstances of the services and the terms under which they are
    provided.  

    Resource certification via RPKI poses a particularly complicated 
    set of circumstances, involving multiple parties and technologies
    which are not in common use today.   Use of RPKI for route origin 
    validation is possible without posing operational risk, but it requires
    attention to numerous operational details (e.g. as per RFC 7115) 
    If there is any production impact due to RPKI usage (e.g. a major 
    financial institution unable to communicate with its business partner, 
    a hospital unable to communicate for telemedicine work, etc.) then 
    the process of determining how the failure occurred will be a highly 
    technical endeavor, and it is not clear that failure on the part of a 
    relying party to implement best practices would be mitigate liability
    of ARIN, the attesting ISP, or any parties in the certification hierarchy
    (even though it is quite clear that the RPKI system is must be used
    with proper attention to the operational configuration details to avoid
    creating more risks than it solves)

    Neither of your two possibilities noted are comparable, as RPKI
    has real benefits but can pose serious operational risks if not done 
    with sufficient care.  Inattentive parties can easily claim that they 
    were impacted as a result of RPKI system issue and untangling the 
    reality when such claims occur is going to be highly problematic.  
    The advantage of a clearly accepted relying party agreement is that
    it makes plain that gaining the benefits of using RPKI resource 
    certification requires specific attention during deployment to avoid 
    creating new dependencies or failure modes and that done correctly
    should result in no operational dependency on the RPKI system - in 
    other words, RPKI provides additional information for better routing
    decisions when available but breakage should not happen otherwise.

    However, from the recent discussion, it is apparent that this explicit
    acknowledgement is seen as a hinderance to RPKI deployment.  
    As I indicated earlier,  we’re now working on changes to provide 
    ready access to ARIN’s TAL (without a click-accept RPA) and 
    switching over to an implicit service agreement instead.  Doing so 
    is a non-trivial activity, with both legal and risk analysis required 
    so that we can bring an informed proposal to the ARIN Board for 
    consideration.  I’ll keep the community informed on any progress
    or developments in this area.

Thanks,
/John

John Curran
President and CEO
ARIN