[ARIN-consult] Consultation on Reallocation Control Features

Wed Oct 16 05:46:48 EDT 2024

A credit freeze was the first thing I though of when I read the 
consultation.  I think for most orgs, reallocation (either in or out) is 
a rare activity (it would be interesting to see stats on this).

Earlier in this thread, Ido Rosen suggested a public/private key 
process.  This might make sense for the most active orgs, but for now, I 
like the simple approach and maybe consider the complexity for 
implementing a cryptographic process vs. benefit. Again- what do the 
stats tell us?  I imagine this process would be a decent amount of work 
for ARIN to implement.  If we implement the 'freeze,' how much of this 
problem remains?  Assuming the most active orgs don't choose to freeze 
their orgs, how frequently do we see inappropriate reallocations?

On 10/15/2024 8:09 PM, Chris Woodfield wrote:
> Thinking out loud on this some more:
>
> If we want to avoid the complexity of having a reallocation being in some sort of provisional state waiting for an approval, and also want to avoid the complexity of asking users to maintain lists of allowed upstream org IDs... could we simply allow an org to prohibit incoming reallocations completely, similar to a consumer credit freeze? If the org needs to receive one, they can unset the checkbox, wait for the reallocation, then add it back afterwards. Is there a requirement for the feature that wouldn’t be covered by this approach?
>
> -C
>
>> On Oct 15, 2024, at 16:02, Chris Woodfield <chris at semihuman.com> wrote:
>>
>> If that’s the case, great, and I’ll withdraw my comment. I'll haven’t been on the receiving side of a reallocation in some time, so it’s entirely possible I’ve missed that development.
>>
>> -C
>>
>>> On Oct 15, 2024, at 15:45, Pellak, Kaitlyn <kaitjean at amazon.com> wrote:
>>>
>>> Hey folks,
>>>   
>>> I believe a notification of the reallocation via email is the default already. This issue might be more prevalent for larger network operators who reallocate resources regularly enough that verifying a legitimate vs malicious reallocation that way gets lost in the shuffle. However I recognize the impacted groups might be in the minority here. Having to manually approve the reallocation when that email comes in could be a good way to resolve this.
>>>   
>>> Kaitlyn
>>>   
>>> Kaitlyn Pellak
>>> Amazon – Technical Business Developer II
>>> kaitjean at amazon.com <mailto:kaitjean at amazon.com>
>>> 301.921.5566
>>>   
>>> <image001.png>
>>>   
>>>   
>>>   
>>> From: ARIN-consult <arin-consult-bounces at arin.net <mailto:arin-consult-bounces at arin.net>> on behalf of Chris Woodfield <chris at semihuman.com <mailto:chris at semihuman.com>>
>>> Date: Tuesday, October 15, 2024 at 6:07 PM
>>> To: Rich Greenwood <rgreenwood at shastacoe.org <mailto:rgreenwood at shastacoe.org>>, "arin-consult at arin.net <mailto:arin-consult at arin.net>" <arin-consult at arin.net <mailto:arin-consult at arin.net>>
>>> Subject: RE: [EXTERNAL] [ARIN-consult] Consultation on Reallocation Control Features
>>>   
>>> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>>>
>>>   
>>> I’m now wondering how many of these incidents might have been mitigated with just a notification mechanism that fires on a reallocation event?
>>>   
>>> If we chose this route, I’d argue that an email notification of a new reallocation being assigned to an org should be a default. Orgs can then flip a switch if they choose to decide whether they want to be able to block them until they can confirm acceptance of the reallocation.
>>>   
>>> -C
>>>
>>>
>>> On Oct 15, 2024, at 14:37, Rich Greenwood <rgreenwood at shastacoe.org> wrote:
>>>   
>>> I tend to agree with a confirmation mechanism.  It doesn't require the receiver to pre-configure anything, provides notification of the attempt, allows the receiver to allow or deny, and notifies the sender of success or failure.  It might be worth adding an option to turn off the notifications in the event someone figures out how to turn them into spam.
>>> --Rich
>>>   
>>> On Tue, Oct 15, 2024 at 2:10 PM Ross Tajvar <ross at tajvar.io <mailto:ross at tajvar.io>> wrote:
>>> I'd like to reiterate Chris's earlier point that manually confirming each reallocation sounds like a better mechanism all around. Easier for users to understand, easier to explain, etc. I'm imagining that most orgs which are reallocating are probably used to the process, but for orgs receiving reallocations, it may be their first time. My experience with IRR has taught me that explaining to a customer who is trying to buy a service from you that they have to perform a process with which they are unfamiliar is difficult and painful.
>>>   
>>> On Tue, Oct 15, 2024 at 5:02 PM Chris Woodfield <chris at semihuman.com <mailto:chris at semihuman.com>> wrote:
>>> Indeed, a larger number than I would have suspected as well. Given that, I’d argue this is worth prioritizing to prevent future abuse.
>>>
>>> I think another relevant question for the consultation would be: If/when this feature ships, will *you* enable it?
>>>
>>> Thanks,
>>>
>>> -Chris
>>>
>>>> On Oct 15, 2024, at 13:57, William Herrin <bill at herrin.us <mailto:bill at herrin.us>> wrote:
>>>>
>>>> On Tue, Oct 15, 2024 at 1:42 PM John Sweeting <jsweeting at arin.net <mailto:jsweeting at arin.net>> wrote:
>>>>> Bill, these would be only those complaints that RSD received and confirmed were suspicious. That is the only way ARIN would have visibility.
>>>> Got it. That's a surprisingly large number. I'm not sure letting folks
>>>> lock the barn door afterwards will help much.
>>>>
>>>> I'm curious: can you share what sort of things the registrants had to
>>>> say for themselves when confronted by ARIN? The ones with the
>>>> allocation direct from ARIN, not the ones filing a complaint about a
>>>> false reallocation?
>>>>
>>>> Thanks,
>>>> Bill Herrin
>>>>
>>>>
>>>> -- 
>>>> William Herrin
>>>> bill at herrin.us <mailto:bill at herrin.us>
>>>> https://bill.herrin.us/
>>>> _______________________________________________
>>>> ARIN-Consult
>>>> You are receiving this message because you are subscribed to the ARIN Consult Mailing
>>>> List (ARIN-consult at arin.net <mailto:ARIN-consult at arin.net>).
>>>> Unsubscribe or manage your mailing list subscription at:
>>>> https://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services
>>>> Help Desk at info at arin.net <mailto:info at arin.net> if you experience any issues.
>>> _______________________________________________
>>> ARIN-Consult
>>> You are receiving this message because you are subscribed to the ARIN Consult Mailing
>>> List (ARIN-consult at arin.net <mailto:ARIN-consult at arin.net>).
>>> Unsubscribe or manage your mailing list subscription at:
>>> https://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services
>>> Help Desk at info at arin.net <mailto:info at arin.net> if you experience any issues.
>>> _______________________________________________
>>> ARIN-Consult
>>> You are receiving this message because you are subscribed to the ARIN Consult Mailing
>>> List (ARIN-consult at arin.net <mailto:ARIN-consult at arin.net>).
>>> Unsubscribe or manage your mailing list subscription at:
>>> https://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services
>>> Help Desk at info at arin.net <mailto:info at arin.net> if you experience any issues.
>>>
>>>   
>>> -- 
>>> Rich Greenwood
>>> Senior Engineer
>>> Shasta County Office of Education
>>> Information Technology
>>> 1644 Magnolia Ave.
>>> Redding, CA 96001
>>> Office: 530-225-0161
>>> rgreenwood at shastacoe.org <mailto:rgreenwood at shastacoe.org>
>>>   
>>> Hotline: 530-225-0279
>>> hotline at shastacoe.org <mailto:hotline at shastacoe.org>
>>> https://hotline.shastacoe.org <https://hotline.shastacoe.org/>
>
>
> _______________________________________________
> ARIN-Consult
> You are receiving this message because you are subscribed to the ARIN Consult Mailing
> List (ARIN-consult at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services
> Help Desk at info at arin.net if you experience any issues.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x1C61021F8B5942A2.asc
Type: application/pgp-keys
Size: 4577 bytes
Desc: OpenPGP public key
URL: <https://lists.arin.net/pipermail/arin-consult/attachments/20241016/1d3571c6/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <https://lists.arin.net/pipermail/arin-consult/attachments/20241016/1d3571c6/attachment.sig>