James Bensley wrote on 23/07/2026 09:50:

Great - thanks Nick, I'll have read!

np, in particular can I suggest: https://www.ripe.net/community/policies/proposals/2019-08/2/#impact-analysis + also: https://mailman.ripe.net/archives/list/routing-wg@ripe.net/message/QG6YEQVIN... I.e. this is not a small undertaking. Nick

With kind regards, James Bensley (he/him) ------------------------------------------------------------------------ *From:* Nick Hilliard <nick@foobar.org> *Sent:* 23 July 2026 10:41 *To:* James Bensley <james@inter.link> *Cc:* Routing WG <routing-wg@ripe.net> *Subject:* Re: [routing-wg] 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.

Hi James,

James Bensley wrote on 23/07/2026 09:20:

...

AFAIK there is an existing policy/process that the RIPE NCC will create ROA AS0 records for prefixes not currently allocated to any LIR. This prevents unused IP space from being originated into the DFZ.

that was policy proposal 2019-08, which was withdrawn by the authors, i.e. never became RIPE policy.  There was lively discussion about this in 2019-2020.

If this was something you were interested in looking at, it would be worth looking back over the archives to understand the calculus involved, which from what I make of it, hasn't significantly changed.

Nick [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 <mailto:hello@inter.link> *|* Web: inter.link <https://inter.link>

I don't get the harmful part. Even further, I see AS0 upstream for unallocated ASN as a big security improvement preventing hijacks and bogons in DFZ.

Hi all, I tried to look through the list archives but the reason this was rejected last time was not clear to me. I think most people can easily guess an argument for doing this; we see people either squatting on unallocated IP/ASN space intentionally (spammers basically), or accidentally (I meant to prepend my AS, 555555 10 times but instead I just rewrote my origin to 10555555, and this "works" so it goes unnoticed and unfixed). Also AS0 ROAs are exactly for the purpose of signalling which IP space should not be announced, this is exactly that case with unallocated space. Similarly, AS0 ASPAs tell me I should be rejecting paths with AS0 in that my peer is sending me, again, this is exactly that case. I think the argument for not doing this (if I understood the list archives correctly, please correct me if I'm wrong!), is concern for overreach from the RIPE NCC? If that understanding is correct, I'm not seeing it and need someone to spell it out for me please. For example, I'm pretty confident the RIPE NCC could create an AS0 ROA or ASPA for an prefix/ASN allocated to them by IANA right now. It's technically not that difficult. They have the means to do it. It's just maybe a manual process right now. So this wouldn't be given the RIPE NCC any technical capabilities they don't already have. We're also only talking about them doing it for unallocated space, which I see RIPE NCC as having a responsibility for because that space is theirs until it's allocated to an LIR or taken back by IANA or transferred away. So not doing this for unallocated space is perhaps a little bit irresponsible of the RIPE NCC? (I'm not blaming the RIPE NCC because it was the membership that pushed back on this). 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? With kind regards, James Bensley (he/him) [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<mailto:hello@inter.link> | Web: inter.link<https://inter.link>

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/piperma... https://web.archive.org/web/20260416124914/https://lists.afrinic.net/piperma... https://web.archive.org/web/20201217144338/https://www.ripe.net/support/serv... https://web.archive.org/web/20260416125539/https://lists.afrinic.net/piperma... https://web.archive.org/web/20260416124817/https://lists.afrinic.net/piperma... 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<mailto:hello@inter.link> | Web: inter.link<https://inter.link>

Thus spake Ben Cartwright-Cox via routing-wg (routing-wg@ripe.net) on Mon, Jul 27, 2026 at 06:36:15PM +0100:

...

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.

(almost) Everyone's capacity for FIB entries is not unlimited, and unless you are suggesting RIPE de-aggregates to announcing every possible /24 of space (this would be somewhere between mildly and totally insane), a squatter can just announce a more specific to get around it

You would also have to take into account everything reserved as well.

curl https://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-extended-latest.txt | grep reserved | wc -l 84668

Dale