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 <na...@as397444.net> wrote: > >> On 11/18/24 5:11 AM, Niels Bakker wrote: >> > * na...@as397444.net (Matt Corallo) [Sun 17 Nov 2024, 20:44 CET]: >> >> Apologies if it came across as insulting, indeed I wasn't spending my >> time reading IETF mailing >> >> lists in the early 2010s :). That said, the reality today is that RPKI >> trust anchors are perfectly >> >> capable of (through malice or cybersecurity incidents) AS0-routing as >> much IP space as they want, >> >> taking entire swaths of the internet offline for a day or more at a >> time. So even if there was a >> >> ton of hand-wringing about it prior to deployment, that didn't >> translate into any best practices >> >> which actually reduce the trust the RPKI system has. >> > >> > Please take some time to read up on what countermeasures against RIRs >> "AS0-routing as much IP space >> > as they want" are being taken by developers of validators before >> posting here again. >> >> Feel free to provide a link, the only constraining I'm aware of is what's >> documented in >> draft-snijders-constraining-rpki-trust-anchors, which does not, as far as >> I understand, constrain AS 0 at all. > > > > It does though. The constraining-rpki-trust-anchors mechanism effectively > prohibits RIRs from issuing ROAs (with any Origin AS, including AS 0), if > the ROA at hand violates the locally configured constraints. > > The goal was to introduce a small policy language to mitigate some risk > around one RIR issuing ROAs covering IP space managed by another RIR. > Compartmentalise and isolate risks in the system. > > The example constraints in the draft are also the ones distributed with > rpki-client, nowadays used by many ISPs. > > > Given no one else in this thread has commented about any specific >> constraints, it seems like a great chance to educate lots of people! > > > > This might interest you: detecting and rejecting AS0 TALs, > https://marc.info/?l=openbsd-tech&m=173289357532392&w=2 > > Regards, > > Job >
