<div><div><div><div dir="auto">Dear Christopher, David, NANOG community,</div></div><div dir="auto"><br></div><div dir="auto">Thank you for your research and report. I found the report quite readable (not having a legal background) and well structured. Definitely edifying and worth the read! In this mail I’ll reply specifically to a few points from the executive summary (and snip the rest). </div></div><div><div dir="auto"><br></div><div dir="auto">For those of you who don’t want to create a SSRN account here is a copy of the report: <div><a href="http://instituut.net/~job/SSRN-id3309813.pdf" target="_blank">http://instituut.net/~job/SSRN-id3309813.pdf</a></div></div><div dir="auto"><br></div><div><br><div class="gmail_quote"></div></div></div></div><div><div dir="ltr">On Thu, 3 Jan 2019 at 23:53, Christopher S. Yoo <<a href="mailto:csyoo@law.upenn.edu" target="_blank">csyoo@law.upenn.edu</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_6774095127324751122m_-3874070145712209045m_-2216948204642855459WordSection1"><p class="MsoNormal">Here is a summary of our recommendations:</p></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_6774095127324751122m_-3874070145712209045m_-2216948204642855459WordSection1"><p class="MsoNormal">On the ROV side of the equation, the principal legal hindrances have to do with the terms and conditions governing access to the RPKI repository offered by ARIN in its Relying Party Agreement (“RPA”), and in the manner it has employed to
ensure the agreement is binding. Regarding ROV:</p>
<p class="MsoNormal" style="margin-left:.75in">
<u></u><span>1.<span style="font:7.0pt "Times New Roman"">
</span></span><u></u>The goal of widespread ROV counsels in favor of ARIN reviewing its current approach to repository distribution, embodied in the RPA. We conclude that two paths would be reasonable. First, ARIN should consider dropping the RPA altogether.
This would remove the most significant legal barriers to widespread utilization of the ARIN RPKI repository. </p></div></div></blockquote><div dir="auto"><br></div><div dir="auto"><br></div></div><div><div dir="auto">I’m happy to see suggestions that dropping the RPA is a viable path.</div><div dir="auto"><br></div><div dir="auto">In December 2018 we’ve measured that around TWENTY percent of the networks deploying RPKI based Origin Validation are missing the ARIN TAL [source: benjojo]. This is an extremely worrying number, as it means that ARIN ROAs are worth far less than RIPE, APNIC, AFRINIC, or LACNIC ROAs. I believe the root cause for ARIN being an outliner is absence of the ARIN TAL in the common RPKI Validation softwares. The absence of the ARIN TAL in software distributions can be directly attributed to the existence of the RPA and applicable contract doctrines.</div><div dir="auto"><br></div><div dir="auto">If no changes are made to the current situation, I expect the 20% number to remain the same or even grow, effectively making ARIN’s RPKI services unsuitable for the purpose of securing routing.</div></div><div><div dir="auto"><br></div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_6774095127324751122m_-3874070145712209045m_-2216948204642855459WordSection1">
<p class="MsoNormal" style="margin-left:.75in">
<u></u><span>2.<span style="font:7.0pt "Times New Roman"">
</span></span><u></u>Developers of RPKI validation software should consider integrating acceptance of ARIN’s RPA into their software workflows. ARIN recently enabled this possibility, and developers should deliberate on whether to capitalize on the opportunity.</p></div></div></blockquote><div dir="auto"><br></div><div dir="auto"><br></div></div><div><div dir="auto">To put it bluntly: item 2 is not going to happen.</div><div dir="auto"><br></div><div dir="auto">We’ve discussed this extensively in the OpenBSD community (who are working on a new RPKI Validation implementation [source: rpki-client]), and concluded that collecting explicit consent to the RPA on behalf of ARIN is undesirable and without precedent. This doesn’t exist for DNSSEC, TLS certificates, or IRR data - and we’re not going to make an exception for ARIN and encumber each and every OpenBSD or rpki-client(1) installation.</div><div dir="auto"><br></div><div dir="auto">I checked the temperature in the room of the other relevant RPKI Validation implementations, and it appears that *nobody* is planning to integrate acceptance of ARIN’s RPA into their installation process.</div></div><div><div dir="auto"><br></div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_6774095127324751122m_-3874070145712209045m_-2216948204642855459WordSection1">
<p class="MsoNormal" style="margin-left:.75in">
<u></u><span>4.<span style="font:7.0pt "Times New Roman"">
</span></span><u></u>In addition to the important step ARIN has already taken to enable third-party software developers to integrate RPA acceptance into their software workflows, ARIN should consider reducing the barriers to third-party service development
imposed by the RPA’s prohibited conduct clause. Specifically, ARIN should consider methods for allowing approved developers to make use of RPKI information as an input into more sophisticated services.</p></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_6774095127324751122m_-3874070145712209045m_-2216948204642855459WordSection1"><p class="MsoNormal" style="margin-left:.75in"><u></u></p>
<p class="MsoNormal" style="margin-left:.75in">
<u></u><span>5.<span style="font:7.0pt "Times New Roman"">
</span></span><u></u>Separately, ARIN should consider revising the prohibited conduct clause to allow broader distribution of information created with RPKI as an input for research and analysis purposes.</p></div></div></blockquote><div dir="auto"><br></div><div dir="auto"><br></div></div><div><div dir="auto">To provide context for the above two paragraphs, at this point in time it’s unclear whether BGPMon’s WHOIS, NLNOG’s IRRExplorer, and the various “RPKI to IRR” services are violating the RPA. I believe it to be highly undesirable for this uncertainty to persist, nor would it be acceptable to require each and every (potential) innovator or researcher to sign contracts with ARIN. ARIN members would be significantly worse off if these services stop using the ARIN TAL.</div><div dir="auto"><br></div><div dir="auto">Finally, ARIN members should realize that the majority of ASNs on the Internet are *outside* North America and are not ARIN members. We want *all* networks to be able to honor ARIN RPKI ROAs. BGP hijacks and misconfigurations don’t know borders. It’s not reasonable to require Dutch, Indian, Russian and Chinese networks to enter into a contractual agreement with ARIN in order to protect the ARIN members. This is why we need things to work properly out of the box, just like was done with DNSSEC. Reform is needed.</div><div dir="auto"><br></div><div dir="auto">Kind regards,</div><div dir="auto"><br></div><div dir="auto">Job</div><div dir="auto"><br></div><div dir="auto">[benjojo]: <a href="https://blog.benjojo.co.uk/post/state-of-rpki-in-2018" target="_blank">https://blog.benjojo.co.uk/post/state-of-rpki-in-2018</a></div><div dir="auto">[rpki-client]: <a href="https://medium.com/@jobsnijders/a-proposal-for-a-new-rpki-validator-openbsd-rpki-client-1-15b74e7a3f65" target="_blank">https://medium.com/@jobsnijders/a-proposal-for-a-new-rpki-validator-openbsd-rpki-client-1-15b74e7a3f65</a></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div>
</div>