[arin-ppml] Draft Policy ARIN-2021-8: Deprecation of the 'Autonomous System Originations' Field

Tue Apr 26 20:07:47 EDT 2022

I'd be fine with eliminating section 3.5 of the NRPM now, and a deprecation
timeline for the Origin AS field in the 2-5 year timeframe that Andrew is
suggesting.  Furthermore, I'm fine with ARIN leveraging the new IRR and
RPKI to get legacy holders to sign the LRSA. But if we want to do that ARIN
shouldn't deprecate Origin AS, in the short term, that is less than a 2-5
year timeframe. Otherwise, if the priority is seen as deprecating the
Origin AS field, in the short term, then legacy holders should be
allowed access to the new IRR.

Thanks

On Tue, Apr 26, 2022 at 5:19 PM Andrew Dul <andrew.dul at quark.net> wrote:

> Legacy holders have the option to add records to ARIN’s authenticated irr.
> It only requires them to sign an lrsa or rsa. In my opinion it is time for
> the free ride for legacy holders to end.
>
> I have no problem with a sunset date say 2-5 years from now but we need to
> move in that direction.
>
> Speaking only for myself and not for any organization or in any position.
>
> Andrew
>
>
> > On Apr 26, 2022, at 14:39, Scott Leibrand <scottleibrand at gmail.com>
> wrote:
> >
> > IMO there is a need for number resource holders to be able to attest
> (solely) that a given origin ASN is (solely) authorized to announce
> route(s) for those number resources.
> >
> > Most forms of RPKI, like DNSSEC, are really easy to screw up in such a
> way that you knock your own services off the Internet. As long as that
> remains true, it will likely never get to 100% adoption. If it does, it
> will be because it allows number resource holders to make attestations via
> the RIRs as to who is authorized to announce their route(s), without
> requiring the resource holders to sign their route announcements in such a
> way that screwing up key rotation will cause them to be rejected.
> >
> > Fully authenticated IRR solutions can provide all the same services that
> putting an origin ASN into whois provides, but only for non-legacy
> resources. Until ARIN is willing to provide basic authenticated IRR
> services to legacy resource holders, it seems we still need the origin ASN
> field as long as it continues to be used.
> >
> > Scott
> >
> >> On Apr 26, 2022, at 9:07 PM, James Hulce via ARIN-PPML <
> arin-ppml at arin.net> wrote:
> >>
> >> snipped, with inline comments
> >>> On Tue, Apr 26, 2022 at 1:07 PM Job Snijders via ARIN-PPML
> >>> <arin-ppml at arin.net> wrote:
> >>> I'm the one who initiated the process towards ARIN-2021-8. I've put in
> >>> considerable effort to find a purpose and use for the ARIN Originations
> >>> field in automated tool chains, and ultimately concluded the field has
> >>> so many apparent challenges it might be better to get rid of it,
> >>> especially since IRR and RPKI nowadays exist.
> >> Job, thanks for coming here to explain your perspective. I, for one,
> >> was surprised to see your name attached to the original policy
> >> proposal given all of your past work in this space.
> >>
> >>>>> On Tue, Apr 26, 2022 at 11:53:58AM -0500, David Farmer via ARIN-PPML
> wrote:
> >>>>> While I do not support the deprecation of the 'Autonomous System
> >>>>> Originations' Field from the database at this time for many of the
> reasons
> >>>>> discussed at the microphone at ARIN 49.
> >>>
> >>> Unfortunatey, I wasn't there. Would you be so kind to outline the many
> >>> reasons in an email?
> >> My comment: Oppose this proposal at this time. The Autonomous System
> >> Origination field in ARIN Whois occupies a peculiar yet potentially
> >> valuable place in the routing information landscape. It provides an
> >> easy and authenticated way for everyone, including legacy resource
> >> holders, to communicate their routing intentions. OriginAS does not
> >> suffer from other problems associated with IRR, such as proxy records
> >> or multiple disparate databases. Several organizations, networks, and
> >> exchanges report using the OriginAS field to generate filters and
> >> perform other operational tasks despite consumption issues. Without
> >> much known about its uptake, usage, accuracy, and role, deprecation
> >> would be premature.  (generally summarized my PPML post from last
> >> week)
> >>
> >> Attempting to outline what others said:
> >> There was general agreement around the point that ARIN Whois OriginAS
> >> is a unique, weird legacy thing and should go away eventually. There
> >> is a desire to eventually reach RPKI's promised land and retire all of
> >> the earlier outmoded and problematic routing information sources.
> >> However, we are not there yet. People from several organizations,
> >> including Lumen (nee CenturyLink & Level 3) and Internet2, expressed
> >> current operational dependencies. It has notable LOA use cases.
> >> Several commentators floated a three-year wind-down period as part of
> >> a broader transition to RPKI and authenticated IRR. I agree with that.
> >> OriginAS is intertwined with other ongoing ARIN discussions, including
> >> handling legacy resources and a la carte/standalone vs bundled
> >> registry services. Right now, there's a vast ocean of legacy resource
> >> holders locked out of ARIN's IRR and RPKI because they can't or won't
> >> sign an LRSA. This pool is gradually decreasing, but will be a
> >> consideration for a while yet. How do legacy resource holders proceed
> >> if/when OriginAS goes away?
> >> Those who were in attendance or watching: did I miss anything?
> >>
> >>>> Nevertheless, as discussed in the problem statement this field has
> >>>> several problems and it eventually needs to be deprecated. However,
> >>>> since this is an optional field within the ARIN database, without any
> >>>> enforcement actions required by policy, it seems possible to remove
> >>>> section 3.5 from the NRPM at this time, without also deprecating the
> >>>> field at this time.
> >>>>
> >>>> Further, this would set things up for the future deprecation of the
> >>>> 'Autonomous System Originations' Field from the database to proceed
> when
> >>>> the community feels that is appropriate, as expressed through a
> separate
> >>>> ARIN Consultation Process, without necessitating additional policy
> actions.
> >>>>
> >>>> If this policy proposal were modified to only remove section 3.5 from
> the
> >>>> NRPM at this time, with the deprecation of the 'Autonomous System
> >>>> Originations' Field from the database occurring at some future date,
> to be
> >>>> determined at a later time by the ARIN community, I would support this
> >>>> policy proposal proceeding forward.
> >>>
> >>> Why do you favor a separate consultation?
> >>
> >> So, this is kind of a weird one. Technically, ARIN services are out of
> >> the PDP scope [1]. However, ARIN's collection and distribution of AS
> >> origination information is enshrined in the NRPM. Whether or not the
> >> existence of Whois OriginAS and NRPM 3.5 are necessarily coupled is
> >> not fully clear to me. I interpreted them as one and the same and I
> >> think much of the community did as well. Notably, some other
> >> informational services have no NRPM mention at all. There's zero
> >> mention of RPKI, for example. Someone from ARIN or the AC could
> >> clarify this point.
> >>
> >> All in all, I could support a future/revised proposal eventually
> >> getting rid of OriginAS. Here's what needs to happen, from my view:
> >> First, we need usage info to quantify what's at stake here. What is
> >> the real usage and impact of OriginAS? Who would be most impacted by
> >> deprecation?
> >> Second, everyone must have viable alternatives.
> >> Third, the wind-down should take lessons from ARIN-Nonauth. Publicize
> >> it well, offer support, and take it slow. This policy proposal was
> >> flying under the radar and proposed an overly fast timeline.
> >>
> >> - James
> >>
> >> [1]
> https://www.arin.net/participate/policy/pdp/#3-1-policies-not-processes-fees-or-services
> >> _______________________________________________
> >> ARIN-PPML
> >> You are receiving this message because you are subscribed to
> >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> >> Unsubscribe or manage your mailing list subscription at:
> >> https://lists.arin.net/mailman/listinfo/arin-ppml
> >> Please contact info at arin.net if you experience any issues.
> > _______________________________________________
> > ARIN-PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > https://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
>
> _______________________________________________
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>

-- 
===============================================
David Farmer               Email:farmer at umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20220426/c4de583b/attachment.htm>