Constraining RPKI Trust Anchors

Status of This Memo

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 18 April 2026.¶

Copyright Notice

Copyright (c) 2025 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.¶

Table of Contents

1. Introduction

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 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 body of knowledge to be communicated within the global Internet routing system community.¶

2. Considerations on Trust Anchor over-claiming

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 [I-D.rir-rpki-allres-ta-app-statement]. 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 ASNs 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.¶

3. Constraining Trust Anchors by constraining End-Entity Certificates

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 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 and consider 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], RSCs [RFC9323], and Geofeeds [RFC9632].¶

The approach has no application in context of Signed Objects unrelated to INRs (which thus use 'inherit' elements); such as Ghostbusters records [RFC6493], 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.¶

4. Operational Considerations

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 are:¶

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].¶

It is clear from the aforementioned observations that, 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 Constraint lists disseminated 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.¶

5. Security Considerations

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.¶

Appendix A. Example listing of Constraints

This section contains an example Constraints listing.¶

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). Denylist entries (entries prefixed with deny) take precedence over allowlist entries (entries prefixed with allow). Denylist entries may not overlap with other denylist entries. Allowlist entries may not overlap with other allowlist entries. The ordering of entries is not significant.¶

# Example constraints following the format described in
# fdraft-spaghetti-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 65123           # 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.

Acknowledgements

Thanks to Niels Bakker, Joel Jaeggli, Tony Tauber, Tom Scholl, Erik Bais, Simon Leinen, and Nick Hilliard for their feedback and input.¶

Authors' Addresses