From info at arin.net Thu Aug 10 15:32:21 2023 From: info at arin.net (ARIN) Date: Thu, 10 Aug 2023 15:32:21 -0400 Subject: [ARIN-consult] Consultation on Pending Functionality for Automatic Creation of IRR Route Objects for Uncovered ROAs Message-ID: Dear ARIN Community, ARIN is seeking feedback from the community regarding a specific aspect of the recent ARIN Online functionality that was deployed on 7 August 2023. This upgrade to ARIN Online brought several new features ? including tighter integration of ARIN?s Resource Public Key Infrastructure (RPKI) and Internet Routing Registry (IRR) routing security services. Upon further review and out of an abundance of caution, we have decided to pause the additional functionality that creates corresponding IRR Route Objects for every Route Origin Authorization (ROA) created. We have also paused the functionality that automatically creates IRR Route Objects for all preexisting ROAs that presently lack a matching Route Object. We recognize the importance of ensuring that our services align with the needs and expectations of our community and believe that additional time for community consultation on this integration functionality is warranted. The current development plan is to provide an opt-in feature to allow for the creation of IRR Route Objects during new ROA creation in the near future. We are seeking operator input through this community consultation (https://www.arin.net/participate/community/acsp/consultations/2023/2023-4/) to gather input on the desirability of additional functionality related to integrating RPKI and IRR security services. The questions for community consideration are: - Should the automatic creation of IRR route objects for resources that have RPKI ROAs be compulsory, the default setting, or require explicit opt-in? - Should IRR Objects be managed via a direct linkage to a ROAs such that they can only be deleted through deletion of the covering ROA, or should ARIN continue to support independent management of IRR route objects? - Should ARIN automatically create managed IRR Route Objects for all validated ROAs in the Hosted RPKI repository that do not have matching IRR Route Objects today? - If so, what is the anticipated benefit of doing so? Conversely, if this functionality is not desired, why not? - If a customer agrees to link a ROA with the IRR, what is the appropriate number of route objects that should be created based on the ROA prefix and max length configuration? Would a ?least specific? route object meet expectations? We sincerely apologize for any inconvenience that pausing this functionality may have caused and appreciate your understanding as we work to ensure that our services are aligned with the interests of the community. I encourage all community members to provide their comments and feedback on this matter ? the feedback you provide during this consultation will be instrumental in determining how ARIN moves forward with this RPKI/IRR integration functionality. 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 10 September 2023. ARIN seeks clear direction through community input, so your feedback is important. Thank you for your continued support and engagement. Regards, John Curran President and CEO American Registry for Internet Numbers (ARIN) From bill at herrin.us Thu Aug 10 17:09:28 2023 From: bill at herrin.us (William Herrin) Date: Thu, 10 Aug 2023 14:09:28 -0700 Subject: [ARIN-consult] Consultation on Pending Functionality for Automatic Creation of IRR Route Objects for Uncovered ROAs In-Reply-To: References: Message-ID: On Thu, Aug 10, 2023 at 12:32?PM ARIN wrote: > - Should the automatic creation of IRR route objects for resources that have RPKI ROAs be compulsory, No, never, absolutely not. > the default setting, or require explicit opt-in? Either of these is fine, IMHO. > - Should IRR Objects be managed via a direct linkage to a ROAs such that they can only be deleted through deletion of the covering ROA, No, never, absolutely not. > or should ARIN continue to support independent management of IRR route objects? Yes. > - Should ARIN automatically create managed IRR Route Objects for all validated ROAs in the Hosted RPKI repository that do not have matching IRR Route Objects today? No, but it might be useful to send a one-time email to the tech POC containing a one-click link that will add them. Broadly speaking, you shouldn't ever do technical things the user isn't expecting. Most especially not at random times when the user isn't expecting anything to happen. That's very bad practice with almost inevitable breakage, no matter how well conceived the notion. And... compulsory? Really? Regards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ From Miles.McCredie at midco.com Thu Aug 10 18:41:44 2023 From: Miles.McCredie at midco.com (Miles McCredie) Date: Thu, 10 Aug 2023 22:41:44 +0000 Subject: [ARIN-consult] [EXTERNAL] - Consultation on Pending Functionality for Automatic Creation of IRR Route Objects for Uncovered ROAs In-Reply-To: References: <2eb1185c-da57-49c1-9307-39d169cb262b.4ed73c0e-3647-455d-a83f-39a249afb096.5d12e156-49db-4797-bd96-73ce250a2abf@emailsignatures365.codetwo.com> Message-ID: >- Should the automatic creation of IRR route objects for resources that have RPKI ROAs be compulsory, the default setting, or require explicit opt-in? Opt-in at the Organization level. Opting in should not remove existing IRR route(6) objects that do not match a ROA though it would probably be useful to highlight any differences between IRR data and ROAs, possibly with an option to fully align the IRR data with the ROA. (ie "The following IRR route(6) objects either match or are more specifics of the prefix in this ROA, click here to remove all the IRR route(6) objects that do not match the prefix in the ROA. The non-matching IRR route(6) objects can be managed separately from the ROA.") > - Should IRR Objects be managed via a direct linkage to a ROAs such that they can only be deleted through deletion of the covering ROA, or should ARIN continue to support independent management of IRR route objects? Should be independent for existing IRR route(6) objects. Automatically created IRR route(6) objects should probably be managed directly from the ROA that triggered the creation. >- If so, what is the anticipated benefit of doing so? Conversely, if this functionality is not desired, why not? Abundance of caution, especially for existing IRR route(6) objects. > - If a customer agrees to link a ROA with the IRR, what is the appropriate number of route objects that should be created based on the ROA prefix and max length configuration? Would a "least specific" route object meet expectations? I think that creating a single "least specific" route object per ROA is the best approach. Probably worthwhile having a message along the lines of "This ROA includes a max length value different from the prefix mask. The system has created an IRR route(6) object corresponding to the prefix mask which supports the most common use cases. Additional IRR route(6) objects can be directly created if needed." Miles McCredie Principal Network Engineer II-Core IP Office: 6052755192 Miles.McCredie at midco.com Midco.com -----Original Message----- From: ARIN-consult On Behalf Of ARIN Sent: Thursday, August 10, 2023 2:32 PM To: arin-consult at arin.net Subject: [EXTERNAL] - [ARIN-consult] Consultation on Pending Functionality for Automatic Creation of IRR Route Objects for Uncovered ROAs CAUTION: This email originated from outside of MIDCO. Do not click links or open attachments unless you recognize the sender and know the content is safe. Dear ARIN Community, ARIN is seeking feedback from the community regarding a specific aspect of the recent ARIN Online functionality that was deployed on 7 August 2023. This upgrade to ARIN Online brought several new features - including tighter integration of ARIN's Resource Public Key Infrastructure (RPKI) and Internet Routing Registry (IRR) routing security services. Upon further review and out of an abundance of caution, we have decided to pause the additional functionality that creates corresponding IRR Route Objects for every Route Origin Authorization (ROA) created. We have also paused the functionality that automatically creates IRR Route Objects for all preexisting ROAs that presently lack a matching Route Object. We recognize the importance of ensuring that our services align with the needs and expectations of our community and believe that additional time for community consultation on this integration functionality is warranted. The current development plan is to provide an opt-in feature to allow for the creation of IRR Route Objects during new ROA creation in the near future. We are seeking operator input through this community consultation (https://www.arin.net/participate/community/acsp/consultations/2023/2023-4/) to gather input on the desirability of additional functionality related to integrating RPKI and IRR security services. The questions for community consideration are: - Should the automatic creation of IRR route objects for resources that have RPKI ROAs be compulsory, the default setting, or require explicit opt-in? - Should IRR Objects be managed via a direct linkage to a ROAs such that they can only be deleted through deletion of the covering ROA, or should ARIN continue to support independent management of IRR route objects? - Should ARIN automatically create managed IRR Route Objects for all validated ROAs in the Hosted RPKI repository that do not have matching IRR Route Objects today? - If so, what is the anticipated benefit of doing so? Conversely, if this functionality is not desired, why not? - If a customer agrees to link a ROA with the IRR, what is the appropriate number of route objects that should be created based on the ROA prefix and max length configuration? Would a "least specific" route object meet expectations? We sincerely apologize for any inconvenience that pausing this functionality may have caused and appreciate your understanding as we work to ensure that our services are aligned with the interests of the community. I encourage all community members to provide their comments and feedback on this matter - the feedback you provide during this consultation will be instrumental in determining how ARIN moves forward with this RPKI/IRR integration functionality. 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 10 September 2023. ARIN seeks clear direction through community input, so your feedback is important. Thank you for your continued support and engagement. Regards, John Curran President and CEO American Registry for Internet Numbers (ARIN) _______________________________________________ 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 Chuck.Hauge at charter.com Fri Aug 11 13:37:15 2023 From: Chuck.Hauge at charter.com (Hauge, Chuck P) Date: Fri, 11 Aug 2023 17:37:15 +0000 Subject: [ARIN-consult] Consultation on Pending Functionality for Automatic Creation of IRR Route Objects for Uncovered ROAs Message-ID: <012d9e3ac8604551990ef41e68042d44@charter.com> The questions for community consideration are: - Should the automatic creation of IRR route objects for resources that have RPKI ROAs be compulsory, the default setting, or require explicit opt-in? A: I believe either and opt-in or opt-out option would be best per ORGID - Should IRR Objects be managed via a direct linkage to a ROAs such that they can only be deleted through deletion of the covering ROA, or should ARIN continue to support independent management of IRR route objects? A: If opt-in/out is adopted, this could be set by that option. If opt-in is selected, it could be a direct link with no manual management. If opt-out, manual management is required. - Should ARIN automatically create managed IRR Route Objects for all validated ROAs in the Hosted RPKI repository that do not have matching IRR Route Objects today? A: It seems this could also be set to opt-in/out, based upon the response to the first question. If opt-out of auto-creation, it seems this would be moot. - If so, what is the anticipated benefit of doing so? Conversely, if this functionality is not desired, why not? A: That would be based upon the IPAM manager for the ORG to define for themselves, based upon options selected. Personally, I can see a benefit for those Tier 1's and other peers that create their import policies based upon IRR objects. - If a customer agrees to link a ROA with the IRR, what is the appropriate number of route objects that should be created based on the ROA prefix and max length (ML) configuration? Would a "least specific" route object meet expectations? A: So, I agree there is a maximum, especially for IPv6. I just found out the other week that Google (and only Google to the best of my knowledge), will bypass ARIN Direct Allocation (DA) of a block, and prefer stale RADb route objects. That is, we own the supernet, but Google will not take that into consideration when we peer direct to them, they will look at [very old] RADb route objects if there is a subnet match and we don't have a route record in RADb or ARIN. As RADb is "open" and allows anyone to create a route object for any IP and origination AS, this opens our 57M v4 iP's to easy attack if we don't have a route record for every possible prefix we own. This creates a new vector of attack created solely by Google for our owned IP's to access Google resources. Also, since we have 100K employees, and most anyone in networking can create a prefix tagged appropriately and leaked to the Internet, in managing IP's we have no way to limit what is routed and leaked. We would have to play whack-a-mole trying to keep up. That in mind, and I think that if more than 256 (or nnn?) IRR route objects are to be created, a message should be presented to the requester informing them of what they are asking. I should say, we don't like to use ML expect in very isolated cases where we'd be playing whack-a-mole if we tried to cover all /48's of a /32 for our business class customers. That said, we still have to act responsibly and understand the consequences such as Forged Origin attacks: https://datatracker.ietf.org/doc/html/rfc9319. So, you want to know the "specific" number, and I honestly don't have a suggestion, but how about this, if ML is used, ask the question something like, "Using an ML value greater than the mask creates the potential for subnets leaked to the Internet. Do you want to create IRR route objects for each candidate subnet, or create a route object for only the parent aggregate?" Regards, [Charter_Email Signature_Logo] ------------------------------------------------------------------------------------------------------------------------------------- CHUCK HAUGE | CCNP, MBA | IP Management - Systems Engineer IV | c. 303.915.5512 | o. 303.323.6056 6175 South Willow Drive | Greenwood Village, CO 80111 ------------------------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 6366 bytes Desc: image001.png URL: From dwcarder at es.net Fri Aug 18 15:30:57 2023 From: dwcarder at es.net (Dale W. Carder) Date: Fri, 18 Aug 2023 14:30:57 -0500 Subject: [ARIN-consult] Consultation on Pending Functionality for Automatic Creation of IRR Route Objects for Uncovered ROAs In-Reply-To: References: Message-ID: Thus spake ARIN (info at arin.net) on Thu, Aug 10, 2023 at 03:32:21PM -0400: > - Should the automatic creation of IRR route objects for resources that have RPKI ROAs be compulsory, the default setting, or require explicit opt-in? First, I believe we are here because in essence, ARIN violated the Principal Of Least Astonishment as new functionality rolled out with no warning. Our org for example had very recently created a new ROA, and then got a surprise as monitoring detected a new IRR object getting created that we did not explicitly create. I believe for new routing security initiatives to have successful uptake, the tooling presented should have reasonable, secure, and safe defaults that "do the right thing" covering the majority of Organizations. Note, "safe defaults" here really, really should include ACSP Suggestion 2022.30. I am estimating the default behavior should skew heavily towards Orgs who are relatively uncomplicated, and for them, the automagic maintenance of IRR objects can be a huge win in terms of simplicity as well as providing immediate benefit for the Internet at large with more data in trustworthy IRR sources. We do need to recognize there are Orgs for whom this default behavior would not be necessary, or perhaps even reasonable. I would believe them to be in the minority. A few have chimed in as part of this discussion and to me, this effectively makes a case for opt-out functionality, communicated well in advance. I do not believe that opt-in is the correct approach to further this aspect of Internet security, as it puts the burden to "do something" in too many unincentivized hands, furthering stagnation. > - Should IRR Objects be managed via a direct linkage to a ROAs such that they can only be deleted through deletion of the covering ROA, or should ARIN continue to support independent management of IRR route objects? Both options may need to exist. I would expect that a Delegated or Hybrid publish-in-parent RPKI customer would still need independent management of IRR route objects in any case. I would propose linked ROA-IRR route object mode as the default for Hosted RPKI Orgs, and have full manual let me shoot myself in the foot mode be available as an option for them as well as anyone else. > - Should ARIN automatically create managed IRR Route Objects for all validated ROAs in the Hosted RPKI repository that do not have matching IRR Route Objects today? Yes, w/ opt-out functionality per Org. > - If so, what is the anticipated benefit of doing so? Conversely, if this functionality is not desired, why not? I believe that as a community we need to actively deprecate all use of non-RIR IRR source databases. We can get a long way there through safe, reasonable default behavior that benefits the majority of Orgs. > - If a customer agrees to link a ROA with the IRR, what is the appropriate number of route objects that should be created based on the ROA prefix and max length configuration? One. Taking a logical step from RFC9319, as a community, we should be working towards a 1:1:1 mapping of Minimal ROA, IRR route object, and the prefix seen in the DFZ. To do anything other than that should require "effort". > We sincerely apologize for any inconvenience that pausing this functionality may have caused and appreciate your understanding as we work to ensure that our services are aligned with the interests of the community. Thanks for consulting the community! I believe had this been communicated in advance, any discussion could have preceded the implementation (and rollback). Let's work together to get the future communication right, and as an upcoming opportunity consider the process we should use for ASPA. Dale From jcurran at arin.net Sat Aug 19 12:46:54 2023 From: jcurran at arin.net (John Curran) Date: Sat, 19 Aug 2023 16:46:54 +0000 Subject: [ARIN-consult] Consultation on Pending Functionality for Automatic Creation of IRR Route Objects for Uncovered ROAs In-Reply-To: References:

Message-ID: <1C9AB295-6750-4D4B-A2A5-E913F39547DF@arin.net> > On Aug 18, 2023, at 3:30 PM, Dale W. Carder wrote: > > Thus spake ARIN (info at arin.net) on Thu, Aug 10, 2023 at 03:32:21PM -0400: >> - Should the automatic creation of IRR route objects for resources that have RPKI ROAs be compulsory, the default setting, or require explicit opt-in? > > First, I believe we are here because in essence, ARIN violated the > Principal Of Least Astonishment as new functionality rolled out with > no warning. Our org for example had very recently created a new > ROA, and then got a surprise as monitoring detected a new IRR object > getting created that we did not explicitly create. Dale - You are entirely correct ? ARIN failed here by deploying something with potential operational impact without adequate community engagement beforehand. This was my error ? as I allowed the ARIN Online release to occur under the misapprehension that the intended linkage with IRR object creation was to be optional in nature. Upon realizing this was not the case, I directed the team to rollback so that we could conduct this community consultation to determine the desired behavior. (I have also put some corrective measures in place to make sure future releases with any potential customer impact ? such as routing linkage requiring an ?opt-out? ? will have a much higher bar to meet in terms of community engagement.) > I believe for new routing security initiatives to have successful > uptake, the tooling presented should have reasonable, secure, and > safe defaults that "do the right thing" covering the majority of > Organizations. Note, "safe defaults" here really, really should > include ACSP Suggestion 2022.30. > > I am estimating the default behavior should skew heavily towards > Orgs who are relatively uncomplicated, and for them, the automagic > maintenance of IRR objects can be a huge win in terms of simplicity > as well as providing immediate benefit for the Internet at large > with more data in trustworthy IRR sources. That reflects the intended goal of the recent (mishandled) IRR route object feature rollout. > We do need to recognize there are Orgs for whom this default behavior > would not be necessary, or perhaps even reasonable. I would believe > them to be in the minority. A few have chimed in as part of this > discussion and to me, this effectively makes a case for opt-out > functionality, communicated well in advance. > > I do not believe that opt-in is the correct approach to further this > aspect of Internet security, as it puts the burden to "do something" > in too many unincentivized hands, furthering stagnation. > >> - Should IRR Objects be managed via a direct linkage to a ROAs such that they can only be deleted through deletion of the covering ROA, or should ARIN continue to support independent management of IRR route objects? > > Both options may need to exist. I would expect that a Delegated > or Hybrid publish-in-parent RPKI customer would still need > independent management of IRR route objects in any case. > > I would propose linked ROA-IRR route object mode as the default > for Hosted RPKI Orgs, and have full manual let me shoot myself > in the foot mode be available as an option for them as well as > anyone else. That seems a very reasonable position, and with appropriate community communication should provide the desired value without adversely impacting those who wish more fine-grain control. >> - Should ARIN automatically create managed IRR Route Objects for all validated ROAs in the Hosted RPKI repository that do not have matching IRR Route Objects today? > > Yes, w/ opt-out functionality per Org. > >> - If so, what is the anticipated benefit of doing so? Conversely, if this functionality is not desired, why not? > > I believe that as a community we need to actively deprecate all > use of non-RIR IRR source databases. We can get a long way there > through safe, reasonable default behavior that benefits the majority > of Orgs. > >> - If a customer agrees to link a ROA with the IRR, what is the appropriate number of route objects that should be created based on the ROA prefix and max length configuration? > > One. > > Taking a logical step from RFC9319, as a community, we should be > working towards a 1:1:1 mapping of Minimal ROA, IRR route object, > and the prefix seen in the DFZ. To do anything other than that > should require "effort". Acknowledged. >> We sincerely apologize for any inconvenience that pausing this functionality may have caused and appreciate your understanding as we work to ensure that our services are aligned with the interests of the community. > > Thanks for consulting the community! I believe had this been > communicated in advance, any discussion could have preceded the > implementation (and rollback). Let's work together to get the > future communication right, and as an upcoming opportunity > consider the process we should use for ASPA. Indeed ? and thanks again for taking the time to provide the feedback! /John John Curran President and CEO American Registry for Internet Numbers From info at arin.net Fri Aug 25 13:31:35 2023 From: info at arin.net (ARIN) Date: Fri, 25 Aug 2023 13:31:35 -0400 Subject: [ARIN-consult] RPKI/IRR Consultation Reminder and Update Message-ID: <186236C4-8CBA-42D3-B0E6-D7B2C32F1550@arin.net> ARIN would like to remind the community about the ongoing consultation on possible new features in ARIN Online that will provide tighter integration of ARIN?s Resource Public Key Infrastructure (RPKI) and Internet Routing Registry (IRR) routing security services. This consultation is slated to close on Sunday, 10 September, so be sure to submit your comments to the arin-consult mailing list before then. Read the full text of the consultation at: https://www.arin.net/participate/community/acsp/consultations/2023/2023-4/ As of 24 August, we have received a range of opinions on how best to proceed. As a result of the feedback received so far, we are planning to develop the following features: - A per-OrgID setting entitled ? Automatic IRR Route Object Maintenance for RPKI ROAs?. This setting will be ?on? by default when we add it to all OrgIDs, but customers can readily turn it off - On the Routing Security Dashboard, there will be a checkbox entitled ?Automatic IRR Route Object Maintenance? which is where an Org can opt-out of the default IRR route automation - At the Org ID level, there will be an option for a one-time ?catch up? that will automatically create Route Objects for each ROA in question. This one time ?catch up? will also result in existing Route Objects being automatically maintained. We are also planning to make the following changes to RPKI and IRR functionality: - Upon creation or removal of a ROA with the default automation attribute set to on, we will make the appropriate change to corresponding IRR Route Object(s) - When a Route Object is automatically generated by ROA creation, its existence is dependent on the ROA; however, the customer will maintain the ability to delete or modify the Route Object and not impact the state of its corresponding ROA Regarding the question of the appropriate number of Route Objects that should be created based on the ROA prefix and max length configuration, ARIN plans to provide an additional checkpoint that will require a user to positively select the option to apply a maxLength value, only after being presented with information about the RFC 9319 best practice recommendation to limit the use of maxLength in ROAs, and the exposure to a potential forced origin sub-prefix hijack with a liberal use of maxLength. If an organization has automatic IRR generation turned on, and a maxLength is set on a ROA, ARIN will generate the IRR Route Object with the least specific match based on the prefix(s) in the triggering ROA. There has been strong and consistent feedback against automatically creating managed IRR Route Objects for all validated ROAs in the Hosted RPKI repository that do not have matching IRR Route Objects, so we will not force this action. No IRR objects will be created without the customers' expressed permission. There is still time to share your thoughts on this important consultation on pending features and functionality that will integrate ARIN?s routing security services. We would appreciate your feedback on the changes proposed above. Please provide your comments to arin-consult at arin.net. You can subscribe to this mailing list at: http://lists.arin.net/mailman/listinfo/arin-consult. We look forward to your feedback on this important topic. Regards, John Curran President and CEO American Registry for Internet Numbers (ARIN)