ASPA AS0 Records for unallocated ASNs
Hi WG, 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. Is there a similar policy or process that ensures RIPE will create ASPA AS0 records for ASNs not currently allocated (again, to ensure they aren't used)? If I look at an example ASN allocated to RIPE by IANA, but not currently allocated by RIPE to any LIR (AS219350), there is no ASPA AS0 record for this ASN. If no such policy or process exists, what is the correct path to establish such a policy/process? 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>
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
Great - thanks Nick, I'll have read! 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>
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 james,
Is there a similar policy or process that ensures RIPE will create ASPA AS0 records for ASNs not currently allocated (again, to ensure they aren't used)?
what is the threat model? randy
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>
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
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>
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
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
On 27 Jul 2026, at 20:31, Dale W. Carder <dwcarder@es.net> wrote:
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
TLDR: 212032 is reserved but in BGP... And for fun, I converted assigned + unallocated, ipv4+ipv6+asn into a stayrtr cache, aka normally what one would feed as the output of rpki-client thus the rpki-client.json that at the moment here weighs in at 102050028 bytes. unallocated.json weighs in at about 10% of that 10517645. Though likely running Job's aggregate6 tool over that would make it a lot and then really a lot smaller as there are a lot of IPv6 prefixes there. The long list of unallocated IPv6 prefixes do not help either. I stuff that into a separate stayrtr instance and then load it into separate tables. Same trick as I do for Spamhaus DROP list: https://massars.net/design/#spamhaus (and as noted, this keeps generated lists separate from config that lives in git, and avoids reloading bird as RTR refresh are automatically done) In this case ipv4/ipv6 prefixes get ASN=0 + prefix + maxlength=32 or 128 An ASN entry gets ASN=0 PFX=192.0.2.0/24 + max=24. Thus I test (roa_check) each ASN in the BGP path against the unalloc4 with prefix 192.0.2.0/24 + ASN in the path. And guess what there is indeed one item that can be found with that: 2401:f6a0:2000::/36 is announced by 212032 grep 212032 delegated-ripencc-extended-latest.txt ripencc||asn|212032|1||reserved https://bgp.tools/as/212032 also has ERR_AS_NAME_NOT_FOUND + ACTIVE + BOGON_ASN and https://bgp.tools/super-lg confirms, lots of folks have it in their tables..... So, that does catch 1 item.... no prefixes that I could see, but I did not retrigger a lookup for all of them. Thus is it worthy..... yeah, as a monitoring tool check, but for letting RIPE NCC do all the work, maybe not so much. Regards, Jeroen -- Sample parts from unalloc.txt: { "asn": 0, "prefix": "5.134.16.0/21", "maxLength": 32, "ta": "delegated_ripencc", "expires": 1786398975 }, { "asn": 0, "prefix": "5.181.140.0/22", "maxLength": 32, "ta": "delegated_ripencc", "expires": 1786398975 }, { "asn": 0, "prefix": "5.249.168.0/21", "maxLength": 32, "ta": "delegated_ripencc", "expires": 1786398975 }, { "asn": 0, "prefix": "31.25.60.0/22", "maxLength": 32, "ta": "delegated_ripencc", "expires": 1786398975 }, ... { "asn": 1901, "prefix": "192.0.2.0/24", "maxLength": 24, "ta": "delegated_ripencc", "expires": 1786398975 }, { "asn": 5575, "prefix": "192.0.2.0/24", "maxLength": 24, "ta": "delegated_ripencc", "expires": 1786398975 }, { "asn": 6691, "prefix": "192.0.2.0/24", "maxLength": 24, "ta": "delegated_ripencc", "expires": 1786398975 }, { "asn": 6781, "prefix": "192.0.2.0/24", "maxLength": 24, "ta": "delegated_ripencc", "expires": 1786398975 }, ... { "asn": 0, "prefix": "2a10:3708::/29", "maxLength": 128, "ta": "delegated_ripencc", "expires": 1786398975 }, { "asn": 0, "prefix": "2a10:3710::/28", "maxLength": 128, "ta": "delegated_ripencc", "expires": 1786398975 }, { "asn": 0, "prefix": "2a10:3720::/27", "maxLength": 128, "ta": "delegated_ripencc", "expires": 1786398975 }, { "asn": 0, "prefix": "2a10:3748::/29", "maxLength": 128, "ta": "delegated_ripencc", "expires": 1786398975 }, { "asn": 0, "prefix": "2a10:3750::/28", "maxLength": 128, "ta": "delegated_ripencc", "expires": 1786398975 }, .... $ whois AS212032 % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See https://docs.db.ripe.net/terms-conditions.html % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to 'AS208885 - AS214345' as-block: AS208885 - AS214345 descr: RIPE NCC ASN block remarks: These AS Numbers are assigned to network operators in the RIPE NCC service region. mnt-by: RIPE-NCC-HM-MNT created: 2026-07-13T14:17:33Z last-modified: 2026-07-13T14:17:33Z source: RIPE % This query was served by the RIPE Database Query Service version 1.123 (BUSA)
On 28 Jul 2026, at 01:16, Jeroen Massar <jeroen@massar.ch> wrote:
On 27 Jul 2026, at 20:31, Dale W. Carder <dwcarder@es.net> wrote:
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
TLDR: 212032 is reserved but in BGP...
More reserved/unallocated ASNs currently announcing things: Seems AS214026 is a quite common occurrence, but I understand it was recently revoke or something like that. Would be good for transits to be informed of that at least... 23.129.68.0/24 AS214026 23.26.139.0/24 AS214026 141.11.150.0/23 AS214026 141.11.150.0/24 AS214026 141.11.234.0/23 AS214026 141.11.234.0/24 AS214026 84.54.0.0/23 AS214026 84.54.0.0/24 AS214026 84.54.1.0/24 AS214026 2602:faa8:260::/44 AS214026 2602:faa8:601::/48 AS214026 216.23.108.0/23 AS214026 185.250.112.0/24 AS210182 185.250.113.0/24 AS210182 185.250.114.0/24 AS210182 185.250.115.0/24 AS210182 185.177.176.0/24 AS206741 185.177.179.0/24 AS206741 45.88.203.0/24 AS42651 104.234.16.0/24 AS47813 109.175.133.0/24 AS208279 117.121.245.0/24 AS49901 149.18.96.0/24 AS200113 188.72.100.0/24 AS208295 188.72.99.0/24 AS208295 2401:f6a0:2000::/36 AS212032 2a0f:7803:fae0::/48 AS215269 2a12:bec4:1444::/48 AS215269 2a13:2380:11::/48 AS213205 2a13:2380:359::/48 AS213205 2a13:2380::/29 AS213205
Hi Jeroen, For me it is not very surprising that *recently* deregistered ASNs still appear in places. Some work in progress, sorry for the not-so-usable stuff, this is a quick lookup for RIPE NCC reserved ASNs that are visible in the GRT. There are more interesting searchable things there for the curious ;) https://bgpthingy.xindi.eu/search?q=tags%3A+ripencc%2C+rir_status_reserved%2... However, this looks a bit out of scope for the thread and maybe could be moved to a separate one, please see my reply inline below. Also, among these are some good examples of short lived assignments that were perhaps, to say it mildly, not needed. Those just add on the Registration Services workload both for registering and deregistering them with all the bureaucratic steps. On 28/07/2026 02:59, Jeroen Massar via routing-wg wrote:
TLDR: 212032 is reserved but in BGP...
was deregistered on 2026-06-29
More reserved/unallocated ASNs currently announcing things:
Seems AS214026 is a quite common occurrence, but I understand it was recently revoke or something like that. Would be good for transits to be informed of that at least...
was also deregistered on 2026-06-29, registered on 2025-10-13, fun fact it had a proton.me email as contact.
185.250.112.0/24 AS210182 185.250.113.0/24 AS210182 185.250.114.0/24 AS210182 185.250.115.0/24 AS210182
deregistered on 2026-06-24 (looks like LIR closure)
185.177.176.0/24 AS206741 185.177.179.0/24 AS206741
also deregistered on 2026-06-24, likely LIR closure
45.88.203.0/24 AS42651
deregistered on 2026-06-16, out of region
104.234.16.0/24 AS47813
another one deregistered on 2026-06-29, out of region
109.175.133.0/24 AS208279
another one from 2026-06-24 (LIR closure day apparently), was registered on 2025-05-16
117.121.245.0/24 AS49901
this one was deregistered on 2025-03-04, interesting
149.18.96.0/24 AS200113
deregistered on 2026-05-04 (registered on 2023-01-27)
188.72.100.0/24 AS208295 188.72.99.0/24 AS208295
deregistered on 2026-06-25 (likely LIR closure)
2401:f6a0:2000::/36 AS212032
see above, the first one. 2026-06-29
2a0f:7803:fae0::/48 AS215269 2a12:bec4:1444::/48 AS215269
mistery on this, I am too lazy to look it up
2a13:2380:11::/48 AS213205 2a13:2380:359::/48 AS213205 2a13:2380::/29 AS213205
deregistered on 2026-05-12 (likely LIR closure), out of region, registered on 2022-08-17
Hi Jeroen, Nice work! Thanks for doing this and sharing your findings. From looking through the list archives, I feel like the last time around in 2021 this kind of homework wasn't done and this really makes it clear why this approach doesn't work with empirical data. Thank you. With kind regards, James Bensley (he/him) ________________________________ From: Jeroen Massar via routing-wg <routing-wg@ripe.net> Sent: 28 July 2026 01:16 To: Routing WG <routing-wg@ripe.net> Cc: Job Snijders <job@bsd.nl> Subject: [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.
On 27 Jul 2026, at 20:31, Dale W. Carder <dwcarder@es.net> wrote:
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
TLDR: 212032 is reserved but in BGP... And for fun, I converted assigned + unallocated, ipv4+ipv6+asn into a stayrtr cache, aka normally what one would feed as the output of rpki-client thus the rpki-client.json that at the moment here weighs in at 102050028 bytes. unallocated.json weighs in at about 10% of that 10517645. Though likely running Job's aggregate6 tool over that would make it a lot and then really a lot smaller as there are a lot of IPv6 prefixes there. The long list of unallocated IPv6 prefixes do not help either. I stuff that into a separate stayrtr instance and then load it into separate tables. Same trick as I do for Spamhaus DROP list: https://massars.net/design/#spamhaus (and as noted, this keeps generated lists separate from config that lives in git, and avoids reloading bird as RTR refresh are automatically done) In this case ipv4/ipv6 prefixes get ASN=0 + prefix + maxlength=32 or 128 An ASN entry gets ASN=0 PFX=192.0.2.0/24 + max=24. Thus I test (roa_check) each ASN in the BGP path against the unalloc4 with prefix 192.0.2.0/24 + ASN in the path. And guess what there is indeed one item that can be found with that: 2401:f6a0:2000::/36 is announced by 212032 grep 212032 delegated-ripencc-extended-latest.txt ripencc||asn|212032|1||reserved https://bgp.tools/as/212032 also has ERR_AS_NAME_NOT_FOUND + ACTIVE + BOGON_ASN and https://bgp.tools/super-lg confirms, lots of folks have it in their tables..... So, that does catch 1 item.... no prefixes that I could see, but I did not retrigger a lookup for all of them. Thus is it worthy..... yeah, as a monitoring tool check, but for letting RIPE NCC do all the work, maybe not so much. Regards, Jeroen -- Sample parts from unalloc.txt: { "asn": 0, "prefix": "5.134.16.0/21", "maxLength": 32, "ta": "delegated_ripencc", "expires": 1786398975 }, { "asn": 0, "prefix": "5.181.140.0/22", "maxLength": 32, "ta": "delegated_ripencc", "expires": 1786398975 }, { "asn": 0, "prefix": "5.249.168.0/21", "maxLength": 32, "ta": "delegated_ripencc", "expires": 1786398975 }, { "asn": 0, "prefix": "31.25.60.0/22", "maxLength": 32, "ta": "delegated_ripencc", "expires": 1786398975 }, ... { "asn": 1901, "prefix": "192.0.2.0/24", "maxLength": 24, "ta": "delegated_ripencc", "expires": 1786398975 }, { "asn": 5575, "prefix": "192.0.2.0/24", "maxLength": 24, "ta": "delegated_ripencc", "expires": 1786398975 }, { "asn": 6691, "prefix": "192.0.2.0/24", "maxLength": 24, "ta": "delegated_ripencc", "expires": 1786398975 }, { "asn": 6781, "prefix": "192.0.2.0/24", "maxLength": 24, "ta": "delegated_ripencc", "expires": 1786398975 }, ... { "asn": 0, "prefix": "2a10:3708::/29", "maxLength": 128, "ta": "delegated_ripencc", "expires": 1786398975 }, { "asn": 0, "prefix": "2a10:3710::/28", "maxLength": 128, "ta": "delegated_ripencc", "expires": 1786398975 }, { "asn": 0, "prefix": "2a10:3720::/27", "maxLength": 128, "ta": "delegated_ripencc", "expires": 1786398975 }, { "asn": 0, "prefix": "2a10:3748::/29", "maxLength": 128, "ta": "delegated_ripencc", "expires": 1786398975 }, { "asn": 0, "prefix": "2a10:3750::/28", "maxLength": 128, "ta": "delegated_ripencc", "expires": 1786398975 }, .... $ whois AS212032 % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See https://docs.db.ripe.net/terms-conditions.html % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to 'AS208885 - AS214345' as-block: AS208885 - AS214345 descr: RIPE NCC ASN block remarks: These AS Numbers are assigned to network operators in the RIPE NCC service region. mnt-by: RIPE-NCC-HM-MNT created: 2026-07-13T14:17:33Z last-modified: 2026-07-13T14:17:33Z source: RIPE % This query was served by the RIPE Database Query Service version 1.123 (BUSA) ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/routing-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/ [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>
On 28 Jul 2026, at 08:54, James Bensley <james@inter.link> wrote:
Hi Jeroen,
Nice work! Thanks for doing this and sharing your findings. From looking through the list archives, I feel like the last time around in 2021 this kind of homework wasn't done and this really makes it clear why this approach doesn't work with empirical data. Thank you.
The above is just the RIPE data, adding APNIC/ARIN/AFNIC/ etc would likely explode the data even more and find more prefixes. Do remember that for forever has existed: https://www.cidr-report.org/#Bogons Which is mailed every month or so to the various NOG lists. The problem here is transits who are not verifying the prefixes coming from their 'customers'. And as the time shows, nobody ever bothered to filter those out, bits is bits when you forward them and get paid for them, be that good or bad data.... Thus knowing what is bad is known, cleaning that up.... at least with converting the data one could stop it at your network edge, but the bits might still come to you. Regards, Jeroen
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
Thanks Ben and Dale for your input. I've just looked at reserved prefixes only: $ ./ripe_prefixes.sh delegated-ripencc-extended-latest.txt v4 prefix count: 333 v6 prefix count: 83355 I feel much better about putting this idea to bed now that we have some data in the list archives (also from Jeroen's emails) showing this is a bad idea, rather than people screaming "I don't like it!". Thank you both! 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>
Hi James, Perhaps your LLM went a bit over board on this one, "emotionally" speaking. Personally I'd like to think the RIPE mailing lists are still human-ish interaction. Job made some very good points your LLM wall of text missed. Sorry but I am not going to expand on this, but maybe human reading his message would help. Radu On 27/07/2026 20:32, James Bensley wrote:
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/ <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/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/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/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/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 <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 <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>
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/routing-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/
Hi Radu, It was all hand written. I think your LLM radar is broken. With kind regards, James Bensley (he/him) ________________________________ From: Radu Anghel via routing-wg <routing-wg@ripe.net> Sent: 28 July 2026 10:09 To: routing-wg@ripe.net <routing-wg@ripe.net> Subject: [routing-wg] Re: ASPA AS0 Records for unallocated ASNs Hi James, Perhaps your LLM went a bit over board on this one, "emotionally" speaking. Personally I'd like to think the RIPE mailing lists are still human-ish interaction. Job made some very good points your LLM wall of text missed. Sorry but I am not going to expand on this, but maybe human reading his message would help. Radu On 27/07/2026 20:32, James Bensley wrote:
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/ <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/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/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/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/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 <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 <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>
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/routing-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/routing-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/
Dear all, The below is intended as a detailed write-up for future reference and not directed at anyone specific. I share this because the topic of "why not have the RIRs also use the RPKI for negative attestations" continues to come up from time to time. On Mon, Jul 27, 2026 at 05:32:38PM +0000, James Bensley wrote:
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:
I'm really just trying to help! :-)
* "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.
I wonder what one would base the "this feature shouldn't take more than a week" assertion on? In my mind such an assertion raises questions about the method of estimating development effort rather than anything about the RIPE NCC. :-) FWIW, I think the brunt of the work is NOT in simply encoding a list of prefixes into ASN.1 BIT STRING conforming to the ROA profile (encoding transformations obviously are the simple part). I think some of the substantial cost is in both cross-departmental and non-technical work, e.g, alignment with CA audit procedures, alignment with registration services, revising certification practise statements, updating of educational materials, QA and scale testing, legal impact analysis, insurance & liability assessment, impact on regulatory compliance posture, impact on sanctions compliance posture, preparations for obtaining executive board approval, etcetera. You don't need to take my word for it, but for the sake of this discussion I'd recommend to assume a budget of 2 FTE for a period of 12 to 18 months to get to a production-grade AS0 implementation and then 0.5 FTE going forward to maintain the result. Perhaps needless to say, but overspending as a result from underbudgeting is a common failure in organisations and in this context the membership would foot the bill. I base these estimates on my own experience managing multi-year/multi-FTE RPKI projects in hopes of helping clarify where I'm coming from.
* "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.
I disagree with this narrow reading. RFC 6811 outlines a validation process that has as outcome a trinary state: "valid", "invalid", and "not-found". The latter state is is the 'fail open' that facilitates incremental deployment, but also is where resources end up for which there is a contractual lapse or some temporary administrative issue. Deregistrations and disputes do happen from time to time, as do software defects (I'll expand on both). In a world where all unassigned/unallocated/reclaimed space is covered by AS0 RPKI ROAs, for BGP announcements related to those type of space the third state ('not-found') is fully subsumed into the 'invalid' state. This is what I mean with 'fail closed': many kinds of process failures can result in AS0 listing, with the end result likely being reachability issues. ... which brings me to an seemingly underappreciated topic: RISK. In reasoning about the construction of new common infrastructure we shouldn't merely look at "what does it cost to build this?" (~ 2 FTE), and "once it is build, what will it gain us?" (detection of few tens of discrepant prefixes), but also important - "what is the risk of this thing even existing? What new risks come into existence?". Risk management is a complicated topic because we know risk is real but often risk is hard to qualify or quantify. There may even be unforeseen risks! One might retort "Job, but fear is the mindkiller!", however such a platitude wouldn't mitigate the real risks. (I'm not trying to put words in anyone's mouth but to get ahead of blanket dismissal of risk as a tangible factor to account for.) I see a few risks: * Administrative process failure -- In the current model, a payment dispute (just an example of a problem of an adminitrative nature) lands things in the 'not-found' bucket, while the creation of a new CA issuing AS0 objects causes more severe impact. This could lead to an increase in claimed damnages in court cases. This example of a risk is not theoretical: I know of real world examples in other regions of the world where a prefix accidentally ended up on an AS0 and this caused material damage to all involved. * Software defects -- While it is formally specified that software defects MUST NOT exist (RFC9225), research across a multitude of codebases suggests that bugs are introduced at a rate of roughly one bug per 1000 CLOC. Mitigations include separation of privileges (isolation), reduction of privileges when executing, embracing safe coding practises, but also a much less obvious one: avoidance creation of certain software to begin with. This may sound like a nihilist argument, but my point is that we just need to be _very_ careful materializing everything we wish for. Some lived experience: in the 2019/2020 era with the global deployment of RPKI-ROV an incredible number of software defects was uncovered in BGP router implementations, RPKI validators, and RPKI signer/publication software. It was painful. Bug hunting was like shooting fish in a barrel. We almost didn't make it. However in my mind the juice was worth the squeeze because the then ongoing avalanche of BGP routing incidents (related to allocated resources) also carried a tremendous collective cost. With the advent of ASPA we are about to start the cycle anew: while I know that many lessons have already been taken to heart (e.g., one outcome is that ASPA will not suffer from some classes of race conditions that were disovered in 2019/2020). However, there is a strong probability that initial ASPA implementations will contain severe bugs. Time will tell whether the market ends up embracing ASPA or disabling it wholesale. Additionally, there already is a documented case where a software bug related to in contractual status in a database system bled through into the existence / disappearance of RPKI ROAs. (Note: this is different from an administrative process failure.) From what I heard it took the RIR a fair a bit of effort to audit and strengthen their systems by adding controls and improve workflows to prevent reoccurance. The bug surface is real and from my perspective the practise of negative attestation would certainly increase the bug surface. * Administrative failures & software bugs can erode community trust -- While there is _some_ room to absorb fallout from problems (nothing is perfect), how many outages / problems is 'one too many'? We all know the infamous mantra "if you have network problems just disable IPv6!". It takes more energy to establish credibility of an infrastructure than to lose it. The current state of RPKI infrastructure & deployment is the fruit of years of hard work and investment. We all paid for it. I consider expansion of the certification scope towards (purportedly!) unallocated/unassigned/reclaimed resources to carry a substantial risk of devaluing the existing investment. We'd be in a fine pickle if people wholesale stop using RPKI due to fallout from incidents related to negative attestation. * Risks of fallout related to sanctions -- Developments in recent years certainly posed challenges for our collective ability to operate in compliance with newly imposed sanctions. I believe the concept of negative attestation may be somewhat like Chekhov's gun. This might be a good read: https://www.techpolicy.press/towards-the-multistakeholder-imposition-of-inte... The section titled "Manipulation of routing security attestations" ties into the aforementioned risk of community distrust. * Technical scaling issues -- Already today, "staying ahead of the demand curve" is a challenge in the RPKI ecosystem. It might not be apparent to outsiders (i.e., to people who do not develop RPKI protocols and software as part of their daily work), but a lot of time and effort is spend on optimising the efficiency of RPKI (e.g., in the RPKI encoding and transport layers, understanding publication best practises, but also BGP RIB lookup optimisations in routers). Expanding the certification scope to additionally cover the *complement* of allocated resources is no small matter! In systems design, it seems there may be general principle that it is more economical/reliable/efficient to compose sets of instructions describing what you DO want to happen - rather than disseminating the inverse possibility space. Constructing and distributing both at the same time obviously is a substantial increase in burden. I suspect there is something architecturally unsound with the concept of negative attestations in context of the global routing system. An analogy (undoubtly severely flawed): nation states usually do not proactively jam unlicensed/unallocated radio spectrum. As a strategy it is just easier to passively measure and apply tactical intervention rather than to try and make the radio spectrum as a whole unusable for those without license. One might say "but negative attestation ROAs and regular ROAs are intended to be ships in the night!", but there _is_ some fate-sharing, at the very least the information streams will coalesce in BGP routers. To put this in numbers: looking at today's APNIC & LACNIC data for their AS0 certification, a validator's output results a 40% increase (!) in number of payloads compared to the 'regular' certification trees. I suspect that this number differs from Jeroen's estimate (which was RIPENCC-centric) because the opportunity to efficiently aggregate may be different from region to region due to (historic) assignment strategies. And, knowing that RIR assignment policies and allocation strategies do change over time, there might be profoundly ill scaling effects down the road resulting from that. Opportunity to aggregate data is not a given. In other words - I'd much rather retain this fictious "40% budget increase" as breathing room to accommodate growth of the existing regular certification trees for allocated resources or spend such "headroom" towards novel 'high yield' features (e.g., ASPA).
* "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).
I wholeheartedly agree with all of the above, but I fail to reconcile the above with what I wrote. :-)
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).
All very good points, and you make an excellent case for strigent reliable fast-paced monitoring of the world's RPKI data. Improving propagation speed of RPKI ROAs is very high on my list of things! :) Kind regards, Job
participants (10)
-
Ben Cartwright-Cox -
Dale W. Carder -
James Bensley -
Jeroen Massar -
Job Snijders -
Job Snijders -
lists＠at.encryp.ch -
Nick Hilliard -
Radu Anghel -
Randy Bush