That said, the reality today is that RPKI trust anchors are perfectly
capable of (through malice or cybersecurity incidents) AS0-routing as much IP space as they want,
taking entire swaths of the internet offline for a day or more at a time. So even if there was a ton
of hand-wringing about it prior to deployment, that didn't translate into any best practices which
actually reduce the trust the RPKI system has.

I mean, I'm still confused about what best practices people think should exist.

The entire point of RPKI is to validate the announcement instructions in the ROA were created by authorized assignee of the IP space. The authoritative party as to who the assignee of the IP space is is the RIR . This means the RIR is inherently the root of trust.

What proposals are out there that can perform the same function without that RIR being at the root of it?

On Sun, Nov 17, 2024 at 2:42 PM Matt Corallo <nanog@as397444.net> wrote:

On 11/14/24 2:29 PM, Tom Beecher wrote:
> In all the rush to deploy RPKI I fear these issues are not talked
> about enough.
>
>
> The first RPKI deployments started happening in the early 2010s, after many many years of being
> talked about.
>
> I'm sure you didn't mean it, but it's pretty insulting to the people who have spent countless hours
> working on these issues to say 'it wasn't talked about enough'.

Apologies if it came across as insulting, indeed I wasn't spending my time reading IETF mailing
lists in the early 2010s :). That said, the reality today is that RPKI trust anchors are perfectly
capable of (through malice or cybersecurity incidents) AS0-routing as much IP space as they want,
taking entire swaths of the internet offline for a day or more at a time. So even if there was a ton
of hand-wringing about it prior to deployment, that didn't translate into any best practices which
actually reduce the trust the RPKI system has.

Matt