Hey Job,

Thanks for providing more info that was helpful.

I don’t agree with quite a lot of what has been written (simply because there seems to be more emotional that strong/clear logical reasoning), summarising some of the points across the archives:

*  "It’s a lot of effort" → maybe it was in 2021, to put together a pipeline today that generates an AS0 ROA when a prefix changes state of unallocated, and removing it when it loses that state, should take a couple of days to churn out in today, maximum 1 week. So I don’t buy the effort argument at all. If it really is a serious amount of work, that just raises more question about the RIPE NCC.

* "We’re failing closed" → this is a logical fallacy. The general approach with RPKI based validation is “if there is a signal to reject, then reject, otherwise accept”, this is fail open logic. That logic is not being changed. What is being changed is that there are no signals for these resources we’re discussing, so for those resources specifically we hit the default accept clause in our routing policies. We’re taking about adding in signals for those resources so that we hit the “there is a signal to reject” clause in the if statement. The suggestion that the logic would be changed to fail closed is simply not correct.

* "It’s a slippery slope" → this is another logical fallacy. If we decide to do something because it's easy ($old_thing we did in the past makes $new_thing easier to achieve than it would have been, had we not done $old_this already), rather than deciding to do something because it's the right thing to do; then the problem is that we are doing something which isn’t the right thing to be doing, we doing something which is easy. We can decide to do many things because they are easy, they could be easy without any past work laying a foundation, that still doesn’t me we should do those things. We should always do things because we decided they are the right thing to do. If we are evaluating things properly, the easiness to achieve the goal has no bearing (only in extreme scenarios where $effort >= some absurd value).

Having thought about this, I think a more water tight argument I can get behind is specifically the risk that comes from the extremely low propagation times for the RPKI; Even though I hate prefix lists, one of the few benefits is that there is a 24 hour window (the industry standard interval IMO) afforded to operators between making a mistake in your IRR data, and getting it fixed before the poop decorates the walls. And it’s a risk I have been musing on recently regarding the RPKI and what to do about it. I would guess that a new ROA is in the control plane of the major of routers in the global DFZ within about 30 minutes. So I think a serious risk is; if something goes wrong with RIPE’s automated process, *there is no time buffer to correct anything* (on it’s own, some sort of bug or mistake is not enough of a reason for me, we’re not talking about launching a rocket to mars, but it’s specifically the combination of a bug /mistake + near real time propagation).

For background/context:

I was musing recently on auto generating SLURM files internally, as you mentioned, to get rid of our static filters for all the IANA special allocations. And then I thought, I could include all the RIR unallocated stuff too. And then I thought; why are 90k networks each creating their own BOGON filter lists today, even though we all want the same stuff filtered, and as a result of so many networks having to repeat the same task, what a shocker, many get it wrong or just don’t do it, and even those that do it, do it differently. It’s a mess. Why don’t we just centralise this, do it once, do it right, and everyone benefits? That was the brain fart that let to my original mailing list post.

Now what about this as a follow-up brain fart; why doesn’t the RIPE NCC just announce their unallocated space? No adding or removing of ROAs, just announce it without a ROA? It will become ROA “unknown” so it will be accepted, and that will disincentivise the squatters from using the space because it’s no longer effective. If someone buys this space from RIPE, RIPE stop announcing it and the new owner can announce it and create a ROA and go on with their day.

With kind regards,
James Bensley (he/him)
From: Job Snijders <job@bsd.nl>
Sent: 27 July 2026 14:55
To: James Bensley <james@inter.link>
Cc: Routing WG <routing-wg@ripe.net>
Subject: Re: [routing-wg] Re: ASPA AS0 Records for unallocated ASNs
 
⚠️ Caution: This email originated from outside of your organization. Do not click on links or open attachments unless you recognize the sender and know the content is safe.

Hello James, others

Thanks for asking, I'll attempt to summarize the last few years --

