Implementing Decentralized RPKI with Blockchain Technology
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? *Brandon Z.* HUIZE LTD www.huize.asia <https://huize.asia/>| www.ixp.su | Twitter This e-mail and any attachments or any reproduction of this e-mail in whatever manner are confidential and for the use of the addressee(s) only. HUIZE LTD can’t take any liability and guarantee of the text of the email message and virus.
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 On Wed, Nov 13, 2024 at 9:42 AM Brandon Z. <Brandon@huize.asia> 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.
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? *Brandon Z.* HUIZE LTD www.huize.asia <https://huize.asia/>| www.ixp.su | Twitter
This e-mail and any attachments or any reproduction of this e-mail in whatever manner are confidential and for the use of the addressee(s) only. HUIZE LTD can’t take any liability and guarantee of the text of the email message and virus.
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.
On Nov 13, 2024, at 09:39, Brandon Z. <Brandon@huize.asia> 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.
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? Brandon Z. HUIZE LTD www.huize.asia <https://huize.asia/>| www.ixp.su <https://www.ixp.su/> | Twitter
This e-mail and any attachments or any reproduction of this e-mail in whatever manner are confidential and for the use of the addressee(s) only. HUIZE LTD can’t take any liability and guarantee of the text of the email message and virus.
On Wed, Nov 13, 2024 at 6:39 AM Brandon Z. <Brandon@huize.asia> wrote:
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.
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 -- William Herrin bill@herrin.us https://bill.herrin.us/
Hi William,
Under block chain, an RIR would not be able to revoke number resources, not even for non-payment or fraud.
Also, please don't cross-post discussions to two lists. It's against
Okay, this would lead to a permanent loss of resources, whereas cryptocurrency does not have this issue. 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, *Brandon Z.* HUIZE LTD www.huize.asia <https://huize.asia/>| www.ixp.su | Twitter This e-mail and any attachments or any reproduction of this e-mail in whatever manner are confidential and for the use of the addressee(s) only. HUIZE LTD can’t take any liability and guarantee of the text of the email message and virus. On Wed, 13 Nov 2024 at 12:16, William Herrin <bill@herrin.us> wrote:
On Wed, Nov 13, 2024 at 6:39 AM Brandon Z. <Brandon@huize.asia> wrote:
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.
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
-- William Herrin bill@herrin.us https://bill.herrin.us/
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](https://docs.ens.domains/wrapper/overview), which bares some similarity in use case. On Wednesday, November 13th, 2024 at 2:37 PM, Brandon Z. - Brandon at huize.asia <brandon_at_huize_asia_gortof@simplelogin.co> wrote:
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, Brandon Z. HUIZE LTD [www.huize.asia](https://huize.asia/)| [www.ixp.su](https://www.ixp.su/) | Twitter
This e-mail and any attachments or any reproduction of this e-mail in whatever manner are confidential and for the use of the addressee(s) only. HUIZE LTD can’t take any liability and guarantee of the text of the email message and virus.
On Wed, 13 Nov 2024 at 12:16, William Herrin <bill@herrin.us> wrote:
On Wed, Nov 13, 2024 at 6:39 AM Brandon Z. <Brandon@huize.asia> wrote:
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.
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
-- William Herrin bill@herrin.us https://bill.herrin.us/
On Wed, Nov 13, 2024 at 12:13 PM Jason R. Rokeach <jason-at-nanog.lb61g@8shield.net> wrote:
Under block chain, an RIR would not be able to revoke number> resources, not even for non-payment or fraud.
For what it's worth, this is quite implementation specific and leaves a lot of room for intentional and appropriate design decisions.
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 -- William Herrin bill@herrin.us https://bill.herrin.us/
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. On Wednesday, November 13th, 2024 at 6:07 PM, William Herrin - bill at herrin.us <bill_at_herrin_us_grgdxpcjd@simplelogin.co> wrote:
On Wed, Nov 13, 2024 at 12:13 PM Jason R. Rokeach jason-at-nanog.lb61g@8shield.net wrote:
Under block chain, an RIR would not be able to revoke number> resources, not even for non-payment or fraud.
For what it's worth, this is quite implementation specific and leaves a lot of room for intentional and appropriate design decisions.
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
-- William Herrin bill@herrin.us https://bill.herrin.us/
On Wed, Nov 13, 2024 at 4:32 PM Jason R. Rokeach <jason-at-nanog.lb61g@8shield.net> wrote:
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.
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 -- William Herrin bill@herrin.us https://bill.herrin.us/
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. On Wed, Nov 13, 2024 at 2:41 PM Brandon Z. <Brandon@huize.asia> wrote:
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, *Brandon Z.* HUIZE LTD www.huize.asia <https://huize.asia/>| www.ixp.su | Twitter
This e-mail and any attachments or any reproduction of this e-mail in whatever manner are confidential and for the use of the addressee(s) only. HUIZE LTD can’t take any liability and guarantee of the text of the email message and virus.
On Wed, 13 Nov 2024 at 12:16, William Herrin <bill@herrin.us> wrote:
On Wed, Nov 13, 2024 at 6:39 AM Brandon Z. <Brandon@huize.asia> wrote:
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.
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
-- William Herrin bill@herrin.us https://bill.herrin.us/
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
On Nov 13, 2024, at 11:59 PM, Tom Beecher <beecher@beecher.cc> wrote:
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.
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 On 2024-11-14 10:22, David Conrad via NANOG wrote:
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
On Nov 13, 2024, at 11:59 PM, Tom Beecher <beecher@beecher.cc> wrote:
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.
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'. On Thu, Nov 14, 2024 at 5:22 AM David Conrad <drc@virtualized.org> wrote:
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
On Nov 13, 2024, at 11:59 PM, Tom Beecher <beecher@beecher.cc> wrote:
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.
On Thu, Nov 14, 2024 at 9:03 AM Tom Beecher <beecher@beecher.cc> wrote:
As explained earlier, RIRs cannot "create" INVALIDs.
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 -- William Herrin bill@herrin.us https://bill.herrin.us/
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. *Brandon Z.* HUIZE LTD www.huize.asia <https://huize.asia/>| www.ixp.su | Twitter This e-mail and any attachments or any reproduction of this e-mail in whatever manner are confidential and for the use of the addressee(s) only. HUIZE LTD can’t take any liability and guarantee of the text of the email message and virus. On Fri, Nov 15, 2024 at 01:21 William Herrin <bill@herrin.us> wrote:
On Thu, Nov 14, 2024 at 9:03 AM Tom Beecher <beecher@beecher.cc> wrote:
As explained earlier, RIRs cannot "create" INVALIDs.
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
-- William Herrin bill@herrin.us https://bill.herrin.us/
William- Yes, you're correct on that point. Fundamentally though, if an RIR actually did that, it's effectively the end of RPKI, and seismic damage to the internet at large. The entire foundation of this system is that everything must trust that the RIRs are the source of truth over what IPs are allocated and to whom. RPKI just provides a way to cryptographically verify it. If an RIR was forced to pull an allocation by an external party for "non-normal" reasons, then trust in that RIR is irrevocably broken, and we have much larger issues to deal with. On Thu, Nov 14, 2024 at 5:28 PM Brandon Z. <Brandon@huize.asia> wrote:
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.
*Brandon Z.* HUIZE LTD www.huize.asia <https://huize.asia/>| www.ixp.su | Twitter
This e-mail and any attachments or any reproduction of this e-mail in whatever manner are confidential and for the use of the addressee(s) only. HUIZE LTD can’t take any liability and guarantee of the text of the email message and virus.
On Fri, Nov 15, 2024 at 01:21 William Herrin <bill@herrin.us> wrote:
On Thu, Nov 14, 2024 at 9:03 AM Tom Beecher <beecher@beecher.cc> wrote:
As explained earlier, RIRs cannot "create" INVALIDs.
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
-- William Herrin bill@herrin.us https://bill.herrin.us/
Haven't we seen this pattern enough times? 1. some organization maintains some database with some data 2. someone asks what if the government forces it to falsify/censor data 3. someone says it would ruin trust and nobody would use the database any more 4. government forces organization to falsify/censor data 5. everyone keeps using that database because it's the low friction path 6. amount of false/censored data increases Governments already censor everything they can physically get their hands on: * IP ranges * DNS (ISP/open resolvers, registries *and* registrars) * messaging apps * social media * end device software and data (only when the vendor already controls it, by pressuring the vendor) If a little birdie told a censor that if they force *this* organization to publish this data block, *that* organization would automatically block *that* resource they don't like, they would go for it. There's absolutely no reason to think they would not. And no, the 1st Amendment won't prevent it, even in the USA. On 14/11/24 23:44, Tom Beecher wrote:
William-
Yes, you're correct on that point.
Fundamentally though, if an RIR actually did that, it's effectively the end of RPKI, and seismic damage to the internet at large. The entire foundation of this system is that everything must trust that the RIRs are the source of truth over what IPs are allocated and to whom. RPKI just provides a way to cryptographically verify it. If an RIR was forced to pull an allocation by an external party for "non-normal" reasons, then trust in that RIR is irrevocably broken, and we have much larger issues to deal with.
On Thu, Nov 14, 2024 at 5:28 PM Brandon Z. <Brandon@huize.asia> wrote:
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.
*Brandon Z.* HUIZE LTD www.huize.asia <https://huize.asia/>| www.ixp.su <https://www.ixp.su/> | Twitter
This e-mail and any attachments or any reproduction of this e-mail in whatever manner are confidential and for the use of the addressee(s) only. HUIZE LTD can’t take any liability and guarantee of the text of the email message and virus.
On Fri, Nov 15, 2024 at 01:21 William Herrin <bill@herrin.us> wrote:
On Thu, Nov 14, 2024 at 9:03 AM Tom Beecher <beecher@beecher.cc> wrote: > As explained earlier, RIRs cannot "create" INVALIDs.
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
-- William Herrin bill@herrin.us https://bill.herrin.us/
++ From: NANOG <nanog-bounces+vasilenko.eduard=huawei.com@nanog.org> On Behalf Of Alex Sent: Friday, November 15, 2024 03:46 To: nanog@nanog.org Subject: Re: Implementing Decentralized RPKI with Blockchain Technology Haven't we seen this pattern enough times? 1. some organization maintains some database with some data 2. someone asks what if the government forces it to falsify/censor data 3. someone says it would ruin trust and nobody would use the database any more 4. government forces organization to falsify/censor data 5. everyone keeps using that database because it's the low friction path 6. amount of false/censored data increases Governments already censor everything they can physically get their hands on: * IP ranges * DNS (ISP/open resolvers, registries *and* registrars) * messaging apps * social media * end device software and data (only when the vendor already controls it, by pressuring the vendor) If a little birdie told a censor that if they force *this* organization to publish this data block, *that* organization would automatically block *that* resource they don't like, they would go for it. There's absolutely no reason to think they would not. And no, the 1st Amendment won't prevent it, even in the USA. On 14/11/24 23:44, Tom Beecher wrote: William- Yes, you're correct on that point. Fundamentally though, if an RIR actually did that, it's effectively the end of RPKI, and seismic damage to the internet at large. The entire foundation of this system is that everything must trust that the RIRs are the source of truth over what IPs are allocated and to whom. RPKI just provides a way to cryptographically verify it. If an RIR was forced to pull an allocation by an external party for "non-normal" reasons, then trust in that RIR is irrevocably broken, and we have much larger issues to deal with. On Thu, Nov 14, 2024 at 5:28 PM Brandon Z. <Brandon@huize.asia<mailto:Brandon@huize.asia>> wrote: 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. Brandon Z. HUIZE LTD www.huize.asia <https://huize.asia/> | www.ixp.su<https://www.ixp.su/> | Twitter [https://ci3.googleusercontent.com/mail-sig/AIorK4w5mVhfW4gNpNNG4wjzSr6YXLPGs...] This e-mail and any attachments or any reproduction of this e-mail in whatever manner are confidential and for the use of the addressee(s) only. HUIZE LTD can’t take any liability and guarantee of the text of the email message and virus. On Fri, Nov 15, 2024 at 01:21 William Herrin <bill@herrin.us<mailto:bill@herrin.us>> wrote: On Thu, Nov 14, 2024 at 9:03 AM Tom Beecher <beecher@beecher.cc<mailto:beecher@beecher.cc>> wrote:
As explained earlier, RIRs cannot "create" INVALIDs.
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 -- William Herrin bill@herrin.us<mailto:bill@herrin.us> https://bill.herrin.us/
On Thu, Nov 14, 2024 at 2:44 PM Tom Beecher <beecher@beecher.cc> wrote:
Yes, you're correct on that point.
Fundamentally though, if an RIR actually did that, it's effectively the end of RPKI, and seismic damage to the internet at large.
We're talking about what an RIR can do if ordered by a court with jurisdiction. Remember: a court ordered AFRINIC to do some pretty remarkable things in the not too distant past. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
We're talking about what an RIR can do if ordered by a court with jurisdiction. Remember: a court ordered AFRINIC to do some pretty remarkable things in the not too distant past.
Sure, but my point is still the same. If at any point, we cannot trust that an RIR is the authoritative record holder of IP allocations , be it malfeasance/negligence, or a legal/government entity forcing them to take an action outside of established policy, then RPKI is severely crippled, if not useless. However, I think it's an overblown concern. If a government entity has the courts in their pocket to force an RIR to do a thing, they have the power to do abou 10 other much easier things that would actually prevent full access to the thing they don't like. ( I'm taking your servers, I'm forcing you to unplug routers, etc) Doesn't really make sense for them to force the RIR to do a think that would only disrupt access, not prevent it entirely. On Thu, Nov 14, 2024 at 8:24 PM William Herrin <bill@herrin.us> wrote:
On Thu, Nov 14, 2024 at 2:44 PM Tom Beecher <beecher@beecher.cc> wrote:
Yes, you're correct on that point.
Fundamentally though, if an RIR actually did that, it's effectively the end of RPKI, and seismic damage to the internet at large.
We're talking about what an RIR can do if ordered by a court with jurisdiction. Remember: a court ordered AFRINIC to do some pretty remarkable things in the not too distant past.
Regards, Bill Herrin
-- William Herrin bill@herrin.us https://bill.herrin.us/
One country whose internet resources are nominally controlled by a RIR that's located in an enemy jurisdiction is Russia. The Netherlands could not physically invade Russia to disconnect its servers or routers, but it could easily require the invalidation of Russian internet resources since RIPE NCC falls under its jurisdiction. This would, as has already been stated, shatter the illusion of the Internet being a cohesive whole -- some people would be unable to access Russian internet sites, while other people would be unable to access European internet sites to which the formerly Russian resources were reallocated. Possibly the main reason this hasn't happened yet is that politicians don't understand what internet resources are, or how they're allocated, or what could be achieved by forcibly changing allocations. On 15/11/24 18:11, Tom Beecher wrote:
We're talking about what an RIR can do if ordered by a court with jurisdiction. Remember: a court ordered AFRINIC to do some pretty remarkable things in the not too distant past.
Sure, but my point is still the same. If at any point, we cannot trust that an RIR is the authoritative record holder of IP allocations , be it malfeasance/negligence, or a legal/government entity forcing them to take an action outside of established policy, then RPKI is severely crippled, if not useless.
However, I think it's an overblown concern. If a government entity has the courts in their pocket to force an RIR to do a thing, they have the power to do abou 10 other much easier things that would actually prevent full access to the thing they don't like. ( I'm taking your servers, I'm forcing you to unplug routers, etc)
Doesn't really make sense for them to force the RIR to do a think that would only disrupt access, not prevent it entirely.
On Thu, Nov 14, 2024 at 8:24 PM William Herrin <bill@herrin.us> wrote:
On Thu, Nov 14, 2024 at 2:44 PM Tom Beecher <beecher@beecher.cc> wrote: > Yes, you're correct on that point. > > Fundamentally though, if an RIR actually did that, it's effectively the end of RPKI, and seismic damage to the internet at large.
We're talking about what an RIR can do if ordered by a court with jurisdiction. Remember: a court ordered AFRINIC to do some pretty remarkable things in the not too distant past.
Regards, Bill Herrin
-- William Herrin bill@herrin.us https://bill.herrin.us/
* Possibly the main reason this hasn't happened yet is that politicians don't understand what internet resources are, or how they're allocated, or what could be achieved by forcibly changing allocations. Nope, you underestimate politicians, they have consultants that are very smart. Isolation is a tool of weakness. Some could not win, hence he isolates himself from the danger. West/NATO still leading the war on the Internet. Then isolation does not make sense. The Internet is a good channel for influence. Hundreds of millions are spent on spreading FUD, and a different sort of propaganda. The Internet has been a battlefield for a long time. I have seen it as it was started and progressed over 20 years. Russia was feeble initially, not capable at all (they could say “it was started not by us”). Russia is still weaker, thousands of blocked sites is a sign of weakness. I do not believe that Russia would ever be as professional as the West in brainwashing (Russia has strengths in different fields). Hence, the West would never start isolation on a wide scope. Some particular ASes would be probably blocked sooner or later. Despite it would be a confession of some weaknesses. West public opinion is the only thing that refrains politicians from starting blocking some ASes. IMHO: it would happen because there would be not enough progress on the other battlefields. Politicians would become a little desperate. IMHO: the war would be driven to the Internet, like you or not. Fighting in all arenas/spaces was advice from all the biggest war theoretics (Clausewitz, Sun Tzu, etc). Ed/ From: NANOG <nanog-bounces+vasilenko.eduard=huawei.com@nanog.org> On Behalf Of Alex Sent: Friday, November 15, 2024 21:00 To: nanog@nanog.org Subject: Re: Implementing Decentralized RPKI with Blockchain Technology One country whose internet resources are nominally controlled by a RIR that's located in an enemy jurisdiction is Russia. The Netherlands could not physically invade Russia to disconnect its servers or routers, but it could easily require the invalidation of Russian internet resources since RIPE NCC falls under its jurisdiction. This would, as has already been stated, shatter the illusion of the Internet being a cohesive whole -- some people would be unable to access Russian internet sites, while other people would be unable to access European internet sites to which the formerly Russian resources were reallocated. Possibly the main reason this hasn't happened yet is that politicians don't understand what internet resources are, or how they're allocated, or what could be achieved by forcibly changing allocations. On 15/11/24 18:11, Tom Beecher wrote: We're talking about what an RIR can do if ordered by a court with jurisdiction. Remember: a court ordered AFRINIC to do some pretty remarkable things in the not too distant past. Sure, but my point is still the same. If at any point, we cannot trust that an RIR is the authoritative record holder of IP allocations , be it malfeasance/negligence, or a legal/government entity forcing them to take an action outside of established policy, then RPKI is severely crippled, if not useless. However, I think it's an overblown concern. If a government entity has the courts in their pocket to force an RIR to do a thing, they have the power to do abou 10 other much easier things that would actually prevent full access to the thing they don't like. ( I'm taking your servers, I'm forcing you to unplug routers, etc) Doesn't really make sense for them to force the RIR to do a think that would only disrupt access, not prevent it entirely. On Thu, Nov 14, 2024 at 8:24 PM William Herrin <bill@herrin.us<mailto:bill@herrin.us>> wrote: On Thu, Nov 14, 2024 at 2:44 PM Tom Beecher <beecher@beecher.cc<mailto:beecher@beecher.cc>> wrote:
Yes, you're correct on that point.
Fundamentally though, if an RIR actually did that, it's effectively the end of RPKI, and seismic damage to the internet at large.
We're talking about what an RIR can do if ordered by a court with jurisdiction. Remember: a court ordered AFRINIC to do some pretty remarkable things in the not too distant past. Regards, Bill Herrin -- William Herrin bill@herrin.us<mailto:bill@herrin.us> https://bill.herrin.us/
Tom, On Nov 15, 2024, at 9:11 AM, Tom Beecher <beecher@beecher.cc> wrote:
However, I think it's an overblown concern. If a government entity has the courts in their pocket to force an RIR to do a thing, they have the power to do abou 10 other much easier things that would actually prevent full access to the thing they don't like. ( I'm taking your servers, I'm forcing you to unplug routers, etc)
RIRs serve multiple (potentially overlapping) jurisdictions, thereby providing a way for effects to cross national boundaries.
Doesn't really make sense for them to force the RIR to do a think that would only disrupt access, not prevent it entirely.
Forcing registrars and resolver operators to block the lookup of certain names does not prevent access entirely, yet it is a very common technique imposed by national regulators and courts all over the world. Regards, -drc
i have not seen mention that a single validing roa wins over any number of 'coerced' invalidating roas. this has implications in the space of 'saving' action(s) by an other rir, iana, an alternate registry, etc. randy
Yep, that’s a great point, and IMO all the more reason to seek solutions that provide operators/other RIRs the ability to respond by giving them human timescales, rather than things being taken out overnight.
On Nov 18, 2024, at 13:39, Randy Bush <randy@psg.com> wrote:
i have not seen mention that a single validing roa wins over any number of 'coerced' invalidating roas. this has implications in the space of 'saving' action(s) by an other rir, iana, an alternate registry, etc.
randy
William-
Yes, you're correct on that point.
Fundamentally though, if an RIR actually did that, it's effectively the end of RPKI, and seismic damage to the internet at large.
Tom, Bill Woodcock announced a framework around this concept on NANOG back in March of 2022. https://mailman.nanog.org/pipermail/nanog/2022-March/218056.html The linked document discusses manipulation of RPKI records specifically: https://www.pch.net/resources/Papers/Multistakeholder-Imposition-of-Internet... " A manipulation of RPSL and RPKI records in centralized registries would flow through to all networks employing these common routing security mechanisms, some of which would then automatically stop routing traffic to and from the specified networks, without affecting other “adjacent” civilian networks or being subject to trivial “workarounds.”" The opinion of that section of the document, at the time it was published, appears to be that fiddling with RPKI in that way constitutes and "unacceptable risk". However simple incrementalism will have that opinion changed as soon as it is more politically palatable. The fact that these frameworks are seriously proposed at all is the chilling part IMHO. Brandon This email may contain confidential information or privileged material and is intended for use solely by the above referenced recipient. Any review, copying, printing, disclosure, distribution, or other use by any other person or entity is strictly prohibited and may be illegal. If you are not the named recipient, or believe you have received this email in error, please immediately notify the City of Sherwood at (503) 625-5522 and delete the copy you received.
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.
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
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.
On 11/13/24 10:45 PM, Seth David Schoen wrote:
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
Eh, semantics. Many people (including myself!) refer to CT as a blockchain. What you're referring to, where there are many entities collaboratively advancing a blockchain, I'd call a cryptocurrency :). In any case, my point in the prior email was that a non-decentralized blockchain is probably the only relevant design in this space, as there is a natural operator already, so there's no need for any of the (attempts at) decentralized approaches. Matt
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)
On 11/14/24 12:08 PM, Christopher Morrow wrote:
On Wed, Nov 13, 2024 at 7:02 PM Matt Corallo <nanog@as397444.net> wrote:
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.
Fair enough. I suppose I wasn't reading the right corner of the internet to find it. Either way there's basically no mitigations in place for these issues today, so hand wringing or not, nothing came of it.
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
How is this SLURM? SLURM lets you allow some nets to have a local view of RPKI, which is great as long as there is some covering route in the global DFZ to reach the nets with a local view. The OP didn't mention anything about a covering route, but instead talked about where the RIR that manages the resources from the global internet's PoV decides to AS0-ROA the IPs and make them unroutable.
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?
Apologies, I had written the email somewhat in haste. Indeed, ROA is what I'd meant. Sadly, just the existence of an expiry doesn't address the issue unless (a) all RPKI RPs take full advantage of the expiry to cache entries (and MUST do so), which as far as I understand they do not (and generally isn't practical given the full-rsync+validate approach most take), (b) RIRs always maintain ROAs with timeouts at least a week (or some N) in the future (I assume most do? But I'm unaware of the exact policy).
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)
Apologies, again I meant ROAs, the email was written in some haste prior to a flight :) Matt
* nanog@as397444.net (Matt Corallo) [Sun 17 Nov 2024, 20:41 CET]:
Fair enough. I suppose I wasn't reading the right corner of the internet to find it. Either way there's basically no mitigations in place for these issues today, so hand wringing or not, nothing came of it.
I'm not sure what technical mitigations are possible against lawful court orders. Calling on RIPE NCC employees to ignore them is not workable. Let's not rehash here the decades of work spent on exchanging views with lawmakers, regulators, lobbyists etc. There are archives, both of mailing lists and of board meetings. -- Niels.
On Nov 18, 2024, at 04:18, Niels Bakker <niels=nanog@bakker.net> wrote:
* nanog@as397444.net (Matt Corallo) [Sun 17 Nov 2024, 20:41 CET]:
Fair enough. I suppose I wasn't reading the right corner of the internet to find it. Either way there's basically no mitigations in place for these issues today, so hand wringing or not, nothing came of it.
I'm not sure what technical mitigations are possible against lawful court orders. Calling on RIPE NCC employees to ignore them is not workable.
I mean you could read my original email :). But, no, of course a RIR won’t ignore a court order, indeed that’d be nuts, but we could ensure that doing so takes some nontrivial (human) time during which the operator community can decide whether they wish to respond with a new anchor/ignoring the new ROA/etc. Matt
Matt Corallo wrote on 18/11/2024 12:53:
But, no, of course a RIR won’t ignore a court order, indeed that’d be nuts, but we could ensure that doing so takes some nontrivial (human) time during which the operator community can decide whether they wish to respond with a new anchor/ignoring the new ROA/etc. You mean obstruction of justice, with intent?
Let us know how that goes. Nick
On Nov 18, 2024, at 08:04, Nick Hilliard <nick@foobar.org> wrote:
Matt Corallo wrote on 18/11/2024 12:53:
But, no, of course a RIR won’t ignore a court order, indeed that’d be nuts, but we could ensure that doing so takes some nontrivial (human) time during which the operator community can decide whether they wish to respond with a new anchor/ignoring the new ROA/etc. You mean obstruction of justice, with intent?
Let us know how that goes.
No, obviously this would have to be done in software on the validator end. Matt
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'. On Wed, Nov 13, 2024 at 10:05 PM Matt Corallo <nanog@as397444.net> wrote:
Hi there,
Currently, due to political factors, some countries are not particularly
On 11/13/24 9:39 AM, Brandon Z. wrote: 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
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
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
On Nov 18, 2024, at 00:02, Tom Beecher <beecher@beecher.cc> wrote:
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?
I didn’t suggest changing the root of trust. Indeed, the RIR is ultimately responsible for its IP space, and there’s no reason to suggest changing that. RPKI did, however, materially change the process for revoking IP space - instead of removing IP space from Whois and then needing to email various networks to get it removed from filters, RIRs can simply AS0-ROA the space and it’s gone overnight. Forcing some human timescale (via software changes in validators) onto that process pulls us one step in between the two cases. Matt
* 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. -- Niels.
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. Given no one else in this thread has commented about any specific constraints, it seems like a great chance to educate lots of people! Matt
On Mon, 18 Nov 2024 at 14:29, Matt Corallo <nanog@as397444.net> 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
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
On 11/18/24 5:11 AM, Niels Bakker wrote: trust anchors are perfectly 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
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:
* 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
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
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
On 11/18/24 5:11 AM, Niels Bakker wrote: trust anchors are perfectly translate into any best practices 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
Apologies, I missed this email when it was sent. On 11/29/24 11:35 AM, Job Snijders via NANOG wrote:
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.
Apologies, it appears I was somewhat dense when I first read it. Indeed, it implicitly does so. Of course, a RIR could still seize IP space by tagging it any other AS they control (and then ASPA that AS out of the global table), so its not really a huge change for malicious/regulatorily-induced entries, but it likely reduces mistakes.
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.
Indeed, don't think anyone in the thread ever suggested otherwise. Quite the opposite, the whole thread was about reducing risks, and indeed this is a great step towards it! Still, my original proposal at the top of this sub-thread (before it turned into a flame-fest) was never materially addressed, and takes things a step further to restore control back in the hands of operators in the case of a RIR taking deliberate and undesirable action to prevent the routing of IPs that they are responsible for:
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".
This would also, of course, be useful in conjunction with something like Brandon's note - "I believe the simplest solution is to allow cross-regional issuance of trust certificates between RIRs." Of course, this has other issues and reduces the compartmentalization of things like draft-snijders-constraining-rpki-trust-anchors, and might make more sense, for example, if the "out-of-bailiwick" entries are only allowed as additional ROAs for IP space that is already covered by "in-bailiwick" ROAs.
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 <https://marc.info/?l=openbsd- tech&m=173289357532392&w=2>
Indeed, thanks, I hadn't seen that patch when it happened. rpki-client has always been great at considering risks! Matt
participants (17)
-
Alex -
Brandon Price -
Brandon Z. -
Christopher Morrow -
David Conrad -
Francis Booth -
Jason R. Rokeach -
Job Snijders -
Matt Corallo -
Nick Hilliard -
Niels Bakker -
Randy Bush -
Robert McKay -
Seth David Schoen -
Tom Beecher -
Vasilenko Eduard -
William Herrin