Mailing List Archive: Changes to ARIN Online - Routing Security Dashboard - RPKI & IRR integration (was: Fwd: [arin-announce] New Features Added to ARIN Online)

Changes to ARIN Online - Routing Security Dashboard - RPKI & IRR integration (was: Fwd: [arin-announce] New Features Added to ARIN Online)

jcurran at arin

Aug 7, 2023, 11:24 AM

Post #1 of 8 (218 views)

Permalink

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.

Re: Changes to ARIN Online - Routing Security Dashboard - RPKI & IRR integration (was: Fwd: [arin-announce] New Features Added to ARIN Online) [ In reply to ]

nanog at nanog

Aug 7, 2023, 4:30 PM

Post #2 of 8 (218 views)

Permalink

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

Re: Changes to ARIN Online - Routing Security Dashboard - RPKI & IRR integration (was: Fwd: [arin-announce] New Features Added to ARIN Online) [ In reply to ]

markk at arin

Aug 8, 2023, 8:59 AM

Post #3 of 8 (215 views)

Permalink

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

Re: Changes to ARIN Online - Routing Security Dashboard - RPKI & IRR integration (was: Fwd: [arin-announce] New Features Added to ARIN Online) [ In reply to ]

nanog at nanog

Aug 8, 2023, 11:18 AM

Post #4 of 8 (215 views)

Permalink

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

Re: Changes to ARIN Online - Routing Security Dashboard - RPKI & IRR integration (was: Fwd: [arin-announce] New Features Added to ARIN Online) [ In reply to ]

jayb at braeburn

Aug 9, 2023, 7:19 AM

Post #5 of 8 (215 views)

Permalink

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.

Re: Changes to ARIN Online - Routing Security Dashboard - RPKI & IRR integration (was: Fwd: [arin-announce] New Features Added to ARIN Online) [ In reply to ]

markk at arin

Aug 9, 2023, 11:42 AM

Post #6 of 8 (215 views)

Permalink

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

Re: Changes to ARIN Online - Routing Security Dashboard - RPKI & IRR integration (was: Fwd: [arin-announce] New Features Added to ARIN Online) [ In reply to ]

jcurran at arin

Aug 9, 2023, 3:19 PM

Post #7 of 8 (215 views)

Permalink

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

Re: Changes to ARIN Online - Routing Security Dashboard - RPKI & IRR integration (was: Fwd: [arin-announce] New Features Added to ARIN Online) [ In reply to ]

markk at arin

Aug 10, 2023, 10:54 AM

Post #8 of 8 (203 views)

Permalink

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