<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 12, 2019 at 12:14 PM John Curran <<a href="mailto:jcurran@arin.net" target="_blank">jcurran@arin.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
On 12 Jul 2019, at 12:00 PM, David Farmer <<a href="mailto:farmer@umn.edu" target="_blank">farmer@umn.edu</a>> wrote:<br>
<div>
<blockquote type="cite">...<br class="m_-4787022214495879955m_-7421705351070862885m_-6957213731093441082m_-8907735655722735596m_2637472130810333746gmail-m_5498879303841031385Apple-interchange-newline">
<div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">
To that end, looking at Route Hijacking more generically, what is it? It is announcing a route for IP addresses registered to someone else or using an ASN registered to someone else to announce routes, without the permission of the registrant. Or more simply,
it is one of many ways of disrupting or interfering with a third party's use of services provided to them by ARIN. Where the service provided by ARIN, in this case, is the unique registration of IP addresses and ASNs, which is effectively the primary mission
of and service provided by ARIN and the other RIRs.</div>
</div>
</blockquote>
</div>
<br>
<div>David - </div>
<div><br>
</div>
<div><span class="m_-4787022214495879955m_-7421705351070862885m_-6957213731093441082m_-8907735655722735596m_2637472130810333746gmail-m_5498879303841031385Apple-tab-span" style="white-space:pre-wrap"></span>The problem with that reasoning is that the registrants "use of ARIN’s registration services" generally continues just fine… i.e. they can receive additional resources, update their
number resources entries, etc. Thus, ARIN would likely face challenges in attempting to assert violation of the Prohibited Conduct clause on such a basis. </div>
<div><span class="m_-4787022214495879955m_-7421705351070862885m_-6957213731093441082m_-8907735655722735596m_2637472130810333746gmail-m_5498879303841031385Apple-tab-span" style="white-space:pre-wrap"></span></div>
<div><span class="m_-4787022214495879955m_-7421705351070862885m_-6957213731093441082m_-8907735655722735596m_2637472130810333746gmail-m_5498879303841031385Apple-tab-span" style="white-space:pre-wrap"></span>If the community really wishes that those participating in the ARIN registry commit to specific routing behavior, then such an obligation should be made quite explicit in the RSA.</div></div></blockquote><div><br></div><div>I think the same logic would apply to ARIN's Whois service as well. If Whois were interfered with and taken offline in some way, registrants "use of ARIN’s registration services" generally continues just fine too, i.e. the service that really matters the uniqueness of the resources are unaffected. I think the same applies to RPKI, if the RPKI repository were interfered with or was unavailable for whatever reason the Internet should keep working just fine.</div><div><br></div><div>Using the standard you provide above, it seems to me, the Prohibited Conduct clause is useless and would never apply to anything meaningful.</div><div><br></div><div>So I ask, what kind of disruption or interference would the Prohibited Conduct clause actually apply too? How are they different than routing behavior? And why don't they need to be made equally explicit then? (I don't need or expect an exhaustive list, but a couple of examples would be instructive)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<div><span class="m_-4787022214495879955m_-7421705351070862885m_-6957213731093441082m_-8907735655722735596m_2637472130810333746gmail-m_5498879303841031385Apple-tab-span" style="white-space:pre-wrap"></span>For example – "Address Holder agrees to only announce routing for its own address blocks, or those address blocks for which it has obtained permission of the registrant as listed in
the Internet Number Registry System.” </div>
<div><br>
</div>
<div><span class="m_-4787022214495879955m_-7421705351070862885m_-6957213731093441082m_-8907735655722735596m_2637472130810333746gmail-m_5498879303841031385Apple-tab-span" style="white-space:pre-wrap"></span>It is unclear if such an obligation should exist, and I would advise the community to very carefully consider the implications that would result. </div>
<div><br>
</div>
<div><span class="m_-4787022214495879955m_-7421705351070862885m_-6957213731093441082m_-8907735655722735596m_2637472130810333746gmail-m_5498879303841031385Apple-tab-span" style="white-space:pre-wrap"></span>(If there were a consultation that showed significant support, then the Board of Trustees could consider recommending such an RSA change – note that the latest version of the RSA provides
that ARIN may only modify the RSA in response to a specific change in the law, or after ratification by Member vote… i.e. adding such an obligation would require recommendation of the Board followed by an affirmative ballot of the ARIN Membership.) </div></div></blockquote><div><br></div>Personly, I'd be fine with that.<br><br>However, you seem to be saying that, ARIN and the other RIRs can do nothing to enforce the uniqueness of resources in the context of the Internet? If so, how are the following statements meaningful?<br><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div class="gmail_quote">ARIN’s primary function is the registration of IP addresses and Autonomous System Numbers, collectively referred to as</div><div class="gmail_quote">Internet number resources. These resources are delegated in a way to ensure global uniqueness.</div><div class="gmail_quote"><br></div><div class="gmail_quote"><a href="https://www.arin.net/new/" target="_blank">https://www.arin.net/new/</a></div><div class="gmail_quote"><br></div><div class="gmail_quote">The allocation and registration functions for all non-reserved AS</div><div class="gmail_quote">numbers are handled by the Internet Numbers Registry System in</div><div class="gmail_quote">accordance with policies developed by the Regional Internet</div><div class="gmail_quote">Registries (RIRs) in accordance with their processes.</div><div class="gmail_quote"><br></div><div class="gmail_quote"><a href="https://tools.ietf.org/html/rfc7249#section-2.1" target="_blank">https://tools.ietf.org/html/rfc7249#section-2.1</a></div><div class="gmail_quote"><br></div><div class="gmail_quote">The allocation and registration functions for all non-reserved,</div><div class="gmail_quote">globally unique unicast IPv4 addresses are handled by the Internet</div><div class="gmail_quote">Numbers Registry System in accordance with policies developed by the</div><div class="gmail_quote">RIRs in accordance with their processes.</div><div class="gmail_quote"><br></div><div class="gmail_quote"><a href="https://tools.ietf.org/html/rfc7249#section-2.2" target="_blank">https://tools.ietf.org/html/rfc7249#section-2.2</a></div><div class="gmail_quote"><br></div><div class="gmail_quote">The allocation and registration functions for all non-reserved</div><div class="gmail_quote">globally unique unicast IPv6 addresses are handled by the Internet</div><div class="gmail_quote">Numbers Registry System in accordance with policies developed by the</div><div class="gmail_quote">RIRs in accordance with their processes.</div><div class="gmail_quote"><br></div><div class="gmail_quote"><a href="https://tools.ietf.org/html/rfc7249#section-2.3" target="_blank">https://tools.ietf.org/html/rfc7249#section-2.3</a> </div></blockquote><div class="gmail_quote"><br></div><div class="gmail_quote">Furthermore, then why is it proper for ARIN to involve itself in routing behavior to the extent it currently does?</div><div class="gmail_quote"><br></div><div class="gmail_quote"><a href="https://teamarin.net/2019/05/06/how-does-arin-handle-reports-of-route-hijacking/" target="_blank">https://teamarin.net/2019/05/06/how-does-arin-handle-reports-of-route-hijacking/</a><br></div><div class="gmail_quote"><br></div>Again, "most instances of Route Hijacking are accidental, and the termination of the RSA is not an appropriate or proportional response in these cases, or in other cases the perpetrator does not have an RSA with ARIN. Therefore this is not fundamentally going to fix or eliminate the problem." However, in my opinion, for the Prohibited Conduct clause to have any real meaning, it should apply to at least the most belligerent and egregious examples of Route Hijacking, without having to explicitly discuss routing behavior.<br><br>If ARIN follows the procedures it has already laid out, and there is no resolution, escalating to the Prohibited Conduct clause, with both cure and dispute options made available, seems like a perfectly reasonable next step to me.<div><br>Thanks<div><br><div>.-- <br><div dir="ltr" class="m_-4787022214495879955m_-7421705351070862885m_-6957213731093441082m_-8907735655722735596m_2637472130810333746gmail_signature">===============================================<br>David Farmer <a href="mailto:Email%3Afarmer@umn.edu" target="_blank">Email:farmer@umn.edu</a><br>Networking & Telecommunication Services<br>Office of Information Technology<br>University of Minnesota <br>2218 University Ave SE Phone: 612-626-0815<br>Minneapolis, MN 55414-3029 Cell: 612-812-9952<br>=============================================== </div></div></div></div></div>