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