



Network Working Group                                        J. Snijders
Internet-Draft                                                       BSD
Intended status: Standards Track                              T. Buehler
Expires: 7 August 2026                                           OpenBSD
                                                         3 February 2026


                    Constraining RPKI Trust Anchors
         draft-ietf-sidrops-constraining-rpki-trust-anchors-00

Abstract

   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.

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 7 August 2026.

Copyright Notice

   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



Snijders & Buehler        Expires 7 August 2026                 [Page 1]

Internet-Draft       Constraining RPKI Trust Anchors       February 2026


   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Required Reading  . . . . . . . . . . . . . . . . . . . .   3
   2.  Considerations on Trust Anchor over-claiming  . . . . . . . .   3
   3.  Constraining Trust Anchors by constraining End-Entity
           Certificates  . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Constraints Configuration Format  . . . . . . . . . . . . . .   5
   5.  Operational Considerations  . . . . . . . . . . . . . . . . .   5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     7.1.  Informative References  . . . . . . . . . . . . . . . . .   7
   Appendix A.  Implementation Status  . . . . . . . . . . . . . . .  11
   Appendix B.  Constraints applicable to an Example Trust Anchor  .  11
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

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.






Snijders & Buehler        Expires 7 August 2026                 [Page 2]

Internet-Draft       Constraining RPKI Trust Anchors       February 2026


1.1.  Definitions

   Assumed Trust  In the RPKI hierarchical structure, a Trust Anchor is
      an authority for which trust is assumed and not derived.  Assumed
      trust means that violation of that trust is out-of-scope for the
      threat model.

   Derived Trust  Derived Trust can be automatically and securely
      computed with subjective logic.  In the context of the RPKI, trust
      is derived according to the rules for validation of RPKI
      Certificates and Signed Objects.

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

1.2.  Required Reading

   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 and sign RPKI Trust Anchor constraints is
   specified in [I-D.nro-sidrops-ta-constraints].  Such signed
   distributed constraints can serve as an input to the methodology
   specified in this document.

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.












Snijders & Buehler        Expires 7 August 2026                 [Page 3]

Internet-Draft       Constraining RPKI Trust Anchors       February 2026


   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



Snijders & Buehler        Expires 7 August 2026                 [Page 4]

Internet-Draft       Constraining RPKI Trust Anchors       February 2026


   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.  Constraints Configuration Format

   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.

   An example is available in Appendix B.

5.  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:




Snijders & Buehler        Expires 7 August 2026                 [Page 5]

Internet-Draft       Constraining RPKI Trust Anchors       February 2026


   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 has not ratified an inter-registry transfer policy
   [AFPUB-2020-GEN-006-DRAFT03].  The policy proposal indicates
   implementation is expected to take an additional 12 months after
   ratification.  Since it's not possible to transfer resources into
   AFRINIC, non-AFRINIC resources should not appear subordinate to
   AFRINIC's Trust Anchor for the foreseeable future.

   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.







Snijders & Buehler        Expires 7 August 2026                 [Page 6]

Internet-Draft       Constraining RPKI Trust Anchors       February 2026


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

7.  References

7.1.  Informative References

   [AFPUB-2020-GEN-006-DRAFT03]
              Ehoumi, G. O., Maina, N., and A. A. P. Aina, "AFRINIC
              Number Resources Transfer Policy (Draft-3)", February
              2022,
              <https://afrinic.net/policy/proposals/2020-gen-006-d3>.

   [APNIC-interrir]
              APNIC, "Transfer of unused IPv4 addresses and/or AS
              numbers", 2023, <https://www.apnic.net/manage-ip/manage-
              resources/transfer-resources/transfer-of-unused-ip-and-as-
              numbers/>.

   [ARIN-2019-4]
              Snijders, J., Farmer, D., and J. Provo, "Draft Policy
              ARIN-2019-4: Allow Inter-regional IPv6 Resource
              Transfers", September 2019,
              <https://www.arin.net/vault/policy/proposals/2019_4.html>.

   [AS0TAL]   APNIC, "Important notes on the APNIC AS0 ROA", 2023,
              <https://www.apnic.net/community/security/resource-
              certification/apnic-limitations-of-liability-for-rpki-2/>.

   [I-D.ietf-sidrops-aspa-profile]
              Azimov, A., Uskov, E., Bush, R., Snijders, J., Housley,
              R., and B. Maddison, "A Profile for Autonomous System
              Provider Authorization", Work in Progress, Internet-Draft,
              draft-ietf-sidrops-aspa-profile-21, 16 January 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
              aspa-profile-21>.

   [I-D.nro-sidrops-ta-constraints]
              Harrison, T., Bruijnzeels, T., Martinez-Cagnazzo, C.,
              Kosters, M., and Y. Chadee, "RPKI Trust Anchor



