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

Mon Aug 7 23:30:00 UTC 2023

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