Send ARIN-consult mailing list submissions to
[email protected]
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
[email protected]
You can reach the person managing the list at
[email protected]
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 (John Curran)
2. Re: Consultation on Pending Functionality for Automatic
Creation of IRR Route Objects for Uncovered ROAs (John Curran)
----------------------------------------------------------------------
Message: 1
Date: Sat, 19 Aug 2023 16:46:54 +0000
From: John Curran <[email protected]>
To: "Dale W. Carder" <[email protected]>
Cc: "<[email protected]>" <[email protected]>
Subject: Re: [ARIN-consult] Consultation on Pending Functionality for
Automatic Creation of IRR Route Objects for Uncovered ROAs
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
> On Aug 18, 2023, at 3:30 PM, Dale W. Carder <[email protected]> wrote:
>
> Thus spake ARIN ([email protected]) 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
------------------------------
Message: 2
Date: Sat, 19 Aug 2023 16:46:55 +0000
From: John Curran <[email protected]>
To: "Dale W. Carder" <[email protected]>
Cc: "<[email protected]>" <[email protected]>
Subject: Re: [ARIN-consult] Consultation on Pending Functionality for
Automatic Creation of IRR Route Objects for Uncovered ROAs
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
> On Aug 18, 2023, at 3:30 PM, Dale W. Carder <[email protected]> wrote:
>
> Thus spake ARIN ([email protected]) 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
------------------------------
Subject: Digest Footer
_______________________________________________
ARIN-consult mailing list
[email protected]
https://lists.arin.net/mailman/listinfo/arin-consult
------------------------------
End of ARIN-consult Digest, Vol 99, Issue 4
*******************************************
