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
Dear John, ARIN, NANOG,
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:
Dear Mark,
Thank you for sharing all the details in your previous email. For
brevity I'm snipping most of your reply.
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 RFC 9319 - The Use of maxLength in the Resource Public Key Infrastructure (RPKI). 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:"
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
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