[ARIN-consult] RPKI/IRR Consultation Reminder and Update

[Job Snijders]

Dear ARIN & community,

Thank you for this opportunity to provide feedback on proposed changes!

[ TL;DR - by and large the proposed changes are a positive step forward
  in harmonizing IRR & RPKI ROAs, this is beneficial to the community
  as it removes friction in operations: maintaining data in 2 places
  always leads to discrepancies ]

Before venturing into the questions put forward by this consultation,
I'd like to share some background on my own experiences harmonizing IRR
& RPKI: I am the initiator of the IRRd v4 project (http://irrd.net/),
and its RPKI integration. In IRRdv4 the integration was twofold: the
first aspect is that *all* RPKI ROAs are transformed into IRR
route/route6 objects, the second aspect is that IRR consumers (bgpq4,
irrtoolset, etc) are blinded from RPKI-invalid route/route6 objects.
This latter aspect in effect made RPKI a 'higher source of truth', and
permitted operators to focus their energy only on configuring RPKI ROAs,
as the associated IRR route/route6 objects automatically were
instantiated tracking the associated ROAs. IRRdv4 nowadays is deployed
at major transit carriers, multiple RIRs, and multiple major third-party
IRR databases. I also was a driving force behind the ARIN/ARIN-NONAUTH
split, the RIPE/RIPE-NONAUTH split, the RPKI-based filtering mechanism
of RIPE-NONAUTH (RIPE-731), and the upcoming deprecation of the
'OriginAS' attribute in the ARIN-WHOIS database.

As it stands, many operators already today enjoy (indirect) benefit from
the design choices of IRRdv4 and tools like 'bgpq4'. I argue that we
should be careful not dismiss prior work and experiences at
Internet-scale in this space.

On Fri, Aug 25, 2023 at 01:31:35PM -0400, ARIN wrote:
> 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 

I've not yet seen anyone argue a compelling case why it should be made
possible to turn this off. Also, over the years of IRRd v4 deployments I
have not seen requests to opt-out of RPKI-based automatic instantiation
of IRR route/route6 object. Therefor I fear that allowing customers to
opt-out might lead to both needless complications in the codebase &
support procedures, for no obvious benefit other than "more buttons is
more better" (which usually really isn't better). I see an opportunity
to improve things in a central location (ARIN's IRR), and think that the
trigger for these improvements should not be pushed down to requiring
action from thousands of Orgs operators.

> - 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 

I don't think Orgs should be able to opt-out. In my years of experience
with RPKI-to-IRR mechanisms this did not came up as a request. As it
stands, in the world's deployments of the RFC 6811 Route Origin
Validation procedure the existence of ROAs takes precedent over
subsequent ingress EBGP filtering. There are benefits to 'downsampling'
RPKI-to-IRR, but not for the IRR to contain information inconsistent
with the RPKI.

> - 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.  

I believe the "catch up" should happen automatically, and not require
operator intervention. The leading principle here is that data addition
to IRR databases is benign. The existence of a "catch up"-button implies
that thousands of Orgs need to understand and edifice themselves as to
the exact ramifications (which are beneficial, as shown by prior work in
this space), and the more barriers to entry are introduced the more
operators drop off, potentially partially nullifying the goal of this
project.

> 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) 

Nice!

> - 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 

I would prefer a simpler mechanism, because making it technically
possible to have discrepancies between IRR and RPKI *will* cause
discrepancies between IRR and RPKI to exist. The more discrepancies
exist, the harder it becomes in the future to fully transition from IRR
(an unsafe plain-text relic from the past) to modern cryptographically
secure attestations like RPKI ROAs.

> 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. 

Am I correct in my understanding that the conclusion was that the
appropriate number of Route Objects is 1 (one), regardless of the
maxLength value submitted by the user? If yes, that indeed would be my
preference, and align with the established practise as promoted by the
various deployments of IRRdv4.

> 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. 

I'd like to receive more information from the opposition as to why not.
Again, the aforementioned previous experiences show that 'automation' is
key to the success, and reduces the burden. RPKI should be considered
the higher source of truth, and it makes a lot of sense to me to
coalesce the higher-source-of-truth into the existing ARIN IRR.

Thanks!

Kind regards,

Job