Send ARIN-consult mailing list submissions to
arin-consult@arin.net
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.arin.net/mailman/listinfo/arin-consult
or, via email, send a message with subject or body 'help' to
arin-consult-requ...@arin.net
You can reach the person managing the list at
arin-consult-ow...@arin.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of ARIN-consult digest..."
Today's Topics:
1. Re: Consultation on Pending Functionality for Automatic
Creation of IRR Route Objects for Uncovered ROAs (Dale W. Carder)
----------------------------------------------------------------------
Message: 1
Date: Fri, 18 Aug 2023 14:30:57 -0500
From: "Dale W. Carder" <dwcar...@es.net>
To: ARIN <i...@arin.net>
Cc: arin-consult@arin.net
Subject: Re: [ARIN-consult] Consultation on Pending Functionality for
Automatic Creation of IRR Route Objects for Uncovered ROAs
Message-ID: <ZN_G8Xd2qR-0cZ2G@dwc-desktop.local>
Content-Type: text/plain; charset=us-ascii
Thus spake ARIN (i...@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
------------------------------
Subject: Digest Footer
_______________________________________________
ARIN-consult mailing list
ARIN-consult@arin.net
https://lists.arin.net/mailman/listinfo/arin-consult
------------------------------
End of ARIN-consult Digest, Vol 99, Issue 3
*******************************************
