[ARIN-consult] Consultation on Pending Functionality for Automatic Creation of IRR Route Objects for Uncovered ROAs

[Dale W. Carder]

Thus spake ARIN (info at arin.net) on Thu, Aug 10, 2023 at 03:32:21PM -0400:
> - Should the automatic creation of IRR route objects for resources that have RPKI ROAs be compulsory, the default setting, or require explicit opt-in?

First, I believe we are here because in essence, ARIN violated the
Principal Of Least Astonishment as new functionality rolled out with
no warning.  Our org for example had very recently created a new 
ROA, and then got a surprise as monitoring detected a new IRR object 
getting created that we did not explicitly create.

I believe for new routing security initiatives to have successful 
uptake, the tooling presented should have reasonable, secure, and 
safe defaults that "do the right thing" covering the majority of 
Organizations.  Note, "safe defaults" here really, really should 
include ACSP Suggestion 2022.30.

I am estimating the default behavior should skew heavily towards 
Orgs who are relatively uncomplicated, and for them, the automagic 
maintenance of IRR objects can be a huge win in terms of simplicity
as well as providing immediate benefit for the Internet at large
with more data in trustworthy IRR sources.

We do need to recognize there are Orgs for whom this default behavior
would not be necessary, or perhaps even reasonable.  I would believe
them to be in the minority.  A few have chimed in as part of this 
discussion and to me, this effectively makes a case for opt-out 
functionality, communicated well in advance.  

I do not believe that opt-in is the correct approach to further this
aspect of Internet security, as it puts the burden to "do something"
in too many unincentivized hands, furthering stagnation.
 
> - Should IRR Objects be managed via a direct linkage to a ROAs such that they can only be deleted through deletion of the covering ROA, or should ARIN continue to support independent management of IRR route objects?

Both options may need to exist.  I would expect that a Delegated
or Hybrid publish-in-parent RPKI customer would still need 
independent management of IRR route objects in any case.

I would propose linked ROA-IRR route object mode as the default 
for Hosted RPKI Orgs, and have full manual let me shoot myself 
in the foot mode be available as an option for them as well as 
anyone else.
 
> - Should ARIN automatically create managed IRR Route Objects for all validated ROAs in the Hosted RPKI repository that do not have matching IRR Route Objects today?

Yes, w/ opt-out functionality per Org.
 
> - If so, what is the anticipated benefit of doing so? Conversely, if this functionality is not desired, why not?

I believe that as a community we need to actively deprecate all 
use of non-RIR IRR source databases.  We can get a long way there
through safe, reasonable default behavior that benefits the majority
of Orgs.

> - If a customer agrees to link a ROA with the IRR, what is the appropriate number of route objects that should be created based on the ROA prefix and max length configuration? 

One.  

Taking a logical step from RFC9319, as a community, we should be 
working towards a 1:1:1 mapping of Minimal ROA, IRR route object,
and the prefix seen in the DFZ.  To do anything other than that 
should require "effort".

> We sincerely apologize for any inconvenience that pausing this functionality may have caused and appreciate your understanding as we work to ensure that our services are aligned with the interests of the community.

Thanks for consulting the community!  I believe had this been
communicated in advance, any discussion could have preceded the
implementation (and rollback).  Let's work together to get the
future communication right, and as an upcoming opportunity 
consider the process we should use for ASPA.

Dale