Re: constraining RPKI Trust Anchors

[Matthew Petach <mpetach () netflight com>]

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-anchors-00.html
>
> Your feedback is appreciated.
>
> Kind regards,
>
> Job