Snijders & Buehler        Expires 7 August 2026                 [Page 7]

Internet-Draft       Constraining RPKI Trust Anchors       February 2026


              Constraints", Work in Progress, Internet-Draft, draft-nro-
              sidrops-ta-constraints-00, 20 October 2025,
              <https://datatracker.ietf.org/doc/html/draft-nro-sidrops-
              ta-constraints-00>.

   [I-D.rir-rpki-allres-ta-app-statement]
              Newton, A., Martínez, C. M., Shaw, D., Bruijnzeels, T.,
              and B. Ellacott, "RPKI Multiple "All Resources" Trust
              Anchors Applicability Statement", Work in Progress,
              Internet-Draft, draft-rir-rpki-allres-ta-app-statement-02,
              18 July 2017, <https://datatracker.ietf.org/doc/html/
              draft-rir-rpki-allres-ta-app-statement-02>.

   [IANA-ASNS]
              IANA, "Autonomous System (AS) Numbers", August 2023,
              <https://www.iana.org/assignments/as-numbers/>.

   [IANA-IPV4]
              IANA, "IANA IPv4 Address Space Registry", July 2023,
              <https://www.iana.org/assignments/ipv4-address-space/>.

   [IANA-IPV6]
              IANA, "IPv6 Global Unicast Address Assignments", November
              2019, <https://www.iana.org/assignments/ipv6-unicast-
              address-assignments/>.

   [IANA-RECOVERED]
              IANA, "IPv4 Recovered Address Space", March 2019,
              <https://www.iana.org/assignments/ipv4-recovered-address-
              space/>.

   [LACNIC-interrir]
              LACNIC, "LACNIC POLICY MANUAL (v2.19 - 22/08/2023)",
              August 2023,
              <https://www.lacnic.net/innovaportal/file/680/1/manual-
              politicas-en-2-19.pdf>.

   [OTE]      ARIN, "Operational Test and Evaluation (OT&E)
              Environment", 2023,
              <https://www.arin.net/reference/tools/testing/>.

   [PRIVSEP]  Obser, F., "Privilege drop, privilege separation, and
              restricted-service operating mode in OpenBSD",
              <https://sha256.net/privsep.html>.







Snijders & Buehler        Expires 7 August 2026                 [Page 8]

