Implementing Decentralized RPKI with Blockchain Technology

Mailman List Mirror (Read Only)
1

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.

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.

Another concept is to use blockchain technology. While cryptocurrencies use computational power to verify ownership, BGP could use peer count. If an IP resource is marked as valid by a majority of high-influence networks (with many peers), it could be trusted by the entire internet.

Could this approach work? Perhaps there’s existing research on similar methods?

2

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.

Any of the RIRs being forced to revoke ROAs would be a pretty significant event. However your statement here is false.

Assuming all of those ROAs disappear or are force-expired, RPKI validation would return NotFound. Exactly the same as any announcement that never had a ROA to begin with. Nobody on the internet is dropping NotFound, and likely won’t in most of our lifetimes.

Another concept is to use blockchain technology.

  1. No
  2. See #1
3

Hi guys,

In technical terms, RIRs can indeed configure IPs to become RPKI invalid. However, my point is not to remove RPKI but to make it invalid.

This could happen; for example, RIPE was required to remove all IRRs related to Russia (I’m glad RIPE has not done this).

Everything that was blockchain last year is now AI.

Decentralization can address this issue; it’s not just a hype concept.

Best,

4

In such a scenario I’d argue for less automation to prevent such a rogue RIR from being able to cause such a disruption to the Internet.

To expand on what Tom mentioned, Networks are not yet rejecting announcements with a NotFound validation. Even if such an event did occur I’d be willing to bet most network operators are going to be leaning on their interpersonal connections rather than automation to reestablish peering with networks. The “proof” of showing they are still allowed to announce those resources will happen later. In a true disaster things are going to fall back to the least complex solution which is simply people talking to people.

5

Hi Brandon,

That's not how blockchain works. Validation is time-bound and
irrevocable. Only the current key-holder can transfer the validated
material to another entity. Effecting such transfers requires minimal
computation, on the order of a few HTTPS transfers.

Under block chain, an RIR would not be able to revoke number
resources, not even for non-payment or fraud. And if the keys
associated with an address block were lost or stolen, the address
block would effectively be lost with them. The whole point of the
block chain is that it is mathematically irrevocable. Period and full
stop.

Bear in mind that the five RIRs are self-organized. There's not a
whole lot to stop a sixth RIR from organizing if enough address
holders (and their money) get together and agree they want one. Which
would surely happen if a government attempted to cut off an entire
country from address registration.

Also, please don't cross-post discussions to two lists. It's against
the rules for NANOG and I presume it's against the rules for MANRS as
well.

Regards,
Bill Herrin

6

Hi William,

Under block chain, an RIR would not be able to revoke number
resources, not even for non-payment or fraud.

Okay, this would lead to a permanent loss of resources, whereas cryptocurrency does not have this issue.

Also, please don’t cross-post discussions to two lists. It’s against
the rules for NANOG and I presume it’s against the rules for MANRS as
well.

Noticed that; sorry for posting twice as well.

Best,

7

Under block chain, an RIR would not be able to revoke number> resources, not even for non-payment or fraud.

Okay, this would lead to a permanent loss of resources, whereas cryptocurrency does not have this issue.

For what it’s worth, this is quite implementation specific and leaves a lot of room for intentional and appropriate design decisions. Custom smart contract (think “decentralized program”) code could be used to enable the functionality desired for an RIR, without other functionality.

Let’s extrapolate: An RIR could use smart contracts with immutable code to allow an entity to register a specific block and retain certain permissions over that block. Furthermore, the code could permit RIR-initiated revocation only in certain circumstances (perhaps such as non-payment) and could even handle expiration via variables set in the token, thereby handling some of this natively on-chain and not requiring manual action from an RIR for expiry. These could be locked to specific owners or free for transfer.
The only thing that being on-chain mandates here is that the code executed is the code put on-chain, and that what happens - stays “happened”. E.g. the past is immutable. Transfers are still possible.
FWIW, many of these design decisions have been addressed by one of the larger projects out there, ENS, which bares some similarity in use case.

8

In technical terms, RIRs can indeed configure IPs to become RPKI invalid.

Incorrect.

If the RIR revokes the resource certificate used to sign the ROA, the ROA is also then revoked. Validator software will then remove the VRPs that had been created from that previously valid ROA. If there are no other VRPs that cover the BGP message parameters, the validator will return NOTFOUND.

If the RIR refused to publish or deleted the ROA, validators will eventually delete them, which also removes the VRP previously created. If there are no other VRPs that cover the BGP message parameters, the validator will return NOTFOUND.

9

Not really. If it's technically feasible to override or roll back
transactions, you've violated one of the central tenets of block
chain. You can design a system that allows transactions to be rolled
back or changed by a central authority but the result would not be a
block chain and would not have the desired characteristic of
resistance against government compulsion.

Regards,
Bill Herrin

10

If it's technically feasible to override or roll back

transactions, you've violated one of the central tenets of block
chain.

