2749 routes AT RISK - Re: TIMELY/IMPORTANT - Approximately 40 hours until potentially significant routing changes (re: Retirement of ARIN Non-Authenticated IRR scheduled for 4 April 2022)

Mon Apr 4 23:23:52 UTC 2022

>
> Cleaning it up is easy too. Publish an RPKI ROA for your space. We
> will automatically delete any route objects which disagree with an
> RPKI ROA. The routing security ecosystem should be doing that anyways.
>

"should" is a pretty tricky word to be using there.

On Mon, Apr 4, 2022 at 7:21 PM Kenneth Finnegan <
kennethfinnegan2007 at gmail.com> wrote:

> On Mon, Apr 4, 2022 at 4:04 PM Nick Hilliard <nick at foobar.org> wrote:
> > Please don't.
> >
> > You're not doing the routing security ecosystem any favours by doing
> > this.
>
> The routing security ecosystem is less of a concern to me than the
> lone network engineer at some water district or county who were about
> to have a really bad / confusing few days while they tried to figure
> out why their Internet is somewhere between slightly and completely
> broken due to no action of their own.
>
> > Couple of reasons why: 1. this isn't your data and this is an
> > unexpected action on the part of the registrants,
>
> The registrants had a year to fix this themselves, and they didn't,
> which implies to me that they are unaware of the issue. How can
> something be unexpected to those who are unaware?
>
> > 2. this is a sure-fire
> > way of accumulating even more cruft in ALTDB in a way which is
> > troublesome to clean up afterwards,
>
> Is it? What is terrible about cruft sitting in IRR databases? It
> doesn't cause conflict with anyone else announcing their new address
> space from any other ASN.
>
> Cleaning it up is easy too. Publish an RPKI ROA for your space. We
> will automatically delete any route objects which disagree with an
> RPKI ROA. The routing security ecosystem should be doing that anyways.
>
> > 3. there are several thousand
> > objects in there which are already marked as proxy registrations, and
> > are already likely to be inaccurate,
>
> And there's lots of non-proxy registrations which are inaccurate too.
> The fact that RPSL was so contrived and routing security has been so
> sidecar for decades that carriers have found it easier to create proxy
> registrations vs getting their customers to go spend money on an RADB
> account or figure out this IRR thing in general means that proxy
> registrations are a reality we live in.
>
> IRR objects lacking any kind of expiration date was a failing of the
> original design. Proxy registration or not, when a company shuts down
> operations, there is kind of by definition no one left around to care
> about cleaning up their IRR records. If RIRs published RPKI ROAs for
> unallocated space to AS0 to give us an authoritative way to know that
> the address space is defunct, clean up could happen automatically. I
> looked into using the RIR registration databases to try and find
> objects which predate the current allocation, but even that data isn't
> clean enough to trace which objects are actually "stale" in some
> definition of the term.
>
> > 4. you're losing authentication
> > information for people to self-manage their registrations
>
> Anyone on that list who would like to self-manage your IRR objects,
> PLEASE email me saying so. Bonus points if you include a reason why
> you waited until T-0 to change your mind on managing them.
>
> --
> Kenneth Finnegan
> http://blog.thelifeofkenneth.com/
>
> On Mon, Apr 4, 2022 at 4:04 PM Nick Hilliard <nick at foobar.org> wrote:
> >
> > Kenneth Finnegan wrote on 04/04/2022 21:05:
> > > I've taken it upon myself to create
> > > proxy registrations for all of these prefixes in ALTDB.
> >
> > Please don't.
> >
> > You're not doing the routing security ecosystem any favours by doing
> > this. Couple of reasons why: 1. this isn't your data and this is an
> > unexpected action on the part of the registrants, 2. this is a sure-fire
> > way of accumulating even more cruft in ALTDB in a way which is
> > troublesome to clean up afterwards, 3. there are several thousand
> > objects in there which are already marked as proxy registrations, and
> > are already likely to be inaccurate, 4. you're losing authentication
> > information for people to self-manage their registrations, and 5. you
> > have likely not cross-checked this data against RIR transfers /
> > de-registrations - it's not really possible to do with with the
> > arin-nonauth db because that db doesn't include the last-modified
> > timestamp, and the changed: attribute is unreliable.
> >
> > Nick
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20220404/6e03af1a/attachment.html>