From info at arin.net Wed Oct 9 15:21:39 2024 From: info at arin.net (ARIN) Date: Wed, 09 Oct 2024 15:21:39 -0400 Subject: [ARIN-consult] =?utf-8?q?NOW_CLOSED_=E2=80=93_Consultation_on_AR?= =?utf-8?q?IN_FTP_Retirement?= Message-ID: >From 20 September to 4 October, ARIN held a consultation seeking feedback from the community on retiring FTP protocol support, which serves data from ftp.arin.net. ARIN has operated an FTP protocol service for various reports and templates since its inception. The projected retirement date is on or after 31 March 2025, and it is noted that all data available via FTP is also available over HTTP and HTTPS. After reviewing and discussing the comments received during the consultation, ARIN plans to move forward with work required to support the retirement of FTP. This includes coordinating with the other RIRs to ensure that the mirrors of the extended statistics data are migrated to HTTP/HTTPS, as well as determining an appropriate solution and implementing a method that will allow community members to run delta synchronization and mirroring of these data sets. ARIN thanks those who provided valuable feedback on this consultation. We rely on this input from our members and community to help steer the organization as we continue our mission in support of the operation and growth of the Internet. Regards, John Curran President and CEO American Registry for Internet Numbers (ARIN) ------- ACSP Consultation 2024.5: Consultation for the Retirement of FTP Protocol Use at ARIN https://www.arin.net/participate/community/acsp/consultations/2024/2024-5/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at arin.net Tue Oct 15 13:19:38 2024 From: info at arin.net (ARIN) Date: Tue, 15 Oct 2024 13:19:38 -0400 Subject: [ARIN-consult] Consultation on Reallocation Control Features Message-ID: <7E397F8B-6850-4257-86EF-D8E83DE4EE21@arin.net> ARIN is seeking feedback from the community (https://www.arin.net/participate/community/acsp/consultations/2024/2024-6/) on a suggested feature that would allow customers to manage the ability to control reallocations to their Organization (Org IDs) to protect against bad actors and reputational damage. We are seeking community input on the specific functionality and the priority that should be placed on developing this feature. ARIN can add a feature in the Organization record management section of ARIN Online that will allow customers the ability to manage reallocations to individual Org IDs. This feature would only be manageable via ARIN Online but would apply to reallocations to specified Org IDs using either ARIN Online or programmatically with our Registration RESTful Service (Reg-RWS). Additional questions for community consideration are: - If someone attempts to reallocate to an Org ID that does not have reallocation enabled, should they receive a notification that the organization does not accept reallocations? - Should the customer be notified of attempts to reallocate resources to their Org ID when reallocations are not enabled? - What priority should be placed on the development of this feature? Please provide comments to arin-consult at arin.net. You can subscribe to this mailing list at https://lists.arin.net/mailman/listinfo/arin-consult. This consultation will remain open until 5:00 PM ET on 30 October. ARIN seeks clear direction through community input, so your feedback is important. Thank you for your continued support to improve ARIN?s services. Regards, John Curran President and CEO American Registry for Internet Numbers (ARIN) -------- References: ASCP Suggestion 2024.13: https://www.arin.net/participate/community/acsp/suggestions/2024/2024-13/ From bill at herrin.us Tue Oct 15 13:31:08 2024 From: bill at herrin.us (William Herrin) Date: Tue, 15 Oct 2024 10:31:08 -0700 Subject: [ARIN-consult] Consultation on Reallocation Control Features In-Reply-To: <7E397F8B-6850-4257-86EF-D8E83DE4EE21@arin.net> References: <7E397F8B-6850-4257-86EF-D8E83DE4EE21@arin.net> Message-ID: On Tue, Oct 15, 2024 at 10:19?AM ARIN wrote: > ARIN is seeking feedback from the community (https://www.arin.net/participate/community/acsp/consultations/2024/2024-6/) on a suggested feature that would allow customers to manage the ability to control reallocations to their Organization (Org IDs) to protect against bad actors and reputational damage. We are seeking community input on the specific functionality and the priority that should be placed on developing this feature. I want to make sure I understand the question. Right now, if I'm org ABC with 10.128.0.0/16, I can reallocate 10.128.1.0/24 to org XYZ and that's simply accepted: XYZ shows up as the registrant for 10.128.1.0/24, whether or not they actually control 10.128.1.0/24. ABC then goes on to send lots of spam from 10.128.1.0/24 while XYZ gets all the complaints. The suggested change would allow org XYZ to "lock" their org so that ABC cannot reallocate addresses to them. Is that correct? Thanks, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ From chris at semihuman.com Tue Oct 15 13:48:45 2024 From: chris at semihuman.com (Chris Woodfield) Date: Tue, 15 Oct 2024 10:48:45 -0700 Subject: [ARIN-consult] Consultation on Reallocation Control Features In-Reply-To: <7E397F8B-6850-4257-86EF-D8E83DE4EE21@arin.net> References: <7E397F8B-6850-4257-86EF-D8E83DE4EE21@arin.net> Message-ID: This is an interesting problem, and I appreciate the community consultation. Responses inline. > On Oct 15, 2024, at 10:19, ARIN wrote: > > ARIN is seeking feedback from the community (https://www.arin.net/participate/community/acsp/consultations/2024/2024-6/) on a suggested feature that would allow customers to manage the ability to control reallocations to their Organization (Org IDs) to protect against bad actors and reputational damage. We are seeking community input on the specific functionality and the priority that should be placed on developing this feature. > > ARIN can add a feature in the Organization record management section of ARIN Online that will allow customers the ability to manage reallocations to individual Org IDs. This feature would only be manageable via ARIN Online but would apply to reallocations to specified Org IDs using either ARIN Online or programmatically with our Registration RESTful Service (Reg-RWS). I?m reading Bill Herrin?s interpretation downthread as to the intent of this potential feature, and to the extent this is a not-theoretical issue, I?d be in full support. I?m slightly skeptical that an org controlling reallocate able resources would send /24s to an unaffiliated party just to add a layer of obfuscation to their abuse, but I?ve seen bolder attempts to make money in more dubious ways on the internet, so? My largest concern here would be that many ISPs have multiple Org IDs that they allocation resources from, and it could be difficult for an org to determine in advance which Org IDs they should be adding to their whitelist. So if an org is signing up with a new ISP and getting an allocation, they?d need to add *all* of the possible Org IDs they could get allocated from. In some cases, this could be a substantial number of them. One possible solution (and probably out of scope for v1.0) might be to allow an org to define the equivalent of an AS-Macro; if an org has multiple Org IDs, they might be able to create an ?Org-Macro? that contains all of them, and a downstream Org can add the Org-Macro to their whitelist instead of individual Org IDs. > > Additional questions for community consideration are: > > - If someone attempts to reallocate to an Org ID that does not have reallocation enabled, should they receive a notification that the organization does not accept reallocations? Yes, I?d see this as no different than a permissions error being thrown by a website when a user attempts to access a URL they don?t have access to. The alternative, which I presume would be to fail the reallocation silently, could be misinterpreted as a system error (particularly if being hit innocuously - let?s say the org forgot to add their new ISP?s org handle to their whitelist) > - Should the customer be notified of attempts to reallocate resources to their Org ID when reallocations are not enabled? Yes, subject to some sort of rate limiting/whitelist. I?d hate to get 100+ emails on this in an hour if there?s a bad actor making the attempt that many times. > - What priority should be placed on the development of this feature? > Again, I?d be curious how often this actually happens in the wild, vs this being a theoretical brand of Bad Acting, before I think I could have an opinion here. Regards, -Chris > -------- > References: > > ASCP Suggestion 2024.13: https://www.arin.net/participate/community/acsp/suggestions/2024/2024-13/ > > > _______________________________________________ > 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. From chris at semihuman.com Tue Oct 15 13:58:22 2024 From: chris at semihuman.com (Chris Woodfield) Date: Tue, 15 Oct 2024 10:58:22 -0700 Subject: [ARIN-consult] Consultation on Reallocation Control Features In-Reply-To: <7E397F8B-6850-4257-86EF-D8E83DE4EE21@arin.net> References: <7E397F8B-6850-4257-86EF-D8E83DE4EE21@arin.net> Message-ID: Thinking out loud? perhaps another approach to this could be that an org can choose to require that they affirmatively accept any attempted reallocation request to their Org ID (via email link or via ARIN Online)? With that approach, an org is not required to list in advance their upstream?s Org IDs, and that also solves the issue of repeated failures when a not-allowed org attempts to reallocate. I can see this as a more complex mechanism, as these in-process reallocations would need to be marked in some sort of provisional state in ARIN?s system, and UI/API flows would need to be developed to allow them to be surfaced and processed. But I think the user experience with this approach would be far superior than requiring an org to maintain an Org ID allow list. Thanks, -Chris > On Oct 15, 2024, at 10:19, ARIN wrote: > > ARIN is seeking feedback from the community (https://www.arin.net/participate/community/acsp/consultations/2024/2024-6/) on a suggested feature that would allow customers to manage the ability to control reallocations to their Organization (Org IDs) to protect against bad actors and reputational damage. We are seeking community input on the specific functionality and the priority that should be placed on developing this feature. > > ARIN can add a feature in the Organization record management section of ARIN Online that will allow customers the ability to manage reallocations to individual Org IDs. This feature would only be manageable via ARIN Online but would apply to reallocations to specified Org IDs using either ARIN Online or programmatically with our Registration RESTful Service (Reg-RWS). > > Additional questions for community consideration are: > > - If someone attempts to reallocate to an Org ID that does not have reallocation enabled, should they receive a notification that the organization does not accept reallocations? > - Should the customer be notified of attempts to reallocate resources to their Org ID when reallocations are not enabled? > - What priority should be placed on the development of this feature? > > Please provide comments to arin-consult at arin.net. You can subscribe to this mailing list at https://lists.arin.net/mailman/listinfo/arin-consult. > > This consultation will remain open until 5:00 PM ET on 30 October. ARIN seeks clear direction through community input, so your feedback is important. > > Thank you for your continued support to improve ARIN?s services. > > Regards, > > John Curran > President and CEO > American Registry for Internet Numbers (ARIN) > > -------- > References: > > ASCP Suggestion 2024.13: https://www.arin.net/participate/community/acsp/suggestions/2024/2024-13/ > > > _______________________________________________ > 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. From bill at herrin.us Tue Oct 15 14:29:16 2024 From: bill at herrin.us (William Herrin) Date: Tue, 15 Oct 2024 11:29:16 -0700 Subject: [ARIN-consult] Consultation on Reallocation Control Features In-Reply-To: References: <7E397F8B-6850-4257-86EF-D8E83DE4EE21@arin.net> Message-ID: On Tue, Oct 15, 2024 at 10:48?AM Chris Woodfield wrote: > I?m reading Bill Herrin?s interpretation downthread as to the intent of this potential feature, and to the extent this is a not-theoretical issue, I?d be in full support. I?m slightly skeptical that an org controlling reallocate able resources would send /24s to an unaffiliated party just to add a layer of obfuscation to their abuse, but I?ve seen bolder attempts to make money in more dubious ways on the internet, so? Well, it depends on what you're trying to obfuscate. Suppose Joe goes to an "IP leaser" and claims to be a particular ARIN-registered org. Joe gets IP addresses which he controls and announces them from a "bulletproof hoster" from which Joe proceeds to distribute child porn. As SWATting goes, it's a bit on the pricey side but it's not inconceivable. > Again, I?d be curious how often this actually happens in the wild, vs this being a theoretical brand of Bad Acting, before I think I could have an opinion here. Same. Additional questions for ARIN are: 1. Has this happened to an ARIN registrant? 2. If yes, how many times is ARIN aware of it having happened to an ARIN registrant? We can sit here and dream up all manner of ways to abuse the ARIN process, but at the end of the day security is a cost/value proposition. If delta threat x delta vulnerability x incident cost is less than the implementation and operational cost of the proposed security then it shouldn't be done. > another approach to this could be that an org can choose to require that they affirmatively accept any attempted reallocation request to their Org ID I like this approach much better than the whole screwy "domain lock" thing they do with the DNS. -- William Herrin bill at herrin.us https://bill.herrin.us/ From irosen at gmail.com Tue Oct 15 15:34:31 2024 From: irosen at gmail.com (Ido Rosen) Date: Tue, 15 Oct 2024 12:34:31 -0700 Subject: [ARIN-consult] Consultation on Reallocation Control Features In-Reply-To: References: Message-ID: <7027CEFB-8E84-425E-AC0C-4D50491B84E8@gmail.com> > On Oct 15, 2024, at 11:29, William Herrin wrote: > ?On Tue, Oct 15, 2024 at 10:48?AM Chris Woodfield wrote: >> >> another approach to this could be that an org can choose to require that they affirmatively accept any attempted reallocation request to their Org ID > > I like this approach much better than the whole screwy "domain lock" > thing they do with the DNS. If an org were required to register a public key with ARIN in order to be eligible for transfers, reallocations, and these other ?advanced? features, then ARIN could solve this authentication and authorization problem systematically and automatically using asymmetric cryptography. This is already the case for hosted RPKI somewhat. Whatever mechanism is created or used here, it coexists in the same security narrative as RPKI, and should be audited. I encourage ARIN to also coordinate with other RIRs to build a standard for secure ownership attestation / authZ for org records (and other data records), even if it is out of scope for this particular consultation. From jsweeting at arin.net Tue Oct 15 16:22:47 2024 From: jsweeting at arin.net (John Sweeting) Date: Tue, 15 Oct 2024 20:22:47 +0000 Subject: [ARIN-consult] Consultation on Reallocation Control Features In-Reply-To: References: <7E397F8B-6850-4257-86EF-D8E83DE4EE21@arin.net> Message-ID: The frequency is on average roughly once a month that ARIN will receive a complaint about this. It is usually more than 5 and less than 20 reassignments that ARIN is asked to remove because the Admin POC that did the reassignments is not responding to the request to remove it. ARIN has been informed that this has caused problems due to subpoenas being issued for nefarious activities that have taken place using these IP addresses. So yes, it does happen and yes, there are negative effects to the organization that these reassignments are made to. From: ARIN-consult on behalf of William Herrin Date: Tuesday, October 15, 2024 at 2:29?PM To: Chris Woodfield Cc: arin-consult at arin.net Subject: Re: [ARIN-consult] Consultation on Reallocation Control Features On Tue, Oct 15, 2024 at 10:48?AM Chris Woodfield wrote: > I?m reading Bill Herrin?s interpretation downthread as to the intent of this potential feature, and to the extent this is a not-theoretical issue, I?d be in full support. I?m slightly skeptical that an org controlling reallocate able resources would send /24s to an unaffiliated party just to add a layer of obfuscation to their abuse, but I?ve seen bolder attempts to make money in more dubious ways on the internet, so? Well, it depends on what you're trying to obfuscate. Suppose Joe goes to an "IP leaser" and claims to be a particular ARIN-registered org. Joe gets IP addresses which he controls and announces them from a "bulletproof hoster" from which Joe proceeds to distribute child porn. As SWATting goes, it's a bit on the pricey side but it's not inconceivable. > Again, I?d be curious how often this actually happens in the wild, vs this being a theoretical brand of Bad Acting, before I think I could have an opinion here. Same. Additional questions for ARIN are: 1. Has this happened to an ARIN registrant? 2. If yes, how many times is ARIN aware of it having happened to an ARIN registrant? We can sit here and dream up all manner of ways to abuse the ARIN process, but at the end of the day security is a cost/value proposition. If delta threat x delta vulnerability x incident cost is less than the implementation and operational cost of the proposed security then it shouldn't be done. > another approach to this could be that an org can choose to require that they affirmatively accept any attempted reallocation request to their Org ID I like this approach much better than the whole screwy "domain lock" thing they do with the DNS. -- William Herrin 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). 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 -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Tue Oct 15 16:38:40 2024 From: bill at herrin.us (William Herrin) Date: Tue, 15 Oct 2024 13:38:40 -0700 Subject: [ARIN-consult] Consultation on Reallocation Control Features In-Reply-To: References: <7E397F8B-6850-4257-86EF-D8E83DE4EE21@arin.net> Message-ID: On Tue, Oct 15, 2024 at 1:22?PM John Sweeting wrote: > The frequency is on average roughly once a month that ARIN will receive a complaint about this. It is usually more than 5 and less than 20 reassignments that ARIN is asked to remove because the Admin POC that did the reassignments is not responding to the request to remove it. ARIN has been informed that this has caused problems due to subpoenas being issued for nefarious activities that have taken place using these IP addresses. So yes, it does happen and yes, there are negative effects to the organization that these reassignments are made to. Hi John, For that monthly number, are we talking all folks who complain that an address block is incorrectly linked to them, or just folks for which ARIN has confirmed a malicious linkage? I note that the proposed solution could only impact cases where (A) the org legitimately created their own POC and (B) never legitimately had the addresses assigned to it. Stale ISP entries and orgs for whom registrations were created without their knowledge would not be helped. Regards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ From jsweeting at arin.net Tue Oct 15 16:42:20 2024 From: jsweeting at arin.net (John Sweeting) Date: Tue, 15 Oct 2024 20:42:20 +0000 Subject: [ARIN-consult] Consultation on Reallocation Control Features In-Reply-To: References: <7E397F8B-6850-4257-86EF-D8E83DE4EE21@arin.net> Message-ID: From: William Herrin Date: Tuesday, October 15, 2024 at 4:39?PM To: John Sweeting Cc: arin-consult at arin.net Subject: Re: [ARIN-consult] Consultation on Reallocation Control Features On Tue, Oct 15, 2024 at 1:22?PM John Sweeting wrote: > The frequency is on average roughly once a month that ARIN will receive a complaint about this. It is usually more than 5 and less than 20 reassignments that ARIN is asked to remove because the Admin POC that did the reassignments is not responding to the request to remove it. ARIN has been informed that this has caused problems due to subpoenas being issued for nefarious activities that have taken place using these IP addresses. So yes, it does happen and yes, there are negative effects to the organization that these reassignments are made to. Hi John, For that monthly number, are we talking all folks who complain that an address block is incorrectly linked to them, or just folks for which ARIN has confirmed a malicious linkage? Bill, these would be only those complaints that RSD received and confirmed were suspicious. That is the only way ARIN would have visibility. I note that the proposed solution could only impact cases where (A) the org legitimately created their own POC and (B) never legitimately had the addresses assigned to it. Stale ISP entries and orgs for whom registrations were created without their knowledge would not be helped. Regards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Tue Oct 15 16:57:13 2024 From: bill at herrin.us (William Herrin) Date: Tue, 15 Oct 2024 13:57:13 -0700 Subject: [ARIN-consult] Consultation on Reallocation Control Features In-Reply-To: References: <7E397F8B-6850-4257-86EF-D8E83DE4EE21@arin.net> Message-ID: On Tue, Oct 15, 2024 at 1:42?PM John Sweeting 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 https://bill.herrin.us/ From chris at semihuman.com Tue Oct 15 17:02:11 2024 From: chris at semihuman.com (Chris Woodfield) Date: Tue, 15 Oct 2024 14:02:11 -0700 Subject: [ARIN-consult] Consultation on Reallocation Control Features In-Reply-To: References: <7E397F8B-6850-4257-86EF-D8E83DE4EE21@arin.net> Message-ID: <3D318B6C-658E-4C16-8EDC-BB3D06E5E9FC@semihuman.com> 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 wrote: > > On Tue, Oct 15, 2024 at 1:42?PM John Sweeting 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 > 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). > 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. From ross at tajvar.io Tue Oct 15 17:09:59 2024 From: ross at tajvar.io (Ross Tajvar) Date: Tue, 15 Oct 2024 17:09:59 -0400 Subject: [ARIN-consult] Consultation on Reallocation Control Features In-Reply-To: <3D318B6C-658E-4C16-8EDC-BB3D06E5E9FC@semihuman.com> References: <7E397F8B-6850-4257-86EF-D8E83DE4EE21@arin.net> <3D318B6C-658E-4C16-8EDC-BB3D06E5E9FC@semihuman.com> Message-ID: 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 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 wrote: > > > > On Tue, Oct 15, 2024 at 1:42?PM John Sweeting > 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 > > 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). > > 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. > > _______________________________________________ > 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 -------------- An HTML attachment was scrubbed... URL: From rgreenwood at shastacoe.org Tue Oct 15 17:37:27 2024 From: rgreenwood at shastacoe.org (Rich Greenwood) Date: Tue, 15 Oct 2024 14:37:27 -0700 Subject: [ARIN-consult] Consultation on Reallocation Control Features In-Reply-To: References: <7E397F8B-6850-4257-86EF-D8E83DE4EE21@arin.net> <3D318B6C-658E-4C16-8EDC-BB3D06E5E9FC@semihuman.com> Message-ID: 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 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 > 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 wrote: >> > >> > On Tue, Oct 15, 2024 at 1:42?PM John Sweeting >> 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 >> > 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). >> > 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. >> >> _______________________________________________ >> 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. >> > _______________________________________________ > 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. > -- 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 Hotline: 530-225-0279 hotline at shastacoe.org https://hotline.shastacoe.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at semihuman.com Tue Oct 15 18:06:44 2024 From: chris at semihuman.com (Chris Woodfield) Date: Tue, 15 Oct 2024 15:06:44 -0700 Subject: [ARIN-consult] Consultation on Reallocation Control Features In-Reply-To: References: <7E397F8B-6850-4257-86EF-D8E83DE4EE21@arin.net> <3D318B6C-658E-4C16-8EDC-BB3D06E5E9FC@semihuman.com> Message-ID: <3CD980F9-87A6-493D-8303-416DDA69FB5F@semihuman.com> 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 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 > 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 > 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 > wrote: >>> > >>> > On Tue, Oct 15, 2024 at 1:42?PM John Sweeting > 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 >>> > 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 ). >>> > 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. >>> >>> _______________________________________________ >>> 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. >> _______________________________________________ >> 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. > > > -- > 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 > > Hotline: 530-225-0279 > hotline at shastacoe.org > https://hotline.shastacoe.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kaitjean at amazon.com Tue Oct 15 18:45:49 2024 From: kaitjean at amazon.com (Pellak, Kaitlyn) Date: Tue, 15 Oct 2024 22:45:49 +0000 Subject: [ARIN-consult] Consultation on Reallocation Control Features In-Reply-To: <3CD980F9-87A6-493D-8303-416DDA69FB5F@semihuman.com> References: <7E397F8B-6850-4257-86EF-D8E83DE4EE21@arin.net> <3D318B6C-658E-4C16-8EDC-BB3D06E5E9FC@semihuman.com> <3CD980F9-87A6-493D-8303-416DDA69FB5F@semihuman.com> Message-ID: <01010192925be899-1f0cf397-f50f-47d1-ba8e-ae5b100db91c-000000@us-west-2.amazonses.com> 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 301.921.5566 [/Users/tinam/Library/Containers/com.microsoft.Outlook/Data/Library/Caches/Signatures/signature_1323502979] From: ARIN-consult on behalf of Chris Woodfield Date: Tuesday, October 15, 2024 at 6:07?PM To: Rich Greenwood , "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 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 > 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 > 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 > wrote: > > On Tue, Oct 15, 2024 at 1:42?PM John Sweeting > 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 > 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). > 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. _______________________________________________ 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. _______________________________________________ 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. -- 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 Hotline: 530-225-0279 hotline at shastacoe.org https://hotline.shastacoe.org [Image removed by sender.] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 5802 bytes Desc: image001.png URL: From chris at semihuman.com Tue Oct 15 19:02:07 2024 From: chris at semihuman.com (Chris Woodfield) Date: Tue, 15 Oct 2024 16:02:07 -0700 Subject: [ARIN-consult] Consultation on Reallocation Control Features In-Reply-To: <01010192925be899-1f0cf397-f50f-47d1-ba8e-ae5b100db91c-000000@us-west-2.amazonses.com> References: <7E397F8B-6850-4257-86EF-D8E83DE4EE21@arin.net> <3D318B6C-658E-4C16-8EDC-BB3D06E5E9FC@semihuman.com> <3CD980F9-87A6-493D-8303-416DDA69FB5F@semihuman.com> <01010192925be899-1f0cf397-f50f-47d1-ba8e-ae5b100db91c-000000@us-west-2.amazonses.com> Message-ID: <4DB840E5-18F9-4796-A94C-9B58A9CA6E8A@semihuman.com> 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 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 > 301.921.5566 > > > > > > From: ARIN-consult > on behalf of Chris Woodfield > > Date: Tuesday, October 15, 2024 at 6:07?PM > To: Rich Greenwood >, "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 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 > 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 > 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 > wrote: > > > > On Tue, Oct 15, 2024 at 1:42?PM John Sweeting > 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 > > 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 ). > > 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. > > _______________________________________________ > 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. > _______________________________________________ > 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. > > > -- > 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 > > Hotline: 530-225-0279 > hotline at shastacoe.org > https://hotline.shastacoe.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at semihuman.com Tue Oct 15 20:09:42 2024 From: chris at semihuman.com (Chris Woodfield) Date: Tue, 15 Oct 2024 17:09:42 -0700 Subject: [ARIN-consult] Consultation on Reallocation Control Features In-Reply-To: <4DB840E5-18F9-4796-A94C-9B58A9CA6E8A@semihuman.com> References: <7E397F8B-6850-4257-86EF-D8E83DE4EE21@arin.net> <3D318B6C-658E-4C16-8EDC-BB3D06E5E9FC@semihuman.com> <3CD980F9-87A6-493D-8303-416DDA69FB5F@semihuman.com> <01010192925be899-1f0cf397-f50f-47d1-ba8e-ae5b100db91c-000000@us-west-2.amazonses.com> <4DB840E5-18F9-4796-A94C-9B58A9CA6E8A@semihuman.com> Message-ID: 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 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 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 >> 301.921.5566 >> >> >> >> >> >> From: ARIN-consult > on behalf of Chris Woodfield > >> Date: Tuesday, October 15, 2024 at 6:07?PM >> To: Rich Greenwood >, "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 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 > 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 > 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 > wrote: >> > >> > On Tue, Oct 15, 2024 at 1:42?PM John Sweeting > 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 >> > 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 ). >> > 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. >> >> _______________________________________________ >> 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. >> _______________________________________________ >> 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. >> >> >> -- >> 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 >> >> Hotline: 530-225-0279 >> hotline at shastacoe.org >> https://hotline.shastacoe.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From akg1330 at gmail.com Wed Oct 16 05:46:48 2024 From: akg1330 at gmail.com (Andrew Gallo) Date: Wed, 16 Oct 2024 05:46:48 -0400 Subject: [ARIN-consult] Consultation on Reallocation Control Features In-Reply-To: References: <7E397F8B-6850-4257-86EF-D8E83DE4EE21@arin.net> <3D318B6C-658E-4C16-8EDC-BB3D06E5E9FC@semihuman.com> <3CD980F9-87A6-493D-8303-416DDA69FB5F@semihuman.com> <01010192925be899-1f0cf397-f50f-47d1-ba8e-ae5b100db91c-000000@us-west-2.amazonses.com> <4DB840E5-18F9-4796-A94C-9B58A9CA6E8A@semihuman.com> Message-ID: <11016f49-85f0-4042-8e28-0a34e08a98d6@gmail.com> 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 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 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 >>> 301.921.5566 >>> >>> >>> >>> >>> >>> From: ARIN-consult > on behalf of Chris Woodfield > >>> Date: Tuesday, October 15, 2024 at 6:07?PM >>> To: Rich Greenwood >, "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 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 > 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 > 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 > wrote: >>>> >>>> On Tue, Oct 15, 2024 at 1:42?PM John Sweeting > 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 >>>> 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 ). >>>> 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. >>> _______________________________________________ >>> 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. >>> _______________________________________________ >>> 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. >>> >>> >>> -- >>> 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 >>> >>> Hotline: 530-225-0279 >>> hotline at 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 495 bytes Desc: OpenPGP digital signature URL: From bill at herrin.us Wed Oct 16 07:23:42 2024 From: bill at herrin.us (William Herrin) Date: Wed, 16 Oct 2024 04:23:42 -0700 Subject: [ARIN-consult] Consultation on Reallocation Control Features In-Reply-To: References: <7E397F8B-6850-4257-86EF-D8E83DE4EE21@arin.net> Message-ID: > On Tue, Oct 15, 2024 at 10:19?AM ARIN wrote: > allow customers to manage the ability to control reallocations to their Organization (Org IDs) to protect against bad actors and reputational damage. If ARIN acts on this, we also have the reverse problem to consider: How do ISPs deal with customers who fail to accept registration of the IP addresses assigned to them? Will ISPs have to add a multi-step process to not route the addresses until a POC for the ORG has accepted them at ARIN? Regards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ From Anthony.DeLaCruz at lumen.com Thu Oct 24 17:10:14 2024 From: Anthony.DeLaCruz at lumen.com (Delacruz, Anthony B) Date: Thu, 24 Oct 2024 21:10:14 +0000 Subject: [ARIN-consult] ACSP Consultation 2024.6: Consultation on Reallocation Control Features In-Reply-To: References: Message-ID: Would be very grateful if ARIN were to implement a lock down feature so no other entity could reassign resources to our ORG-ID?s without our permission. I would go and lock everyone of our ORGs immediately. I have been one of the folks calling in or opening tickets to get IP space set to us removed from being associated to us. My favorite way to find out about this is by getting a subpoena from the DOJ for naughtiness on IP space that is not ours but we have been tagged for then chasing to get us off the listing. Do you know about Methbot? Only one of the largest ad revenue scams ever. So, a large portion of those ranges were noted as us, but it wasn?t us. We also have problems where folks put an attribution to us in the name or comment section we have to reach out to get removed but that would be a wholly different and more difficult item to deal with. If someone attempts to reallocate to an Org ID that does not have reallocation enabled, should they receive a notification that the organization does not accept reallocations? LOL sure might save staff from getting a call from the bad guys why didn?t the swip go thru... maybe ? I don?t care that they find out they have been blocked with the feature, might encourage them to stop. Should the customer be notified of attempts to reallocate resources to their Org ID when reallocations are not enabled? A heads up would also be nice here, with all interactions notice to both parties would be great. What priority should be placed on the development of this feature? It?s important but we haven?t run across a bad guy in 3 or so years doing this to us. Anthony Delacruz Senior Lead Engineer IP Admin Backbone Planning and Design Office: +1 832-449-4073 anthony.delacruz at lumen.com ipadmin at lumen.com ---------------------------------------------------------------------- This communication is the property of Lumen Technologies and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Fri Oct 25 12:59:19 2024 From: gert at space.net (Gert Doering) Date: Fri, 25 Oct 2024 18:59:19 +0200 Subject: [ARIN-consult] ACSP Consultation 2024.6: Consultation on Reallocation Control Features In-Reply-To: References: Message-ID: Hi, On Thu, Oct 24, 2024 at 09:10:14PM +0000, Delacruz, Anthony B via ARIN-consult wrote: > Would be very grateful if ARIN were to implement a lock down feature so no other entity could reassign resources to our ORG-ID???s without our permission. If someone reallocates resources to you, can you not just keep them? Not sure how this ARIN "reallocate" thing works. Gert Doering -- RIPE has other processes -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From denis.l.gauthier at bell.ca Fri Oct 25 13:12:23 2024 From: denis.l.gauthier at bell.ca (Gauthier, Denis) Date: Fri, 25 Oct 2024 17:12:23 +0000 Subject: [ARIN-consult] ACSP Consultation 2024.6: Consultation on Reallocation Control Features In-Reply-To: References: Message-ID: No you can't just keep them. They are not the Parent of the larger Block. They are similar to a reassignment in that respect. The downstream child can use IPs as long as Parent allows them to. (or has a contract with them) Reallocation is like renting space to someone. You own the building but they rent the apartment. When they stop renting, you take the apartment back. As Parent of the block, you can remove reallocations, Reassignments, at ARIN at any time. Thanks, Denis Gauthier Business Provisioning - IPPROV Field Services (613) 781-0695 Email: Denis.l.gauthier at bell.ca -----Original Message----- From: ARIN-consult On Behalf Of Gert Doering Sent: October-25-24 12:59 PM To: Delacruz, Anthony B Cc: arin-consult at arin.net Subject: [EXT]Re: [ARIN-consult] ACSP Consultation 2024.6: Consultation on Reallocation Control Features Hi, On Thu, Oct 24, 2024 at 09:10:14PM +0000, Delacruz, Anthony B via ARIN-consult wrote: > Would be very grateful if ARIN were to implement a lock down feature so no other entity could reassign resources to our ORG-ID???s without our permission. If someone reallocates resources to you, can you not just keep them? Not sure how this ARIN "reallocate" thing works. Gert Doering -- RIPE has other processes -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 _______________________________________________ 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. ------------------------------------------------------------------------------ External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints