On Fri, Jul 12, 2019 at 12:14 PM John Curran <[email protected]> wrote:
> On 12 Jul 2019, at 12:00 PM, David Farmer <[email protected]> wrote: > > ... > 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. > > > David - > > 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. > 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. > 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. Using the standard you provide above, it seems to me, the Prohibited Conduct clause is useless and would never apply to anything meaningful. 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) > 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.” > > It is unclear if such an obligation should exist, and I would advise the > community to very carefully consider the implications that would result. > > (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.) > Personly, I'd be fine with that. 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? ARIN’s primary function is the registration of IP addresses and Autonomous System Numbers, collectively referred to as Internet number resources. These resources are delegated in a way to ensure global uniqueness. https://www.arin.net/new/ The allocation and registration functions for all non-reserved AS numbers are handled by the Internet Numbers Registry System in accordance with policies developed by the Regional Internet Registries (RIRs) in accordance with their processes. https://tools.ietf.org/html/rfc7249#section-2.1 The allocation and registration functions for all non-reserved, globally unique unicast IPv4 addresses are handled by the Internet Numbers Registry System in accordance with policies developed by the RIRs in accordance with their processes. https://tools.ietf.org/html/rfc7249#section-2.2 The allocation and registration functions for all non-reserved globally unique unicast IPv6 addresses are handled by the Internet Numbers Registry System in accordance with policies developed by the RIRs in accordance with their processes. https://tools.ietf.org/html/rfc7249#section-2.3 Furthermore, then why is it proper for ARIN to involve itself in routing behavior to the extent it currently does? https://teamarin.net/2019/05/06/how-does-arin-handle-reports-of-route-hijacking/ 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. 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. Thanks .-- =============================================== David Farmer Email:[email protected] Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 ===============================================
_______________________________________________ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