To be clear, I did not state such. Ownership can be transferred by smart contract. This does not violate a core tenet of blockchains and is a key feature of almost all blockchains which still exhibit signs of life.

11

If the RIR can institute a revocation via smart contract, for any
reason, then you haven't achieved any resilience against government
compulsion applied to the RIR, which was Brandon's reason for
considering blockchain in the first place.

Regards,
Bill Herrin

12

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.

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.

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 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".

Another concept is to use blockchain technology. While cryptocurrencies use computational power to verify ownership, BGP could use peer count. If an IP resource is marked as valid by a majority of high-influence networks (with many peers), it could be trusted by the entire internet.

I see where you're going - blockchains are an audit log (eg Certificate Transparency) and cryptocurrencies generally use something expensive to perform anti-sybil to gate appending to the audit log, but allowing the largest ISPs to randomly assign or re-assign resources doesn't solve the problem, it only makes it worse (and we can't do the thing cryptocurrencies do where resource holders have keys which are required to move the resources, because its legitimate for a RIR to reclaim resources for non-payment).

Having a cryptographic audit log of RPKI changes (published by the RIRs, presumably) isn't the worst idea in the world, but it doesn't really buy us a lot so its just kinda added complexity.

Matt

13

Matt Corallo writes:

I see where you're going - blockchains are an audit log (eg Certificate
Transparency) and cryptocurrencies generally use something expensive to
perform anti-sybil to gate appending to the audit log, but allowing the
largest ISPs to randomly assign or re-assign resources doesn't solve the
problem, it only makes it worse (and we can't do the thing cryptocurrencies
do where resource holders have keys which are required to move the
resources, because its legitimate for a RIR to reclaim resources for
non-payment).

Having a cryptographic audit log of RPKI changes (published by the RIRs,
presumably) isn't the worst idea in the world, but it doesn't really buy us
a lot so its just kinda added complexity.

There are some tools out there either directly using or inspired by
Certificate Transparency that facilitate transparency logging of other
kinds of events. It might be interesting to put RPKI events into one
of those.

The big difference between blockchains and systems like CT is that the
latter do have single points of failure (an operator can shut down the
log completely, or break it in other ways), or at least relatively
small numbers of organizations that together have this power. But
participants in the system who cheat will generally get caught doing so
(that is, they'll leave records showing that they cheated).

A blockchain doesn't have the single point of failure, because new parties
can always come in and start mining on it even if previous miners cheat
or stop. (Like in real life, the government of China apparently somewhat
abruptly told the huge community of mining companies there to stop
mining Bitcoin, and miners elsewhere seamlessly picked up the slack.)
But a blockchain may have extremely high overhead in order to achieve
that property, whereas a system like CT doesn't.

We might say that a blockchain is tamper-proof (if its economic
assumptions hold!) while CT is more tamper-evident. CT logs can and
do fail

https://www.agwa.name/blog/post/how_ct_logs_fail

which would be a big risk if we didn't have enough redundancy in the
system, and maybe a risk if governments someday don't want people to
run CT logs.

14

Tom,

Something I’ve been curious about for some time: since deployment of RPKI is (mostly) hosted by the RIRs and ultimately, the RIRs control the validation chain, what would happen if the RIR creates (or, if you prefer, is directed by court order to create) INVALIDs?

Regards,
-drc

15

Possibly one use of a blockchain RPKI would be to restrict the RIR's ability to sign RPKIs to address ranges under their management. The blockchain would then be used for inter-RIR transfers, preventing RIRs from going rogue and interfering with each other's RPKIs (such as a court using it's power over RIRs in it's jurisdiction to censor address space under another RIR). Perhaps over time additional RIRs could be created or even end user orgs could withdraw their RPKIs from the legacy RIR system into the new RIRs or their own custody.

-Rob

16

Something I’ve been curious about for some time: since deployment of RPKI is (mostly) hosted by the RIRs and ultimately, the RIRs control the validation chain, what would happen if the RIR creates (or, if you prefer, is directed by court order to create) INVALIDs?

As explained earlier, RIRs cannot “create” INVALIDs.

Remember that RIRs role in RPKI is to validate that the organization creating ROAs is the one authorized to do so, because the number resources are assigned to them. That’s it. They have no function in saying anything about the ROAs themselves.

RIRs could always invalidate the resource certificate if forced, which would invalidate those ROAs too, but that would lead to NOTFOUND from a validator, NOT INVALID INVALID means ‘a VRP exists that covers this prefix, but does not MATCH it’.

17

> 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)

18

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’.

19

Hi Tom,

Wouldn't they just withdraw the delegation and issue an AS0 ROA
covering the address block? Does that not cause the associated route
advertisements to become RPKI invalid?

Regards,
Bill Herrin

20

Yeah ,that’s what I meant. They can remove the certificate for the resource holder and sign a new certificate for these resources and set ROA for as0 only. Technically speaking.