Re: Implementing Decentralized RPKI with Blockchain Technology

["Brandon Z." <Brandon () huize asia>]

I believe the simplest solution is to allow cross-regional issuance of
trust certificates between RIRs. This way, as long as at least one of the
ROA is marked as valid, even if one RIR sets a country's IPs as invalid due
to political reasons, other RIRs can still maintain their IPs are with
vaild ROA. Additionally, coordination among RIRs regarding IP address
reclamation can also be somewhat controlled.

Some argue that a country could enact legislation to block another
country's routing. However, since RPKI is global, if an RPKI remains valid,
the affected country could maintain internet connectivity through other
countries that do not enforce routing restrictions.


On 2024年11月29日周五 下午7:36 Job Snijders via NANOG <nanog () nanog org> wrote:

> On Mon, 18 Nov 2024 at 14:29, Matt Corallo <nanog () as397444 net> wrote:
>
> > On 11/18/24 5:11 AM, Niels Bakker wrote:
> > > * nanog () as397444 net (Matt Corallo) [Sun 17 Nov 2024, 20:44 CET]:
> > > > 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.
> > >
> > > Please take some time to read up on what countermeasures against RIRs
> > "AS0-routing as much IP space
> > > as they want" are being taken by developers of validators before
> > posting here again.
> >
> > Feel free to provide a link, the only constraining I'm aware of is what's
> > documented in
> > draft-snijders-constraining-rpki-trust-anchors, which does not, as far as
> > I understand, constrain AS 0 at all.
>
>
>
> It does though. The constraining-rpki-trust-anchors mechanism effectively
> prohibits RIRs from issuing ROAs (with any Origin AS, including AS 0), if
> the ROA at hand violates the locally configured constraints.
>
> The goal was to introduce a small policy language to mitigate some risk
> around one RIR issuing ROAs covering IP space managed by another RIR.
> Compartmentalise and isolate risks in the system.
>
> The example constraints in the draft are also the ones distributed with
> rpki-client, nowadays used by many ISPs.
>
>
> Given no one else in this thread has commented about any specific
> > constraints, it seems like a great chance to educate lots of people!
>
>
>
> This might interest you: detecting and rejecting AS0 TALs,
> https://marc.info/?l=openbsd-tech&m=173289357532392&w=2
>
> Regards,
>
> Job