On Mon, Apr 4, 2022 at 4:04 PM Nick Hilliard <nick@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@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