| Internet-Draft | Constraining RPKI Trust Anchors | September 2026 |
| Snijders, et al. | Expires 20 March 2027 | [Page] |
This document describes an approach for Resource Public Key Infrastructure (RPKI) Relying Parties (RPs) to impose locally configured Constraints on cryptographic products subordinate to Trust Anchors (TAs). The ability to constrain a Trust Anchor operator's effective signing authority to a limited set of Internet Number Resources (INRs) allows Relying Parties to enjoy the potential benefits of assuming trust - within a bounded scope. The specified approach and configuration format allow RPKI operators to communicate efficiently about observations related to Trust Anchor operations.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 20 March 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
This document describes an approach for Resource Public Key Infrastructure (RPKI) Relying Parties (RPs) to impose locally configured Constraints on cryptographic products subordinate to trusted Trust Anchors (TAs). The ability to constrain a Trust Anchor operator's effective signing authority to a limited set of Internet Number Resources (INRs) allows Relying Parties to enjoy the potential benefits of assuming trust - within a bounded scope. The specified approach and configuration format allow RPKI operators to communicate efficiently about observations related to Trust Anchor operations.¶
It is important to emphasize that each and every Relying Party makes its Trust Anchor inclusion decisions independently, on its own timelines, based on its own inclusion criteria; and that imposed constraints (if any) are a matter of local configuration.¶
This document is intended to address user (meaning, Network Operator and Relying Party) needs and concerns, and was authored to benefit users and providers of RPKI services by providing a common reference to be communicated within the global Internet routing system community.¶
Readers should be familiar with the RPKI, the RPKI repository structure, and the various RPKI objects, uses, and interpretations described in the following: [RFC3779], [RFC6480], [RFC6481], [RFC6487], and [RFC6488].¶
A process to construct signed RPKI Trust Anchor constraints is specified in [I-D.nro-sidrops-ta-constraints]. The aforementioned signed artefacts could serve as an input to the constraining methodology specified in this document.¶
Currently, all five Regional Internet Registries (RIRs) list 'all-resources' (0.0.0.0/0, ::/0, and AS 0-4294967295) as subordinate on their Trust Anchor certificates in order to reduce some potential for risk of invalidation in the case of transient registry inconsistencies (see [I-D.rir-rpki-allres-ta-app-statement] for more details). Such 'all-resources' listings demonstrate that - in the course of normal operations - Trust Anchors may claim authority for INRs outside the registry's current resource holdings.¶
The primary reason for transient registry inconsistencies to occur would be when resources are transferred from one registry to another. However, the ability to transfer resources between registries is not universally available: this ability depends on the implementation of registry-specific consensus-driven policy development reciprocated by other registries. Another source of churn would be the inflow of new resources following allocations made by the IANA; but because of IPv4 address exhaustion, IPv6 abundance, and 32-bit AS numbers being allocated in large blocks - IANA allocations occur far less often than they used to.¶
Absent a registry's ability to execute inter-registry transfers or frequently receive new allocations from IANA, that registry's set of holdings would be a fairly static list of resources.¶
Therefore, a Relying Party need not trust each and every signed product in a derived trust relationship to any and all INRs subordinate to the registry's Trust Anchor, even when the Trust Anchor certificate lists 'all-resources' as subordinate. Following the widely deployed information security principle of least privilege [PRIVSEP], constraining a given Trust Anchor's capacity strictly to just that what relates to the their respective current INR holdings, provides some degree of risk reduction for all stakeholders involved.¶
Consequently, knowing a registry's current resource holdings and knowing this set of holdings will not change in the near-term future; following the principle of least privilege, operators can consider applying a restricted-service operating mode towards what otherwise would be an unbounded authority. The principle of constraining Trust Anchors might be useful when for example working with RPKI testbeds [OTE], risky Trust Anchors which cover unallocated space with AS0 ROAs [AS0TAL], but also in dealings with publicly-trusted registries.¶
As noted in Section 2, the current set of publicly-trusted RPKI TA certificates are expected to overclaim in the course of normal operations. However, applying a bespoke implementation of the certification path validation algorithm to CA certificates to prune all possible certificate paths related to INRs not contained within the locally configured Constraints would not be a trivial task. Instead, an alternative and simpler approach operating on end-entity (EE) certificates is proposed.¶
To constrain a Trust Anchor, the IP address and AS number resources listed in a given EE certificate's [RFC3779] extensions must be fully contained within the locally configured union set of IP prefixes, IP address ranges, AS identifiers, and AS identifier ranges for which the Relying Party operator anticipates the Trust Anchor operator to issue cryptographic products. If a given EE certificate's listed resources are not fully contained within the Constraints, the RP should halt processing of the signed object at hand and considers the EE certificate invalid.¶
The above described approach applies to all RPKI objects for which an explicit listing of resources is mandated in their respective [RFC3779] extensions; such as BGPSec Router Certificates [RFC8209], ROAs [RFC9582], ASPAs [I-D.ietf-sidrops-aspa-profile], and RSCs [RFC9323].¶
The approach has no application in context of Signed Objects unrelated to INRs (which thus use 'inherit' elements), for example, Signed TALs [RFC9691] and Manifests [RFC9286].¶
The validation of Constraint containment is a check in addition to all the validation checks specified in [RFC6487], [RFC6488], and each Signed Object's profile specification.¶
As it's clumsy and error prone to calculate the complement of a block of resources, for efficiency a simple notation in the form of allow and deny keywords is used to indicate INRs which may or may not appear subordinate to a Trust Anchor (rather than merely using lengthy exhaustive allowlists of what INRs may appear under a given Trust Anchor).¶
The constraints configuration format is line-oriented. Comments can be put anywhere in the file using a hash mark ('#') and extend to the end of the current line. Each non-empty, non-comment line contains exactly one constraint entry. Each constraint entry begins with either the allow or deny keyword, followed by the resource to which the entry applies.¶
A resource can be an IPv4 prefix, an IPv6 prefix, an IPv4 address range, an IPv6 address range, a single AS identifier, or an AS range. Ranges include the end points. The two end points of a range are separated by a hyphen '-' and the numerically lower end point comes first.¶
An example is:¶
<CODE BEGINS> # Example constraints following the format described in # draft-ietf-sidrops-constraining-rpki-trust-anchors # This is a comment allow 10.0.0.0/8 # comments may follow entries allow 192.168.0.0/12 deny 192.168.1.0/24 # carve a hole in the above entry allow 192.0.2.0/24 allow 100.64.0.0 - 100.127.255.254 # this is a range allow 203.0.113.0 - 203.0.113.255 # this too allow 3fff::/20 # IPv6 is also supported deny 3fff::/48 deny 2001:db8:: - 2001:db8::ffff # an IPv6 range # From https://www.iana.org/assignments/as-numbers/ allow 64496 - 64511 deny 64500 # carve a hole in the above entry allow 65536 # can declare for single ASN deny 4200000000 - 4294967294 # There is an implicit deny for all resources which were not # explicitly allowed through 'allow' declarations. <CODE ENDS>¶
The RP must consider any deviation from the constraints configuration format specified above to be an error. If a constraints file contains an error, the RP must reject the entire constraints file and must not check EE certificates against it.¶
The following rules also apply to constraints entries:¶
There is an implicit deny for all resources that are not explicitly permitted by an allow entry. In other words, the set of resources allowed by a constraints file is the union of the resources specified by all allow entries, excluding the union of the resources specified by all deny entries.¶
When assessing the feasibility of constraining a Trust Anchor's effective signing abilities to the registry's current set of holdings, it is important to take note of existing policies (or lack thereof) and possible future events which might impact the degree of churn in the registry's holdings. Examples of these considerations are provided in Appendix B.¶
While there are sound reasons to declare 'all resources' as subordinate ([I-D.rir-rpki-allres-ta-app-statement]), there are resources which would never be subordinate to any particular Regional Internet Registry in the normal course of operations. Maintainers of configuration files containing constraints distributed as part of an operating system or a third-party software package release process would do well to assume a six month delay for users to update.¶
The routing security benefits promised by the RPKI are derived from assuming trust in registry operators to run flawless certification services. Assuming such trust exposes users to some potential for [risks] and adverse actions by Certificate Authorities [RFC8211]. Restricting a Trust Anchor's effective signing abilities to its respective registry's current holdings - rather assuming unbounded trust in such authorities - is a constructive approach to limit some potential for risk.¶
This document has no IANA actions.¶
This section is to be removed before publishing as an RFC.¶
This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in RFC 7942. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.¶
According to RFC 7942, "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".¶
The above three implementations were tested to produce the same outcomes for the same [fixtures] from the OpenBSD project.¶
The ARIN policy development community abandoned a proposal to allow inter-regional IPv6 resource transfers [ARIN-2019-4]. Since it's currently not possible to transfer IPv6 resources from ARIN to any other RIR, ARIN's IANA-allocated IPv6 resources should not appear subordinate to any Trust Anchor other than ARIN's own Trust Anchor.¶
The APNIC policy development community has not developed policy [APNIC-interrir] to support inter-RIR IPv6 transfers.¶
The LACNIC policy development community has not developed policy [LACNIC-interrir] to support inter-RIR IPv6 or ASN transfers.¶
The RIPE NCC policy development community did develop policy [RIPE-interrir] to support inter-RIR IPv6 transfers, but being the only community to have done so, inter-RIR transfers are not possible.¶
AFRINIC ratified an inter-registry transfer policy [AFPUB-2020-GEN-006-DRAFT03] in February 2026. The policy does not support inter-RIR IPv6 transfers and stipulates that AFRINIC-issued IPv4 resources cannot be transferred out of the region. The staff assessment indicates that implementation is expected to take 12 months.¶
The RIRs collectively manage only a subset of 0.0.0.0/0 [IANA-IPV4] and 2000::/3 [IANA-IPV6]; and have no authority over any parts of 10.0.0.0/8 [RFC1918], 2001:db8::/32 [RFC3849], and AS 64512 - 65534 [RFC6996], for example. Since it's not possible to transfer private internet allocations, documentation prefixes, or private use ASNs into an RIR's management, such resources should not appear subordinate to any RIR's Trust Anchor.¶
In recent times IANA has not made allocations from the Current Recovered IPv4 Pool [IANA-RECOVERED], and Autonomous System Number allocations are also fairly infrequent [IANA-ASNS].¶
Thanks to Niels Bakker, Joel Jaeggli, Tony Tauber, Tom Scholl, Erik Bais, Simon Leinen, and Nick Hilliard for their feedback and input.¶