Okay, as the document implies, it seems the staff is taking action only on the DB. RPKI seems to be never cleaned up. I looked at the last 30 assignments which span ~2 days and I found the following ROAs that look like being unrelated. I’m also including the AS assignment date.
AS201874 194.104.191.0/24-24 RIPENCC 2026-01-28 AS201899 91.92.251.0/24-24 RIPENCC 2026-01-27 AS201907 136.0.197.0/24-24 ARIN 156.228.6.0/24-24 AFRINIC 2026-01-27 AS201926 185.59.120.0/22-32 RIPENCC 2026-01-27 AS201944 2a14:67c3:361::/48-48 RIPENCC 2026-01-27 AS201950 2a06:de04:40::/44-48 RIPENCC 2a0e:97c0:aa0::/44-48 RIPENCC 2026-01-26 AS202147 185.229.216.0/22-22 RIPENCC 2a14:7581:ff0::/48-48 RIPENCC 2026-01-26 Perhaps this is then a conversation for a different medium and not the DB WG list? Antonis > On 29 Jan 2026, at 11:01, Antonis Chariton via db-wg <[email protected]> wrote: > > Thank you both for that link! I dug up a bit more into the case here. Here > are my findings: > > At the time of the 3rd (current) assignment, the AS was a member of 17 > AS-SETs in the RIPE database: > > 4x are from DE-CIX (so probably automated since the AS is still in their IXF > and nothing can be done) > The rest are from 4 different maintainers. Did they all get an e-mail and > ignored it? (It’s likely) — I wasn’t aware of these e-mails you referred to > Peter. > > This AS also has 2 ROAs for two /22s of IPv4. Since ROAs are deleted when the > LIR account closes or when a transfer of the space happens, these are > probably left from another account. Currently this new assignment can hijack > IPv4 space with RPKI valid status, so perhaps we need to do more than just > e-mailing for that. We want to increase RPKI accuracy and not end up with > legacy / debt there, too. > > After running bgpq4 in debug mode, I found that NTT is using > "NTTCOM,INTERNAL,LACNIC,RADB,RIPE,RIPE-NONAUTH,ALTDB,BELL,LEVEL3,APNIC,JPIRR,ARIN,BBOI,TC,AFRINIC,IDNIC,RPKI,REGISTROBR,CANARIE > C” so perhaps the filters are emitted from the pseudo-DB “RPKI”. > > It looks like RIPE can mainly influence the ROAs, ensure ASPAs are also > deleted as part of this process, and then perhaps be a bit more aggressive in > the IRR DB regarding leftovers. Changing people’s objects authoritatively is > a bit much, but perhaps more nagging is the answer? > > As an upstream of this network, when I added this AS in my automation, I was > asked to allow two IPv4 prefixes that the “customer” never notified me about > nor recognized, and then I had to manually hardcode blocklists for these > because they were advertised by someone else. In turn, my upstream and its > upstream also had questions, and were not so inclined to manually override > automation and maintain blocklists as it would eventually get out of sync. > > Is this a problem others see in their filtering, too? Do you blindly trust > AS-SETs if the ASNs in them are known, or do you have additional checks? > Perhaps RIPE here could run these additional checks operators do for the > benefit of routing security. > > Finally, I also checked the last 20 or so AS assignments manually from > https://social.bgp.tools/@new_ripe_asns . Most of them are still in plenty of > seemingly unrelated AS-SETs (oh well, known issue), and for a lot of them > bgpq4 generates a larger than announced prefix list. monocle also found some > ROAs for a few others as well. > > My goal here is not to complain, I’m just wondering if we can improve this > process and help the staff be more thorough in their quarantine. > > Antonis > >> On 29 Jan 2026, at 10:25, Peter Hessler <[email protected]> wrote: >> >> Hi Antonis, >> >> (speaking as a member of the WG, not Co-Chair) >> >> Yes, I think it would be appropriate for the NCC to delete those objects >> from the RIPE database when they are returned to the NCC. >> >> As Radu points out, this should be hapening already but it's possible >> that the objects don't match their search criteria. As a transit >> operator, at work we get emails from RIPE when our AS-SET refers to ASNs >> that have been returned. >> >> Much of this is described at, >> https://www.ripe.net/manage-ips-and-asns/resource-management/quarantine-for-returned-internet-number-resources/ >> so I'm a little surprised this is happening. >> >> Best Regards, >> Peter Hessler >> >> >> On 2026 Jan 28 (Wed) at 21:26:11 +0200 (+0200), Antonis Chariton via db-wg >> wrote: >> :Hello DB WG, >> : >> :As RIPE has been handing out new ASNs from previous allocations that have >> been returned for several months now, I wanted to ask if there’s any plan to >> clean up an entry somehow before reassigning the AS. >> : >> :With the current system you can request an AS, get it, and then have ROAs >> (ASPAs too?) / route{6,} / as-set objects, etc. from the previous one or >> more owners. >> : >> :I recently got an AS with valid ROAs and route objects for some IPv4 still >> pointed its way from a couple of operators ago (according to the bgp.tools >> history). >> : >> :For bonus points, it’s also included in a DE-CIX IXF feed and shows up as >> connected there :) >> : >> :Does it make sense to clean up objects or notify entities including an AS >> upon its return back to the available pool? Since you can’t really know who >> will get it and when, it’s unlikely you really mean to authorize >> announcements with a ROA, or IRR routes. It also probably doesn’t make any >> logical sense to include it in an as-set. >> : >> :I stumbled upon this when I tried generating filters with bgpq* and it >> added a few unknown /22s without me recognizing them. Pim here (in Cc) also >> had the same question :) >> : >> :Thanks, >> :Antonis >> >> -- >> I found out why my car was humming. It had forgotten the words. >> ----- >> To unsubscribe from this mailing list or change your subscription options, >> please visit: https://mailman.ripe.net/mailman3/lists/db-wg.ripe.net/ >> As we have migrated to Mailman 3, you will need to create an account with >> the email matching your subscription before you can change your settings. >> More details at: https://www.ripe.net/membership/mail/mailman-3-migration/ > > ----- > To unsubscribe from this mailing list or change your subscription options, > please visit: https://mailman.ripe.net/mailman3/lists/db-wg.ripe.net/ > As we have migrated to Mailman 3, you will need to create an account with the > email matching your subscription before you can change your settings. > More details at: https://www.ripe.net/membership/mail/mailman-3-migration/ ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/db-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
