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 can make arbitrary RPKI statements about Internet Number Resources (INRs) independently of the other TA operators: For example, one TA could issue a Route Origin Authorization (ROA) 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. The specification ‘RPKI Trust Anchor Constraints’ 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 3 November 2025 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 INRs. This work aims 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 Requirements 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 fulfil all of the requirements from the governance requirements document.
Note that in the scenario with TA constraints, there may be temporary INR overlaps to allow for make-before-break when INRs are being transferred across RIRs.
What now
We invite the broader technical community to review and discuss this proposed specification, helping refine and improve it through your feedback. Read the draft, join the sidrops mailing list and the WG session, and share your thoughts.
Sofia Silva Berenguer is the RPKI Program Manager for the NRO.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.