A Solution to Concerns on the Current RPKI Trust Anchor Configuration
This blog post is part of the NRO RPKI Program series. Read the previous posts here.
Representatives of the five RIRs propose RPKI Trust Anchor constraints — a draft RPKI protocol that binds each Trust Anchor to its rightful resources, enabling safe inter-RIR transfers and so closing a long-standing validation gap.
In the context of the Resource Public Key Infrastructure (RPKI), validation is performed by Relying Party (RP) software. RPs are commonly configured with five Trust Anchors (TAs), one for each of the Regional Internet Registries (RIRs). Each TA operator is able to make arbitrary RPKI statements about Internet number resources independently of the other TA operators: for example, one TA could issue a Route Origin Authorization for resources that have actually been assigned to another TA. The fact that TAs can claim resources for which they are not authoritative has created concerns among the technical community.
As part of the NRO RPKI Program, representatives of the five RIRs have been working on a draft specification to address these concerns. This specification has now been posted to the SIDR Operations working group (sidrops WG) in the IETF and will be discussed during the sidrops WG session on Nov 3rd in Montreal.
How This Solution Works
The document defines a protocol that a group of RPKI TAs can use to make statements about which TA is authoritative for which Internet number resources. The aim of this work is to protect RPKI clients from TAs claiming resources that they do not actually hold.
The protocol involves each TA agreeing to an initial distribution of resources and then signing an object to that effect. After that object has been issued, TAs can issue additional objects in order to perform transfers. For transfers, only the source and the recipient TAs are involved in signing the relevant objects. TAs can also assert on their own initiative that they have received resources from IANA, or have returned resources to IANA, by way of other signed objects.
Periodically, the TAs will each issue a new “distribution of resources” object at an agreed time, which then functions as the new initial state for clients. This new state follows logically from the previous state and all changes that occurred since. Furthermore, this acts as a check on mistakes or errors that occur in transfers or IANA-related operations.
One of the requirements of the protocol is that a single TA cannot cause constraint validation to fail. This limits the risk of a mistake or error at one RIR from having an operational impact on clients.
This document is intended to align with the emerging consensus in the RIR Governance Document that arises from the ICP-2 update process. While the TA constraints functionality is intended to be usable by any group of RPKI TAs, the final specification will be such that the RIRs will be able to implement the TA constraints functionality as well as fulfilling all of the requirements from the governance requirements document.
Note that in the scenario with TA Constraints there may be temporary Internet number resource overlaps to allow for make-before-break when Internet number resources are being transferred across RIRs.
What Now
We would like to invite the broader technical community to join the discussion about this proposed specification to iterate it and improve it based on feedback received. Read the draft, join the discussion in the sidrops mailing list, join the discussion at the sidrops working group session and please share your feedback.
Learn more about ARIN’s RPKI services at arin.net/RPKI.
Any views, positions, statements, or opinions of a guest blog post are those of the author alone and do not represent those of ARIN. ARIN does not guarantee the accuracy, completeness, or validity of any claims or statements, nor shall ARIN be liable for any representations, omissions, or errors contained in a guest blog post.
Recent blogs categorized under: RPKI
GET THE LATEST!
Sign up to receive the latest news about ARIN and the most pressing issues facing the Internet community.
SIGN ME UP →Blog Categories
RPKI • Caribbean • Outreach • Public Policy • Elections • ARIN Bits • Grant Program • Tips • Fellowship Program • Training • Security • Updates • IPv6 • Guest Post • Data Accuracy • Business Case for IPv6 • Internet Governance • IPv4 • Customer Feedback • IRR
