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