[ARIN-consult] [ARIN-Suggestions] NEW ACSP 2019.17: RSA Change

[Adam Thompson]

I see it as orthogonal, but YMMV.

I'd very much like the RIRs to have bigger sticks.

However, I don't know of any proposal or idea, current or historical, for said stick(s) that is or has been acceptable to a sufficiently broad cross-section of the membership to get any traction. :-(

(Nor am I about to suggest anything new, even if I had a new idea, as I don't need to get flamed that much this month.)

-Adam

On August 5, 2019 3:54:53 p.m. CDT, David Farmer <farmer at umn.edu> wrote:
>I think you are making my point for me, currently, there aren't even
>theoretical consequences for ignoring the RIR system, even deliberately
>using someone else's allocations on the Internet, let alone using
>bogons.
>If you deliberately use someone else's allocations the RIR system
>currently
>continues to protect your allocations, even though you are thwarting
>the
>system. This is a form of "free-riding", you are enjoying the
>protection
>provided by the RIR system that is honored by many if not most
>operators,
>without honoring the protection it should be providing to others. I
>think
>those that deliberately thwart the system should lose the protection of
>the
>system.
>
>In my opinion, this is how ARIN grows the bigger stick you seem to be
>saying it needs. ARIN and the other RIRs only have the sticks that we
>give
>them. If you think they need sticks, we need to give them the sticks.
>If we
>don't give them any sticks, we can't complain that that don't have them
>and
>that they don't use them.
>
>As I said this by itself doesn't solve the problem, MANRS and other
>efforts
>are equally if not more important for the practical solution of this
>problem. But, If you think the RIRs should have any sticks at all to
>bring
>to bear even in the most systematic and egregious instances then we
>have to
>give them the sticks and that is done through T&Cs in the RSA contract.
>
>If you don't think ARIN or the other RIRs should have any sticks, I can
>respect that, but then don't say "ARIN needs to grow a bigger stick."
>
>Thanks.
>
>On Mon, Aug 5, 2019 at 3:06 PM Adam Thompson <athompso at athompso.net>
>wrote:
>
>> I would suggest that ARIN needs to grow a bigger stick before there
>is any
>> _point_ in changing the RSA to include specific language like that,
>anyway.
>>
>> So ARIN terminates my contract and nullifies my number assignments -
>if
>> I'm a malicious or even just egregiously negligent user, my reaction
>is "so
>> what?" Even here in Winnipeg, there's at least one ISP I'm pretty
>sure will
>> peer with me and/or advertise for me, even if I'm using bogus IP and
>AS
>> numbers (for a suitable price, of course).
>>
>> If MANRS/RPKI/IRR/etc. had decent adoption here, I think the
>situation
>> would be different.
>>
>> I just don't understand why we're talking about adding T&C's when
>there's
>> so little consequence to willfully breaching them anyway.
>>
>> -Adam
>>
>>
>> On August 5, 2019 12:42:13 p.m. CDT, David Farmer <farmer at umn.edu>
>wrote:
>>>
>>> While I generally support the idea behind this change, the specifics
>of
>>> the language added to the RSA matters significantly. Furthermore, I
>do not
>>> believe that the language added to the RSA should be specific to
>routing.
>>> The language added to the RSA should be more generic, such as a
>commitment
>>> to not deliberately interfere with another registrant's use of the
>>> resources that are registered to them within the context of their
>use on
>>> Internet and not limited to any specific form of interference. Where
>making
>>> route announcements for blocks without permission of the registrant
>should
>>> be a specific example of such prohibited interference.
>>>
>>> Also, ARIN will need to create formal procedures, in addition to the
>>> informal procedures discussed in the following;
>>>
>>>
>>>
>https://teamarin.net/2019/05/06/how-does-arin-handle-reports-of-route-hijacking/
>>>
>>>
>>> I think only the registrant affected should be able to formally make
>a
>>> complaint and such a complaint is only actionable by ARIN after the
>accused
>>> is given a formal opportunity to cure the complaint.
>>>
>>> I think this type of change to the RSA is important and within the
>scope
>>> of the industry self-regulatory framework that the RIR system is
>intended
>>> to provide. Further, such a change promotes an equitable registry
>system,
>>> entities that are unwilling to respect other's registrations do not
>deserve
>>> the protections afforded to them by the registry system. For the RIR
>system
>>> to be taken seriously and provide effective industry self-regulation
>it
>>> needs a mechanism to sanction those that systematically and
>egregiously
>>> thwart the fundamental intent of the registry system, especially
>when such
>>> activities constitute deliberate interference with the proper
>operation of
>>> the Internet.
>>>
>>> That said, while in my opinion, this change is necessary, it is only
>a
>>> very small part of the overall fix for the problem, as most
>incidents are
>>> neither systematic or egregious, and are usually not deliberate,
>most
>>> incidences are merely accidental. In addition this change to the
>RSA, the
>>> industry needs to adopt best practices for routing security,
>including
>>> route filtering and RPKI, to prevent and mitigate these accidental
>>> incidents, such as promoted by the MANRS program;
>>>
>>> https://www.manrs.org/
>>>
>>> Thanks.
>>>
>>> On Wed, Jul 31, 2019 at 2:24 PM ARIN <info at arin.net> wrote:
>>>
>>>> On 31 July, we received a new suggestion, numbered 2019.17 upon
>confirmed
>>>> receipt, that ARIN update its Registration Services Agreement.
>Staff is
>>>> reviewing this suggestion and will issue a formal response once
>analysis
>>>> is complete.
>>>>
>>>> The full text of the suggestion may be found below or at:
>>>>
>>>>
>https://www.arin.net/participate/community/acsp/suggestions/2019-17/
>>>>
>>>> ***
>>>>
>>>> Description: ARIN should modify its Registration Services Agreement
>so
>>>> that address holders agree 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.
>>>>
>>>> Value to Community: The additional value to the community would be
>that
>>>> ARIN address holders would be far less likely to hijack routes as
>it
>>>> would represent a breach of their agreement with ARIN.
>>>>
>>>> Timeframe: Not specified
>>>>
>>>> ***
>>>>
>>>> Regards,
>>>>
>>>> Communications and Member Services
>>>> American Registry for Internet Numbers (ARIN)
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> arin-suggestions mailing list
>>>> arin-suggestions at arin.net
>>>> https://lists.arin.net/mailman/listinfo/arin-suggestions
>>>>
>>>
>>>
>>> --
>>> ===============================================
>>> 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
>>> ===============================================
>>>
>>
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>
>
>
>-- 
>===============================================
>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
>===============================================

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-consult/attachments/20190805/383b892c/attachment.htm>