[arin-ppml] [EXT] Re: Open Petition for ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation

[David Farmer]

On Fri, May 3, 2019 at 12:10 PM John Curran <jcurran at arin.net> wrote:

>
> In effect:. “Address Holder agrees to only route to the Internet 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.”
>
> Does the reformulation help clarify why the addition of that
> responsibility might be seen by some as rather significant?  If you
> actually intend it to be a meaningful change, then it should include the
> corresponding obligation in clear and uncertain terms.
>
> It’s possible that such a change is reasonable if the community wishes,
> but absent a clear and unified expression of support, ARIN could not
> consider adding such obligations to registry customers.
>

John,

If the community wishes to move forward and add similar language as the
above to the RSA, what is the best way to move forward? The ACSP? I assume
the PDP is not as it is an RSA contract issue and not directly a policy
issue.

Further, if similar language as the above was added to the RSA, then BGP
hijacking effectively becomes a breach of RSA contract and ARIN could
terminate the perpetrator's RSA for cause under section 13b of the RSA and
effect a return of all resources if the breach remains uncured for more the
60 days.  How would a series of repeated non-continuous breach events, none
of which exists for more than 60 days, be handled? Would 13b of the RSA
need to be modified as well to handle this type of repeated
but non-continuous breach?

In any case, the goal would be to cure the breach and bring the other party
into compliance if at all possible, termination is not the primary goal,
cure of the breach is the primary goal. Termination is the last resort and
the result of an uncured breach.

I'll note that such a change in the RSA would create a strong operational
incentive for publication of valid information, with at least some level of
authentication, about the proper origination of prefixes, either through
the use AS Origin in the Registry, the forthcoming updated ARIN IRR, or
through RPKI ROAs. As these are easy ways for the proper resource
registrant to express their intent for someone else to originate their
prefixes.

Thanks

-- 
===============================================
David Farmer               Email:farmer at umn.edu
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
===============================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20190506/956ad51c/attachment.htm>