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