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