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

[John Curran]

> On Aug 18, 2023, at 3:30 PM, Dale W. Carder <dwcarder at es.net> wrote:
> 
> 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.

Dale - 

You are entirely correct – ARIN failed here by deploying something with potential operational impact without adequate community engagement beforehand. 

This was my error – as I allowed the ARIN Online release to occur under the misapprehension that the intended linkage with IRR object creation was to be optional in nature.  Upon realizing this was not the case, I directed the team to rollback so that we could conduct this community consultation to determine the desired behavior.   (I have also put some corrective measures in place to make sure future releases with any potential customer impact – such as routing linkage requiring an “opt-out” – will have a much higher bar to meet in terms of community engagement.) 

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

That reflects the intended goal of the recent (mishandled) IRR route object feature rollout. 

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

That seems a very reasonable position, and with appropriate community communication should provide the desired value without adversely impacting those who wish more fine-grain control. 

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

Acknowledged. 

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

Indeed – and thanks again for taking the time to provide the feedback! 
/John

John Curran
President and CEO
American Registry for Internet Numbers