> > 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 < kennethfinnegan2...@gmail.com> wrote: > 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 >
