constraining RPKI Trust Anchors
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 https://www.ietf.org/archive/id/draft-snijders-constraining-rpki-trust-ancho... 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 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. Thanks! Matt On Tue, Sep 26, 2023 at 9:57 AM Job Snijders via NANOG <nanog@nanog.org> wrote:
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
https://www.ietf.org/archive/id/draft-snijders-constraining-rpki-trust-ancho...
Your feedback is appreciated.
Kind regards,
Job
Dear Matthew, See below On Tue, 26 Sep 2023 at 20:49, Matthew Petach <mpetach@netflight.com> wrote:
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
On Sep 26, 2023, at 09:56, Job Snijders via NANOG <nanog@nanog.org> wrote:
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 https://www.ietf.org/archive/id/draft-snijders-constraining-rpki-trust-ancho...
Your feedback is appreciated.
Kind regards,
Job
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
On Oct 11, 2023, at 01:01, Martin Pels <martin+nanog@rodecker.nl> wrote:
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
Dear Martin, On Wed, Oct 11, 2023 at 10:01:53AM +0200, Martin Pels wrote:
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]: https://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml [1]: https://www.ietf.org/archive/id/draft-snijders-constraining-rpki-trust-ancho... [2]: https://packages.debian.org/stable/rpki-trust-anchors
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
Sent from my iPhone
On Oct 11, 2023, at 15:29, Randy Bush <randy@psg.com> wrote:
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.
randy
participants (7)
-
Delong.com -
Job Snijders -
Joelja Bogus -
Martin Pels -
Matt Corallo -
Matthew Petach -
Randy Bush