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
