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

Mon Aug 5 16:54:53 EDT 2019

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
===============================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-consult/attachments/20190805/eb132be5/attachment-0001.htm>