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