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