Dear all,
Two weeks ago AFRINIC was placed under receivership by the Supreme Court
of Mauritius. This event prompted me to rethink the RPKI trust model and
associated risk surface.
The RPKI technology was designed to be versatile and flexible to
accommodate a myriad of real-world deployment scenarios including
multiple trust anchors existing, inter-registry transfers, multiple
transports, and permissionless innovation for signed objects, for
example. All good and well ... but ofcouse there is a fine print. 
Over the years various people have expressed astonishment about each RIR
having issued so-called 'all-resources' (0.0.0.0/0 + ::/0) trust anchor
certificates, but this aspect often is misunderstood: the risk is not
necessarily in the listing of 'all-resources' itself, it is in the RIR
being able to issue an 'all-resources' certificate in the first place.
RPKI trust anchor operators indeed can voluntarily reduce the scope of
subordinate Internet Number Resources, but just as easily increase the
scope of their authority. In other words, a trust anchor cannot truly
constrain itself.
Upon reconsideration on how exactly RPKI hooks into the real world; I
concluded trust anchors do not require unbounded trust in order to
provide constructive services in the realm of BGP routing security.
Some examples: ARIN does not support inter-RIR IPv6 transfers, so it
would not make any sense to see a ROA subordinate to ARIN's trust anchor
covering RIPE-managed IPv6 space. Conversely, it wouldn't make sense
to observe a ROA covering ARIN-managed IPv6 space under APNIC's,
LACNIC's, or RIPE's trust anchor - even if a cryptographically valid
certificate path existed. Along these lines AFRINIC doesn't support
inter-RIR transfers of any kind; and none of the RIRs have authority
over private resources like 10.0.0.0/8 or AS 65535. It seems feasible to
paint constraints around RPKI trust anchors in broad strokes.
Over the last two weeks I've diligently worked with Theo Buehler to
research RIR transfer policies, untangle the history of the IANA->RIR
and RIR->RIR allocation spaghetti, design & implement a maintainable
constraints mechanism for rpki-client(8), and publicly document the
concept of applying operator-defined policy to derived trust arcs.
Please take a moment to read
Your feedback is appreciated.
Kind regards,
Job
Job,
This looks fantastic, thank you!
For my edification and clarification, the reason you don’t need a
deny 2000::/3
or
Dear Matthew,
See below
Job,
This looks fantastic, thank you!
For my edification and clarification, the reason you don’t need a
deny 2000::/3
or
```
deny 0::/0
```
at the bottom of the ARIN list of allows is that every file comes with an implicit “deny all”, is that correct?
Is there a drawback to adding the explicit “deny 0::/0” at the bottom of the file, to make it clear that everything else will return “invalid”?
I tend to prefer being explicit in my configurations, rather than depending upon implicit behaviours which might change with future versions of software releases.
Sorry, the lede is a bit buried on how exactly the policy language works. It’s in the appendix, and the example source code offers hints too
https://marc.info/?l=openbsd-tech&m=169574305230941&w=2
I’ll elaborate a bit here: the order of the entries in each constraints file is not significant. All “deny” entries take precedence over all “allow entries”. Individual “deny” entries may not overlap with any other “deny” entries. Individual “allow” entries may not overlap with other “allow” entries. Deny entries are available to punch holes in allow entries, as a shortcut. If overlapping constraints are configured the program errors.
If a constraint is applied to a resource class (for example by specifying just a single “allow 2000::/3” entry), all EE certificates with IPv6 resources in their respective RFC 3779 extensions under that TA must be encompassed in that single allow entry. So the “implicit deny” comes into effect the moment you’d configure at least one allow entry for a resource class (IPv4, IPv6, or AS numbers). This is why no additional “deny the rest” line is needed in the case of ARIN.
This approach was the best I could muster on short notice. My objective wasn’t to invent a policy language everyone should adopt, but rather to draw attention to the concept of constraining RPKI trust anchors and provide some running code to advance the dialogue.
Thank you for reading the document and asking questions!
Kind regards,
Job
Thank you!
This is awesome and very, very much needed work.
RPKI has plugged some major security issues with the DFZ, but in exchange introduced substantial other ones. It sucks it took AFRINIC imploding to motivate more time fixing it, but I’m super glad you’re working on it!
We should also consider further constraining RPKI, IMO, though how isn’t entirely clear. One further possible change would be for RIR allocation changes time to be delayed by validators such that any loss of address space by RPKI enforcement takes a few months, giving operators some time to respond.
Matt
Hi Job,
I think this is important work.
As you indicated in your mail you have spent quite some time compiling the constraints files in the appendix. Keeping them up to date requires tracking allocations and policy developments in all RIRs. It reminds me of bogon filters for unallocated IP space, and the associated problems of networks not updating them[0].
So while each RP should be able to make policy decisions based on its own local criteria, managing a default set of constraints is something that is best done centralized. Who do you envision should manage these lists? RP software maintainers? RIRs? Others?
[0] https://archive.nanog.org/meetings/nanog33/presentations/deitrich.pdf, slide 4
Kind regards,
Martin
Isn’t this sort of related to the AS-0 ROA effort a while back (except some of the RIRs rejected it, unfortunately)?
I suspect that the same reasons behind rejection of AS-0 will also apply to RIR implementation of something like this, so plans to address that (and revive AS-0 perhaps) might also be a worthy effort.
Owen
Dear Martin,
I think this is important work.
Thanks!
As you indicated in your mail you have spent quite some time compiling
the constraints files in the appendix. Keeping them up to date
requires tracking allocations and policy developments in all RIRs. It
reminds me of bogon filters for unallocated IP space, and the
associated problems of networks not updating them [0].
Yes, indeed there is a burden associated with this risk mitigation
approach. I deem tracking of ratified policies in all RIRs feasible, but
yeah... it'll definitely be a recurring quarterly todo item. The current
approach in developing these default constraint listings is to focus on
coarse-grained filters, and not bother to document unallocated space
because the resulting churn would hard to manage & distribute.
So while each RP should be able to make policy decisions based on its
own local criteria, managing a default set of constraints is something
that is best done centralized. Who do you envision should manage these
lists? RP software maintainers? RIRs? Others?
I guess initially it'll be the RP developers (like me), because who else
is chartered to produce such listings at this moment? I do intend to
keep [1] updated. Would you like to help?
I envision the default constraints can be distributed via packages like
rpki-trust-anchors [2] and integral in operating systems like OpenBSD in
order to reduce the burden on operators.
A potential follow-up exercise here could be to propose to increase the
level of detail in IANA's IPv4 Address Space Registry [0] by - for
example - documenting the longer-than-/8 blocks each RIR transferred to
AFRINIC when AFRINIC was instantiated.
Kind regards,
Job
[0]: IANA IPv4 Address Space Registry
[1]: Constraining RPKI Trust Anchors
[2]: Debian -- Details of package rpki-trust-anchors in bookworm
So while each RP should be able to make policy decisions based on its
own local criteria, managing a default set of constraints is something
that is best done centralized. Who do you envision should manage these
lists? RP software maintainers? RIRs? Others?
and how will this pain-to-maintain list be distributed? how do i know
a copy is authentic not an attack?
i am all for a single root of trust. it's just that i thought it was
the iana's job. but i am easily confused.
randy
So while each RP should be able to make policy decisions based on its
own local criteria, managing a default set of constraints is something
that is best done centralized. Who do you envision should manage these
lists? RP software maintainers? RIRs? Others?
and how will this pain-to-maintain list be distributed? how do i know
a copy is authentic not an attack?
i am all for a single root of trust. it's just that i thought it was
the iana's job. but i am easily confused.
Not clear to me how IANA constrains the behavior of the rirs either now or in the future.