I see another potential issue here. You mention that the ASN is already
on its third assignment. I am unsure of the actual timeframe for the ASN
you are referring to, but If these reassignments occurred within a
relatively short period, it is possible that the ASN was not actually
necessary, which could point to an issue with the touchy subject of
*assignment criteria* (AP-WG business).
By "short timeframe" I mean something like:
(~1 year of use + 6-month quarantine) +
(~1 year of use + 6-month quarantine second assignment) +
the current third assignment.
Such a high churn rate increases the workload for the NCC when it comes
to cleaning up resources.
Cleaning up ROAs is not something the NCC can do directly for other TALs
or delegated CAs, and is mostly the responsibility/risk of the resource
holder. However, I think this would be an easy addition to the existing
procedure of asking nicely the AS-SET owners to remove stale data.
Chasing various IXPs to clean up their IXF is a somewhat different matter.
Radu
On 1/29/2026 11:01 AM, Antonis Chariton via db-wg 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/
