Re: Implementing Decentralized RPKI with Blockchain Technology

[Christopher Morrow <morrowc.lists () gmail com>]

On Wed, Nov 13, 2024 at 7:02 PM Matt Corallo <nanog () as397444 net> wrote:
> On 11/13/24 9:39 AM, Brandon Z. wrote:
> > Hi there,
> >
> > Currently, due to political factors, some countries are not particularly proactive in deploying
> > RPKI. Imagine if the RIR of a region were forced to revoke all IP resources of a particular country
> > from RPKI, effectively isolating that country from the global internet.
>
> Thanks for raising this topic. In all the rush to deploy RPKI I fear these issues are not talked
> about enough.

you missed ~8yrs  of hand wringing and such... so sad.

> > To address this, one approach is for autonomous networks within a region to establish two trusted
> > RPKI CA servers: one from the major RIRs and another locally managed. The locally managed CA would
> > take precedence, allowing autonomous networks to submit their IP resources to the RPKI server of
> > their peers (and potentially backed by a national mandate to trust this CA). This setup could
> > prevent a scenario where an entire country’s IP resources are revoked, leading to all IPs being
> > marked as invalid.
>
> A variant of this could make some sense, the issue is that it doesn't do you a whole lot of good to
> have a local RPKI anchor that you and your local community look to if the global internet community
> isn't looking at it - sure, your IPs are routable to a few of your friends, but they can't reach
> Google...oops.

this is slurm, actually... but sure.
There's even a federated version of slurm being discussed.
you might like that conversation over in sidrops () ietf org

> Another variant I've suggested before relies on timeouts for removal - for networks that have RPKI
> anchors deployed, if their RIR wants to remove their anchors the RIR must publish an intent to

'anchor' is not an RPKI word, maybe you mean something else, please
try a correct version of the word you mean?
(if you mean, effectively, ROA.. then basically all ROA have an
expiry..so yay we already have the thing you want?)
perhaps you actually mean the 'trust-anchor' - of which (today) there
are one per RIR?

> remove the anchor a week (or some other N) prior to the removal, with validators ignoring immediate
> removal. This takes the issue from "I woke up one morning and my IPs weren't routable" to "I spent a
> week arguing on *NOG and the internet community added a new temporary workaround to avoid my ISP
> losing all its resources due to a runaway RIR".

removal of a trust-anchor would have relatively high  impact on the
RPKi system and possibly the routing
system depending on what decisions were made in bgp policy. I think
over time we've tried to make the
whole of the system a bit more resilient, though... a missing
trust-anchor (or broken one) SHOULD just
end up with a bunch of 'not found' or  'unknown' routes... which
probably you aren't tossing in the bucket.
(because ~40% of the internet is still unsigned/unknown)