<div><div><div><div dir="auto">Dear ARIN Board of Trustees, staff, and community!</div></div><div dir="auto"><br></div><div dir="auto">Reviving an old thread, I’d still like this to be resolved :-)</div><div dir="auto"><br></div><div dir="auto">It is my understanding that the ARIN RPKI TAL currently is a hot topic for the Board of Trustees. I can see a lot of effort is being put in to get to a point to make a fully informed decision, which I appreciate. My hope is that - somehow - the ARIN RPKI TAL can become more like other public key files which we embed in our systems to improve our lives.<br></div><div dir="auto"><br></div><div dir="auto">I shot a video to illustrate some analogies I see between DNSSEC, TLS, Signify, and RPKI. The purpose of the video is to show that you can install and boot a fully functional operating system without agreeing to anything that resembles something along the lines of the ARIN RPA.</div><div dir="auto"><br></div><div dir="auto">Video link: <a href="https://youtu.be/oBwAQep7Q7o" target="_blank">https://youtu.be/oBwAQep7Q7o</a> (11 minutes)<br></div><div dir="auto"><br></div><div dir="auto">Kind regards,</div><div dir="auto"><br></div><div dir="auto">Job</div></div></div><div><div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 30 Jan 2017 at 17:42, Job Snijders <<a href="mailto:job@ntt.net" target="_blank">job@ntt.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear all,<br>
<br>
For many years now, the publication of ARIN's cryptographic RPKI<br>
materials has been a point of contention. See [1], [2], [3], and [4] as<br>
examples of the ongoing discussion.<br>
<br>
Third parties who wish to validate BGP route announcements to protect<br>
their ARIN-region-based customers and partners, or to use RPKI data in<br>
provisioning processes (such as prefix-filters generation), must<br>
(implicitly) agree to the "Relying Party Agreement".<br>
<br>
>From <a href="https://www.arin.net/resources/rpki/tal.html" rel="noreferrer" target="_blank">https://www.arin.net/resources/rpki/tal.html</a>:<br>
<br>
"ARIN publishes all Certificates, Certificate Revocation Lists<br>
(CRLs), and RPKI-signed objects in its Resource Public Key<br>
Infrastructure (RPKI) Repository. The ARIN Repository is available<br>
to anyone under the terms and conditions in the Relying Party<br>
Agreement."<br>
<br>
These materials are intended to be used by both ARIN members as well as<br>
non-ARIN affiliated organisations (who might not even have a presence in<br>
the ARIN region).<br>
<br>
What stands out to me is that (as example) the RIPE NCC RPKI Validator<br>
ships with materials from all the RIRs, except ARIN. The RPKI Validator<br>
is a commonly used software package to interact with the RPKI.<br>
<br>
<a href="https://github.com/RIPE-NCC/rpki-validator/tree/master/rpki-validator-app/conf/tal" rel="noreferrer" target="_blank">https://github.com/RIPE-NCC/rpki-validator/tree/master/rpki-validator-app/conf/tal</a><br>
(notice that LACNIC, AfriNIC, APNIC, RIPE NCC are all there)<br>
<br>
As such, the RPKI Validator (out of the box) is not complete. I<br>
attribute this to ARIN's RPA. This phenomenon puts a burden on every<br>
organisation wishing to use RPKI.<br>
<br>
I view this as a shortcoming of the ecosystem and detrimental to our<br>
efforts maintain a secure routing system.<br>
<br>
Of course any party can read the RPA and (if they agree) download the<br>
ARIN TAL and add it to their RPKI Validator installation, but I strongly<br>
prefer an ecosystem which out-of-the-box is operating in a secure mode.<br>
I'd argue that ARIN has an obligation to its members to make these<br>
materials unencumbered by legal constraints and freely available to<br>
anyone.<br>
<br>
A comparison can be drawn with DNSSEC: ICANN (through the IANA) go above<br>
and beyond to publish the DNSSEC materials required for validation, and<br>
ensure distribution as widely as possible: <a href="https://www.iana.org/dnssec/files" rel="noreferrer" target="_blank">https://www.iana.org/dnssec/files</a><br>
The strategy is described here:<br>
<a href="http://data.iana.org/root-anchors/draft-icann-dnssec-trust-anchor.html" rel="noreferrer" target="_blank">http://data.iana.org/root-anchors/draft-icann-dnssec-trust-anchor.html</a><br>
Note that there is no mention of "Agreement" or "Indemnification".<br>
Imagine DNSSEC without trivial availability of public keys: it wouldn't<br>
work.<br>
<br>
I'd like to request that we revisit the topic of the RPKI TAL Relying<br>
Party Agreement, with the goal to make these cryptographic materials<br>
freely available in such a way that they can be bundled with software<br>
distributions. When ARIN's TAL can be bundled freely, I anticipate more<br>
innovation in the secure routing problem space. RPKI can play a<br>
significant role in not only as a defense mechanism, but also as part of<br>
provisioning processes. Unlimited distribution of the RPKI TALs is key.<br>
<br>
I consider the limited availability of the ARIN TAL a showstopper for<br>
global RPKI deployment.<br>
<br>
Kind regards,<br>
<br>
Job Snijders<br>
<br>
[1]: <a href="http://seclists.org/nanog/2016/Feb/84" rel="noreferrer" target="_blank">http://seclists.org/nanog/2016/Feb/84</a><br>
[2]: <a href="http://seclists.org/nanog/2014/Dec/77" rel="noreferrer" target="_blank">http://seclists.org/nanog/2014/Dec/77</a><br>
[3]: <a href="http://packetpushers.net/rpki-bgp-security-hammpered-legal-agreement/" rel="noreferrer" target="_blank">http://packetpushers.net/rpki-bgp-security-hammpered-legal-agreement/</a><br>
[4]: <a href="http://markmail.org/message/ycbijxzgw24je5zn" rel="noreferrer" target="_blank">http://markmail.org/message/ycbijxzgw24je5zn</a><br>
</blockquote></div></div>
</div>
</div>