Internet-Draft       Constraining RPKI Trust Anchors       February 2026


   [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
              J., and E. Lear, "Address Allocation for Private
              Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
              February 1996, <https://www.rfc-editor.org/info/rfc1918>.

   [RFC3779]  Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
              Addresses and AS Identifiers", RFC 3779,
              DOI 10.17487/RFC3779, June 2004,
              <https://www.rfc-editor.org/info/rfc3779>.

   [RFC3849]  Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
              Reserved for Documentation", RFC 3849,
              DOI 10.17487/RFC3849, July 2004,
              <https://www.rfc-editor.org/info/rfc3849>.

   [RFC6480]  Lepinski, M. and S. Kent, "An Infrastructure to Support
              Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
              February 2012, <https://www.rfc-editor.org/info/rfc6480>.

   [RFC6481]  Huston, G., Loomans, R., and G. Michaelson, "A Profile for
              Resource Certificate Repository Structure", RFC 6481,
              DOI 10.17487/RFC6481, February 2012,
              <https://www.rfc-editor.org/info/rfc6481>.

   [RFC6487]  Huston, G., Michaelson, G., and R. Loomans, "A Profile for
              X.509 PKIX Resource Certificates", RFC 6487,
              DOI 10.17487/RFC6487, February 2012,
              <https://www.rfc-editor.org/info/rfc6487>.

   [RFC6488]  Lepinski, M., Chi, A., and S. Kent, "Signed Object
              Template for the Resource Public Key Infrastructure
              (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012,
              <https://www.rfc-editor.org/info/rfc6488>.

   [RFC6493]  Bush, R., "The Resource Public Key Infrastructure (RPKI)
              Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493,
              February 2012, <https://www.rfc-editor.org/info/rfc6493>.

   [RFC6996]  Mitchell, J., "Autonomous System (AS) Reservation for
              Private Use", BCP 6, RFC 6996, DOI 10.17487/RFC6996, July
              2013, <https://www.rfc-editor.org/info/rfc6996>.

   [RFC8209]  Reynolds, M., Turner, S., and S. Kent, "A Profile for
              BGPsec Router Certificates, Certificate Revocation Lists,
              and Certification Requests", RFC 8209,
              DOI 10.17487/RFC8209, September 2017,
              <https://www.rfc-editor.org/info/rfc8209>.




Snijders & Buehler        Expires 7 August 2026                 [Page 9]

Internet-Draft       Constraining RPKI Trust Anchors       February 2026


   [RFC8211]  Kent, S. and D. Ma, "Adverse Actions by a Certification
              Authority (CA) or Repository Manager in the Resource
              Public Key Infrastructure (RPKI)", RFC 8211,
              DOI 10.17487/RFC8211, September 2017,
              <https://www.rfc-editor.org/info/rfc8211>.

   [RFC9286]  Austein, R., Huston, G., Kent, S., and M. Lepinski,
              "Manifests for the Resource Public Key Infrastructure
              (RPKI)", RFC 9286, DOI 10.17487/RFC9286, June 2022,
              <https://www.rfc-editor.org/info/rfc9286>.

   [RFC9323]  Snijders, J., Harrison, T., and B. Maddison, "A Profile
              for RPKI Signed Checklists (RSCs)", RFC 9323,
              DOI 10.17487/RFC9323, November 2022,
              <https://www.rfc-editor.org/info/rfc9323>.

   [RFC9582]  Snijders, J., Maddison, B., Lepinski, M., Kong, D., and S.
              Kent, "A Profile for Route Origin Authorizations (ROAs)",
              RFC 9582, DOI 10.17487/RFC9582, May 2024,
              <https://www.rfc-editor.org/info/rfc9582>.

   [RFC9632]  Bush, R., Candela, M., Kumari, W., and R. Housley,
              "Finding and Using Geofeed Data", RFC 9632,
              DOI 10.17487/RFC9632, August 2024,
              <https://www.rfc-editor.org/info/rfc9632>.

   [RFC9691]  Martinez, C., Michaelson, G., Harrison, T., Bruijnzeels,
              T., and R. Austein, "A Profile for Resource Public Key
              Infrastructure (RPKI) Trust Anchor Keys (TAKs)", RFC 9691,
              DOI 10.17487/RFC9691, December 2024,
              <https://www.rfc-editor.org/info/rfc9691>.

   [RIPE-interrir]
              NCC, R., "Inter-RIR Transfers", February 2023,
              <https://www.ripe.net/manage-ips-and-asns/resource-
              transfers-and-mergers/inter-rir-transfers>.

   [risks]    Cooper, D., Heilman, E., Brogle, K., Reyzin, L., and S.
              Goldberg, "On the Risk of Misbehaving RPKI Authorities",
              <https://www.cs.bu.edu/~goldbe/papers/hotRPKI.pdf>.

   [rpki-client]
              Jeker, C., Snijders, J., Dzonsons, K., and T. Buehler,
              "rpki-client", July 2023, <https://www.rpki-client.org/>.







Snijders & Buehler        Expires 7 August 2026                [Page 10]

Internet-Draft       Constraining RPKI Trust Anchors       February 2026


Appendix A.  Implementation Status

   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 approach specified in this document has been implemented in
   [rpki-client] and has been enabled by default in releases since 2023.

Appendix B.  Constraints applicable to an Example Trust Anchor

   If the below content is placed in a file named *example.constraints*
   next to a Trust Anchor Locator file named *example.tal*, the
   [rpki-client] implementation will only accept an End-Entity
   certificate subordinate to *example.tal* if all its resources are
   fully contained within the resources allowed in
   *example.constraints*.
















Snijders & Buehler        Expires 7 August 2026                [Page 11]

Internet-Draft       Constraining RPKI Trust Anchors       February 2026


   # Example constraints following the format described in
   # draft-snij-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

   Job Snijders
   BSD Software Development
   Amsterdam
   Netherlands
   Email: job@bsd.nl
   URI:   https://www.bsd.nl/







Snijders & Buehler        Expires 7 August 2026                [Page 12]

Internet-Draft       Constraining RPKI Trust Anchors       February 2026


   Theo Buehler
   OpenBSD
   Switzerland
   Email: tb@openbsd.org















































Snijders & Buehler        Expires 7 August 2026                [Page 13]
