Changes to ARIN Online - Routing Security Dashboard - RPKI & IRR integration (was: Fwd: [arin-announce] New Features Added to ARIN Online)
NANOGers - We have made some fairly significant changes for those customers using ARIN Online for routing security administration – see attached message for specifics. FYI, /John John Curran President and CEO American Registry for Internet Numbers Begin forwarded message: From: ARIN <info@arin.net> Subject: [arin-announce] New Features Added to ARIN Online Date: August 7, 2023 at 1:37:51 PM EDT To: <arin-announce@arin.net> ARIN is pleased to present the latest version of ARIN Online, including improvements, new features, and updates. Full release notes are included at the end of this message. All ARIN systems have been restored and are now operating normally. We thank you for your patience. If you have additional questions, comments, or issues, please submit an Ask ARIN ticket using your ARIN Online account or contact the Registration Services Help Desk by phone Monday through Friday, 7:00 AM to 7:00 PM ET at +1.703.227.0660. Regards, Mark Kosters Chief Technology Officer American Registry for Internet Numbers (ARIN) Release Notes - Navigation and eligibility status for ARIN’s routing security services, the Resource Public Key Infrastructure (RPKI), and Internet Routing Registry (IRR) have been condensed into a single Routing Security Dashboard in ARIN Online. We have also made the navigation of the IRR pages consistent with the RPKI portions of the website. - Abuse, Network Operation Center (NOC), and DNS Points of Contact now have read-only viewing privileges for RPKI details in both ARIN Online and the RESTful API. - Creating a new Route Origin Authorization (ROA) in ARIN Online now automatically creates and manages the matching IRR Route Objects based on the ROA prefix and max length configuration. If the creation of a ROA would result in more than 256 IRR Route Objects, no managed IRR Route Objects will be created. Managed IRR Route Objects may not be removed independently of their covering ROAs. Deleting a ROA in ARIN Online will automatically delete its corresponding managed IRR Route Objects. In the coming weeks, ARIN will create managed IRR Route Objects for all preexisting ROAs that do not currently have matching IRR Route Objects. Preexisting IRR Route Objects that match ROAs will be associated with the covering ROA. - To create feature parity with templates, we have added the capability to modify reassignment information within ARIN Online without any changes to the registration date. - Customers can begin the application process for the Qualified Facilitator Program in ARIN Online. ARIN Qualified Facilitators serve as resources for the community by assisting organizations seeking to acquire or transfer IPv4 or Autonomous System Number (ASN) resources. _______________________________________________ ARIN-Announce You are receiving this message because you are subscribed to the ARIN Announce Mailing List (ARIN-announce@arin.net). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-announce Please contact info@arin.net if you experience any issues.
Dear John, ARIN, NANOG, On Mon, Aug 07, 2023 at 06:24:09PM +0000, John Curran wrote:
We have made some fairly significant changes for those customers using ARIN Online for routing security administration – see attached message for specifics.
Yes, significant changes! I very much appreciate ARIN's efforts to streamline IRR & RPKI operations for INR holders. :-) I too think that having to enter "sorta similar" data in 2 places of course is more prone to error (in terms of internal discrepancies between the two inputs of data) compared to entering routing data in just one place. I imagine the scheduled simplification of the user interface (intertwining IRR & RPKI) will lead to improved data accuracy and fewer operator errors. Thank you ARIN for that! I think the industry's transition from plain-text IRR data towards cryptographically verifiable RPKI data really starts happening when there are automated processes coupling the two sets of data, and indeed also retroactively glueing the two together (within ARIN's auspices the 'ARIN Online' environment). A few questions arose in my mind while wondering about implementation aspects on ARIN's side: - is the IRR state directly derived from the RPKI state? An example for context: should some kind of unfortunate failure happen in ARIN's HSMs and thusly a new Manifest + CRL pair isn't signed and published before the 'nextUpdate' timestamp of the previous pair, would the associated IRR objects be deleted via NRTM? Or is the creation of ROAs and IRR route:/route6: objects discoupled in the sense that an operator creates an abstract object which then is transformed into both IRR and RPKI objects? - What is the expected delay (if any) between creating a RPKI ROA and the associated IRR route/route6 objects appearing via NRTM? Is there online documentation outlining expectations, and is there internal monitoring on the delivery of the RPKI-to-IRR transformation service? - The documentation states "If the creation of a ROA would result in more than 256 IRR Route Objects, no managed IRR Route Objects will be created." - but, why not? Would it not be advantageous to create at a minimum the 256 of the 'least-specific' objects? I wonder if the current approach violates the principle of least astonishment in the sense that an operator picking an unfortunate 'maxLength' value results in no IRR objects at all. Kind regards, Job
Hi Job Answers below starting with MK: On 8/7/23, 7:31 PM, "NANOG on behalf of Job Snijders via NANOG" <nanog-bounces+markk=arin.net@nanog.org <mailto:arin.net@nanog.org> on behalf of nanog@nanog.org <mailto:nanog@nanog.org>> wrote: - is the IRR state directly derived from the RPKI state? MK: No. This is all done in software. First a ROA is generated, then one or more IRR objects based on how the ROA was defined by the user. An example for context: should some kind of unfortunate failure happen in ARIN's HSMs and thusly a new Manifest + CRL pair isn't signed and published before the 'nextUpdate' timestamp of the previous pair, would the associated IRR objects be deleted via NRTM? Or is the creation of ROAs and IRR route:/route6: objects discoupled in the sense that an operator creates an abstract object which then is transformed into both IRR and RPKI objects? MK: When the resource holder submits a ROA generation request, we have code that translates the ROA into the equivalent auto-managed route/route6 IRR objects, from the starting prefix to longest possible match. This process does not use the capabilities or features in third party software implementations. - What is the expected delay (if any) between creating a RPKI ROA and the associated IRR route/route6 objects appearing via NRTM? Is there online documentation outlining expectations, and is there internal monitoring on the delivery of the RPKI-to-IRR transformation service? MK: New RPKI ROAs are published every three minutes. IRR objects are published every five minutes. There is a possibility that the route object derived from a ROA could be seen in ARIN’s IRR database before the ROA in ARIN’s RPKI repository. - The documentation states "If the creation of a ROA would result in more than 256 IRR Route Objects, no managed IRR Route Objects will be created." - but, why not? MK: Our reason to limiting the creation is to protect the IRR mirroring service. A rapid influx of route object creation may overrun the IRR processes if a poor decision was made with respect to the use of the maxlength field. For example a 205.188.0.0/16 maxlength 24 ROA, would generate 511 IRR route objects (( 2^( prefix_length - max_length + 1 ))- 1). We may revisit this maximum limit in the future. Would it not be advantageous to create at a minimum the 256 of the 'least-specific' objects? MK: That may be a reasonable approach. Do you see any adverse effects in simplifying the IRR Route creation logic to just have least-specific? Thanks, Mark
Dear Mark, Thank you for sharing all the details in your previous email. For brevity I'm snipping most of your reply. On Tue, Aug 08, 2023 at 03:59:19PM +0000, Mark Kosters wrote:
Job Snijders wrote:
Would it not be advantageous to create at a minimum the 256 of the 'least-specific' objects?
MK: That may be a reasonable approach. Do you see any adverse effects in simplifying the IRR Route creation logic to just have least-specific?
I don't think I see a downside of mapping a single VRP to a single IRR route/route6 object. Synthesizing only the least-specific is how RPKI-integration was implemented in IRRd v4, and that implemntation has seen quite some flight hours by now. The approach seemed to work well in the last ~ 5 years. No request ever came up to extend IRRd v4 to synthesize (a limited number of) more-specific route/route6 objects if maxLength was present in the ROA generation request. IRRd v4 does expose the 'maxLength' value by inserting a non-standard RPSL attribute called 'max-length:' in the route/route6 object. While this is not IETF-standardized, it seemed intuitive enough. RPSL parsers are expected to ignore what they don't recognize anyway. ARIN could mimick this practise. See the following example: $ whois -h rr.ntt.net -- '-s RPKI -T route6 2001:67c:208c::/48' \ | egrep "route6|max-length|origin" | paste - - - route6: 2001:67c:208c::/48 max-length: 48 origin: AS0 route6: 2001:67c:208c::/48 max-length: 48 origin: AS15562 I'd suggest to consider simplying the IRR creation logic to just a singular least-specific route/route object, and not bother with generating 'potentially up to 256' more-specific route/route6 objects. I see a few advantages: G* Every single VRP resulting from a ROA generation request will always result in the instantiation of exactly one IRR route/route6 object. As I understand the current proposal, sometimes a route/route6 object is created, sometimes not, depending on the value of the maxLength. In this I see a source for potential confusion. * By creating just 1 route/route6 object per validated ROA payload, any potential load on the NRTM mirror ecosystem is minimized to the fullest extend possible: 65,285 ROAs on 'rpki.arin.net' will result in 72,082 Validated ROA Payloads thus result in 13,933 'route6:' objects and 58,149 'route:' objects. A significant smaller number compared to expanding up to 256 additional objects if maxLength is set wide enough. * the use of maxLength isn't really recommended anyway, see BCP 185 / RFC 9319 https://datatracker.ietf.org/doc/html/rfc9319. As a rule of thumb I recommend: 1 BGP announcement == 1 ROA == 1 IRR object and avoid just using maxLength all together. * Most transit providers and IXP route server operators create so-called 'upto /24' prefix-list-filters, regardless of maxLength values. So in the vast majority of cases I don't think the additional up to 256 more-specific route objects would change anything. Finally, if people can articulate why exactly synthesizing up to 256 more-specific route objects really would be a useful feature, it can always be added at a later point in time. Adding extra objects to the IRR has always been easier than removing them. :-) Thanks! Kind regards, Job
Job Snijders via NANOG writes:
Would it not be advantageous to create at a minimum the 256 of the 'least-specific' objects?
MK: That may be a reasonable approach. Do you see any adverse effects in simplifying the IRR Route creation logic to just have least-specific?
I don't think I see a downside of mapping a single VRP to a single IRR route/route6 object.
I agree that in ARIN's RPKI-->IRR synthesis, the set of route[6] objects created should not depend on the maxlength used. In Mark's phrasing, "just have least-specific." Ideally, discussion about details such as this should have occurred on some ARIN technical mailing list in the months leading up to ARIN deploying this change to production. Thanks. Jay B.
Responses inline starting with "MK:" On 8/9/23, 10:21 AM, "NANOG on behalf of Jay Borkenhagen" <nanog-bounces+markk=arin.net@nanog.org <mailto:arin.net@nanog.org> on behalf of jayb@braeburn.org <mailto:jayb@braeburn.org>> wrote: I agree that in ARIN's RPKI-->IRR synthesis, the set of route[6] objects created should not depend on the maxlength used. In Mark's phrasing, "just have least-specific." MK: I think it was Job that brought it up as a recommendation and glad to hear you agree with him. Ideally, discussion about details such as this should have occurred on some ARIN technical mailing list in the months leading up to ARIN deploying this change to production. MK: I agree that we have some improvements to make here on issues that directly impact the operations community. In fact, we will be placing the automatic creation of new route objects on hold. We are in the process of issuing a community consultation that is being formulated to solicit feedback on several technical aspects of this change. We hope to hear from you and others when this consultation is announced (it will conducted on the arin-consult mailing list - https://lists.arin.net/mailman/listinfo/arin-consult). Thanks, Mark
NANOGers - As alluded to by Mark Kosters in his message below, we are placing on hold the functionality for the automatic creation of corresponding new route objects for RPKI validated ROAs that lack such. This is being done out of an abundance of caution in order to allow us to conduct a community consultation in the near future to confirm with the operational community the desired functionality in this area. Thanks! /John John Curran President and CEO American Registry for Internet Numbers On Aug 9, 2023, at 2:42 PM, Mark Kosters <markk@arin.net> wrote: Responses inline starting with "MK:" On 8/9/23, 10:21 AM, "NANOG on behalf of Jay Borkenhagen" <nanog-bounces+markk=arin.net@nanog.org <mailto:arin.net@nanog.org> on behalf of jayb@braeburn.org <mailto:jayb@braeburn.org>> wrote: I agree that in ARIN's RPKI-->IRR synthesis, the set of route[6] objects created should not depend on the maxlength used. In Mark's phrasing, "just have least-specific." MK: I think it was Job that brought it up as a recommendation and glad to hear you agree with him. Ideally, discussion about details such as this should have occurred on some ARIN technical mailing list in the months leading up to ARIN deploying this change to production. MK: I agree that we have some improvements to make here on issues that directly impact the operations community. In fact, we will be placing the automatic creation of new route objects on hold. We are in the process of issuing a community consultation that is being formulated to solicit feedback on several technical aspects of this change. We hope to hear from you and others when this consultation is announced (it will conducted on the arin-consult mailing list - https://lists.arin.net/mailman/listinfo/arin-consult). Thanks, Mark
Following up on John Curran's note, we just deployed a new release of ARIN Online at approx. 16:10 UTC today (10 Aug 2023). Here are the release notes: ARIN has completed a new release to pause functionality deployed on 7 August 2023 that creates corresponding IRR Route Objects for every 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. Regards, Mark From: NANOG <nanog-bounces+markk=arin.net@nanog.org> on behalf of John Curran <jcurran@arin.net> Date: Wednesday, August 9, 2023 at 6:20 PM To: NANOG <nanog@nanog.org> Subject: Re: Changes to ARIN Online - Routing Security Dashboard - RPKI & IRR integration (was: Fwd: [arin-announce] New Features Added to ARIN Online) NANOGers - As alluded to by Mark Kosters in his message below, we are placing on hold the functionality for the automatic creation of corresponding new route objects for RPKI validated ROAs that lack such. This is being done out of an abundance of caution in order to allow us to conduct a community consultation in the near future to confirm with the operational community the desired functionality in this area. Thanks! /John John Curran President and CEO American Registry for Internet Number
participants (4)
-
Jay Borkenhagen -
Job Snijders -
John Curran -
Mark Kosters