And what happens if RIPE NCC issues a so-called 'AS0' in error?
Lawsuits? Probably! Luckily, at present this is (nearly) impossible
because RIPE NCC has implemented many controls to mitigate exactly that.
Only the resource holder can create RPKI objects. However, proposals
like these create additional, automated, pathways towards yeeting
resources off the Internet. Proposals like these _increase_ the surface
for bugs. I think you may be underestimating the burden of properly
running a RPKI Trust Anchor!

In the past there already have been incidents where an (accidental!)
change in contract status resulted in automated removal of ROAs. This
type of administrative error can happen, but a world with AS0 TALs
instead of going from "valid -> notfound" things go "valid -> invalid".
This is highly problematic. Why make the error path more severe?
Proposals like these change the dynamic from "FAIL OPEN" to "FAIL CLOSED"!

Which brings me to the obvious counter-question: why are you not doing
this yourself with the existing information? Surely you can easily
generate a SLURM file based on https://ftp.ripe.net/pub/stats/ripencc/,
right? If this type of blocklisting was so valuable, surely everyone
would already today be converting delegated-stats into SLURMs and using
that in production environments, right?

Putting risk aside - the implementation of separate AS0 TALs also turns
out to be a very costly and a very time consuming activity for RIR staff
(this is the lived experience from some other RIRs). These resources
would be much better spend on actually improving the RPKI feature set
itself (rather than implementing gazillion extra controls to wrap around
something dangerous). AS0 TALs are an expensive feature that doesn't
accomplish much in the happy path and destroys confidence in the RPKI in
the failure path. Tall order if you ask me.

> So this wouldn't be given the RIPE NCC any technical capabilities they
> don't already have.

At present the 0.0.0.0/0, ::/0, AS 0 -- 4294967295 root certificate is
unavoidable due to operational reasons. A side-effect is that quite some
time and effort is being spend to REDUCE privileges to avoid accidental
mishap resulting from the unavoidable absolute authority. Consider this
analogy: you install an operating system and gain root privileges, you
then work to set things up so that you do not do everything with your
root privileges. Just because you _could_ elevate to root privileges
doesn't mean you _should_.

> We're also only talking about them doing it for unallocated space,

Exactly... unallocated space is the least valuable space (it is not even
allocated yet). The space becomes valuable upon allocation, the receiver
of the space can choose to make RPKI objects (or not). The problem with
the proposals like these is that in order to protect the least valuable
resources all of a sudden the valuable resources end up being put at
risk.

> Please can someone spell it out for me what the reason(s) for not
> doing this is, which outweigh the reason(s) for doing it?

Please read:

https://web.archive.org/web/20260416125626/https://lists.afrinic.net/pipermail/rpd/2021/013314.html
https://web.archive.org/web/20260416124914/https://lists.afrinic.net/pipermail/rpd/2021/013308.html
https://web.archive.org/web/20201217144338/https://www.ripe.net/support/service-announcements/rpki-roas-deleted-for-some-legacy-resources
https://web.archive.org/web/20260416125539/https://lists.afrinic.net/pipermail/rpd/2021/013312.html
https://web.archive.org/web/20260416124817/https://lists.afrinic.net/pipermail/rpd/2021/013328.html

How many BGP announcements are there for unallocated RIPE space?
500? Less? Whatever it is, is that really worth spending hundreds of
thousands of euros on to increase our collective risk? I SAY BAD DEAL! :-)

Kind regards,

Job

ps. I consider AS0 TALs so risky that I added a protection mechanism
in the rpki-client validator which detects AS0 TALs and automatically
ignores them by default. In order to increase the barrier the operator
has to explicitly enable support for AS0 TALs: https://man.openbsd.org/rpki-client#0
[CompanySignature]
Inter..link GmbH | Boxhagener Straße 80, 10245 Berlin, Germany | Managing Directors: Marc Korthaus, Theo Voss | Commercial Register: Amtsgericht Charlottenburg, HRB 138876 | VAT ID: DE281288887 | Email: hello@inter.link | Web: inter.link