On Tue, Sep 25, 2018 at 09:17:56PM +0000, John Curran wrote:
On 25 Sep 2018, at 5:04 PM, Job Snijders <job@ntt.net> wrote:
It would be informative to know how many organizations potentially have concerns about the indemnification clause in the RPA but already agree to indemnification via RIPE NCC Certification Service Terms and Conditions.
This seems a matter of personal curiosity that perhaps distracts from the problem at hand: the ARIN TAL is less widely deployed than the other TALs.
I would have to disagree regarding whether question of indemnification is a simply a distraction… It has been raised by the operator community multiple times, and in fact, you indirectly reference the same issue by quoting a sentence in the write-up within your post -
I quote Ben's assessment:
"""Using the data, we can also see that the providers that have not downloaded the ARIN TAL. Either because they were not aware that they needed to, or could not agree to the agreement they have with it.”"
I believe that you correctly characterize the situation; i.e:
1) Either they were not aware they needed it (note this is trivial to fix with outreach/education and requires skills well within the range of anyone who is going to be doing routing validation based on RPKI data), or
My assessment (based on the data Ben collected) is that the current outreach & education are failing to accomplish the goal of widely distributing the ARIN TAL, and I fear this may get worse over time.
2) They could not agree to ARIN RPA agreement (for which the most cited reason is the indemnification clause, but perplexing given agreement to other indemnification clauses such as RIPE’s Certification services.)
It may make sense to associate an implicit agreement (or perhaps a license?) with the ARIN TAL to limit risks to the ARIN organisation. "Use at your own risk"-style clauses are common and acceptable. In section 5 ("prohibited conduct") of the RPA I read: "You shall not, directly or indirectly, disclose, share, divulge, link to, rebroadcast, provide access to or in any other way make available the TAL to any third party, except as permitted by the ORCP Service Terms." I believe this prevents OpenBSD, Cisco, Juniper, etc... from shipping their operating system with a copy of the ARIN TAL, and as far as I understand is the reason that RIPE NCC's RPKI Cache Validator and the NLNetLabs RPKI Validator don't include the ARIN TAL either.
Further analysis and characterization of those not using the ARIN TAL would help enormously in understanding which of the scenarios above is dominant, and prioritize efforts for addressing the situation.
I'd like to frame the discussion in context of what software developers and distributors can do to be able to include the ARIN TAL (by default) rather than focus on getting thousands of organisations to separately download & install a TAL file. The latter approach doesn't scale. We're both at NANOG next week, I'd love to sit down and have a cup of coffee. Kind regards, Job