Send ARIN-consult mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.arin.net/mailman/listinfo/arin-consult
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of ARIN-consult digest..."
Today's Topics:
1. Re: Consultation on Reallocation Control Features
(Chris Woodfield)
2. Re: Consultation on Reallocation Control Features
(Chris Woodfield)
----------------------------------------------------------------------
Message: 1
Date: Tue, 15 Oct 2024 16:02:07 -0700
From: Chris Woodfield <[email protected]>
To: "Pellak, Kaitlyn" <[email protected]>
Cc: Rich Greenwood <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [ARIN-consult] Consultation on Reallocation Control
Features
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
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 <[email protected]> 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
> [email protected] <mailto:[email protected]>
> 301.921.5566
>
> <image001.png>
>
>
>
> From: ARIN-consult <[email protected]
> <mailto:[email protected]>> on behalf of Chris Woodfield
> <[email protected] <mailto:[email protected]>>
> Date: Tuesday, October 15, 2024 at 6:07?PM
> To: Rich Greenwood <[email protected]
> <mailto:[email protected]>>, "[email protected]
> <mailto:[email protected]>" <[email protected]
> <mailto:[email protected]>>
> 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 <[email protected]> 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 <[email protected]
> <mailto:[email protected]>> 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 <[email protected]
> <mailto:[email protected]>> 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 <[email protected]
> > <mailto:[email protected]>> wrote:
> >
> > On Tue, Oct 15, 2024 at 1:42?PM John Sweeting <[email protected]
> > <mailto:[email protected]>> 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
> > [email protected] <mailto:[email protected]>
> > https://bill.herrin.us/
> > _______________________________________________
> > ARIN-Consult
> > You are receiving this message because you are subscribed to the ARIN
> > Consult Mailing
> > List ([email protected] <mailto:[email protected]>).
> > 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 [email protected] <mailto:[email protected]> if you experience any
> > issues.
>
> _______________________________________________
> ARIN-Consult
> You are receiving this message because you are subscribed to the ARIN Consult
> Mailing
> List ([email protected] <mailto:[email protected]>).
> 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 [email protected] <mailto:[email protected]> if you experience any
> issues.
> _______________________________________________
> ARIN-Consult
> You are receiving this message because you are subscribed to the ARIN Consult
> Mailing
> List ([email protected] <mailto:[email protected]>).
> 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 [email protected] <mailto:[email protected]> 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
> [email protected] <mailto:[email protected]>
>
> Hotline: 530-225-0279
> [email protected] <mailto:[email protected]>
> https://hotline.shastacoe.org <https://hotline.shastacoe.org/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.arin.net/pipermail/arin-consult/attachments/20241015/0e873907/attachment-0001.htm>
------------------------------
Message: 2
Date: Tue, 15 Oct 2024 17:09:42 -0700
From: Chris Woodfield <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [ARIN-consult] Consultation on Reallocation Control
Features
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
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 <[email protected]> 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 <[email protected]> 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
>> [email protected] <mailto:[email protected]>
>> 301.921.5566
>>
>> <image001.png>
>>
>>
>>
>> From: ARIN-consult <[email protected]
>> <mailto:[email protected]>> on behalf of Chris Woodfield
>> <[email protected] <mailto:[email protected]>>
>> Date: Tuesday, October 15, 2024 at 6:07?PM
>> To: Rich Greenwood <[email protected]
>> <mailto:[email protected]>>, "[email protected]
>> <mailto:[email protected]>" <[email protected]
>> <mailto:[email protected]>>
>> 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 <[email protected]> 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 <[email protected]
>> <mailto:[email protected]>> 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 <[email protected]
>> <mailto:[email protected]>> 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 <[email protected]
>> > <mailto:[email protected]>> wrote:
>> >
>> > On Tue, Oct 15, 2024 at 1:42?PM John Sweeting <[email protected]
>> > <mailto:[email protected]>> 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
>> > [email protected] <mailto:[email protected]>
>> > https://bill.herrin.us/
>> > _______________________________________________
>> > ARIN-Consult
>> > You are receiving this message because you are subscribed to the ARIN
>> > Consult Mailing
>> > List ([email protected] <mailto:[email protected]>).
>> > 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 [email protected] <mailto:[email protected]> if you experience any
>> > issues.
>>
>> _______________________________________________
>> ARIN-Consult
>> You are receiving this message because you are subscribed to the ARIN
>> Consult Mailing
>> List ([email protected] <mailto:[email protected]>).
>> 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 [email protected] <mailto:[email protected]> if you experience any
>> issues.
>> _______________________________________________
>> ARIN-Consult
>> You are receiving this message because you are subscribed to the ARIN
>> Consult Mailing
>> List ([email protected] <mailto:[email protected]>).
>> 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 [email protected] <mailto:[email protected]> 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
>> [email protected] <mailto:[email protected]>
>>
>> Hotline: 530-225-0279
>> [email protected] <mailto:[email protected]>
>> https://hotline.shastacoe.org <https://hotline.shastacoe.org/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.arin.net/pipermail/arin-consult/attachments/20241015/cc6b15af/attachment.htm>
------------------------------
Subject: Digest Footer
_______________________________________________
ARIN-consult mailing list
[email protected]
https://lists.arin.net/mailman/listinfo/arin-consult
------------------------------
End of ARIN-consult Digest, Vol 110, Issue 6
********************************************
