Route Origin Authorization via Protected Delegation of Internet Number Resources
draft-gersch-sidrops-sovereign-roots-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Joseph Gersch | ||
| Last updated | 2026-09-18 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-gersch-sidrops-sovereign-roots-00
SIDR Operations J. Gersch
Internet-Draft Invykta LLC
Intended status: Experimental 18 September 2026
Expires: 22 March 2027
Route Origin Authorization via Protected Delegation of Internet Number
Resources
draft-gersch-sidrops-sovereign-roots-00
Abstract
The Resource Public Key Infrastructure (RPKI) provides cryptographic
route-origin authorization, but its hierarchical authority model does
not provide a way for a superior authority to permanently divest
itself of control over a delegated resource. Even after delegation,
superior authority remains part of the authorization hierarchy. This
document explores a different property: an address-space holder may
elect a protected delegation boundary beyond which superior
authorities can no longer reclaim the resource, suppress the holder's
effective origin authorizations, or create competing allocation or
route-origin authority.
The document specifies a hierarchical IPv4 and IPv6 resource registry
that enforces this property at the state-transition boundary and
derives Validated ROA Payloads (VRPs) for conventional Route Origin
Validation (ROV). It also defines conflict and precedence rules that
permit protected resources to coexist with RPKI-derived authority
while leaving routers and the RPKI itself unchanged. The mechanism
can provide origin authorization for resources not currently
protected by RPKI, including legacy resources, but does not depend on
such resources remaining outside RPKI. It is intended for
experimental deployment alongside RPKI rather than as a replacement
for RPKI or the Regional Internet Registry system.
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/.
Gersch Expires 22 March 2027 [Page 1]
Internet-Draft Protected Delegation September 2026
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 22 March 2027.
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
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Observed Coverage Gap . . . . . . . . . . . . . . . . . . 6
3.2. Legacy Resources and Contractual Mechanisms . . . . . . . 7
3.3. Design Goals . . . . . . . . . . . . . . . . . . . . . . 7
4. Hierarchical Resource Registry Model . . . . . . . . . . . . 8
4.1. Canonical Prefix Representation . . . . . . . . . . . . . 9
4.2. Origin Authorizations . . . . . . . . . . . . . . . . . . 9
4.3. Controlling Principals and Authentication of Writes . . . 10
5. Protected Delegations . . . . . . . . . . . . . . . . . . . . 11
5.1. Provisional Protection Window . . . . . . . . . . . . . . 13
5.2. Nested and Partial Delegation . . . . . . . . . . . . . . 13
5.3. Holder-Controlled Recovery . . . . . . . . . . . . . . . 13
5.4. Who May Grant Protection . . . . . . . . . . . . . . . . 14
6. Bounded Protected-Range Conflict Detection . . . . . . . . . 15
7. Provenance and Holder Confirmation . . . . . . . . . . . . . 16
8. Finality and Canonical State . . . . . . . . . . . . . . . . 16
9. Deriving VRPs and Route Origin Validation . . . . . . . . . . 17
10. Coexistence with RPKI . . . . . . . . . . . . . . . . . . . . 17
10.1. What Coexistence Claims, and What It Does Not . . . . . 18
10.2. Protected-Range Precedence . . . . . . . . . . . . . . . 19
10.3. Outside Protected Ranges . . . . . . . . . . . . . . . . 19
Gersch Expires 22 March 2027 [Page 2]
Internet-Draft Protected Delegation September 2026
10.4. Why Plain Union Is Insufficient . . . . . . . . . . . . 19
10.5. Conveying Protected Ranges to Relying Parties . . . . . 20
10.6. Trust Conveyed by a Filter Artifact . . . . . . . . . . 21
10.7. Incremental Deployment . . . . . . . . . . . . . . . . . 21
11. Trust, Governance, and Upgradeability . . . . . . . . . . . . 21
12. Transfers, Re-parenting, and Ordinary Recovery . . . . . . . 22
13. Availability and Replication . . . . . . . . . . . . . . . . 22
14. Implementation Considerations . . . . . . . . . . . . . . . . 23
15. Security Considerations . . . . . . . . . . . . . . . . . . . 23
16. Operational Considerations . . . . . . . . . . . . . . . . . 24
17. Implementation Status . . . . . . . . . . . . . . . . . . . . 25
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
19. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25
20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
21. Normative References . . . . . . . . . . . . . . . . . . . . 25
22. Informative References . . . . . . . . . . . . . . . . . . . 26
Appendix A. Comparison with Alternative Approaches . . . . . . . 27
A.1. A Relying-Party Precedence Rule . . . . . . . . . . . . . 27
A.2. A Separate Trust Anchor for the Holder . . . . . . . . . 28
A.3. Locally Configured Trust Anchor Constraints . . . . . . . 29
Appendix B. Conformance Vectors for the Enumeration Bound . . . 30
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction
The Resource Public Key Infrastructure (RPKI) [RFC6480] provides a
widely deployed mechanism for binding Internet number resources to
route-origin authorizations. Its hierarchical certificate model
intentionally permits an issuing authority to remain an authority
over resources delegated below it. A superior authority can
therefore revoke or allow a subordinate certificate to expire, and
the certificate hierarchy does not express that the superior
authority has permanently divested itself of the delegated resource.
For many deployments this is an appropriate operational model.
Contractual, policy, and registry mechanisms can also reduce the
practical risk of superior-authority action. This document addresses
a narrower technical question: how can an address-space holder elect
a delegation for which superior revocation and conflicting issuance
are no longer capabilities of the authorization system itself?
The mechanism specified here, referred to as a protected delegation,
records the delegation in a replicated, cryptographically authorized
state machine. Once the protection has become irreversible, the
state-transition rules refuse conflicting allocation and origin-
authorization writes from outside the protected subtree, refuse
superior recovery of the protected allocation, and terminate
authority traversal at the protected boundary. The holder remains
Gersch Expires 22 March 2027 [Page 3]
Internet-Draft Protected Delegation September 2026
able to suballocate, authorize route origins, transfer control, and
voluntarily release the resource according to the rules of the
registry.
The same state model is also a hierarchical IPv4 and IPv6 resource
registry. Each allocation identifies an address prefix, a
controlling principal, and a delegating parent. Suballocations form
a containment-constrained hierarchy. Transfers of control and
changes of delegation are authenticated state transitions. The term
controlling principal is used deliberately: a protocol-level control
record does not by itself assert legal title to an Internet number
resource.
The initial deployment objective is coexistence with RPKI. Routers
continue to consume ordinary VRPs over RTR and perform ordinary ROV.
A Protected-Registry-Aware Consumer derives VRPs from protected state
that is in Final State and Confirmed State and applies explicit
source-precedence rules before exporting a single VRP set to routers.
1.1. Scope
This document specifies origin authorization and hierarchical
address-resource delegation. It does not authenticate the BGP
AS_PATH, secure packet forwarding, replace ASPA or BGPsec, allocate
Autonomous System Numbers, or define legal ownership of number
resources.
1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Terminology
* Allocation: a registry record identifying an IPv4 or IPv6 prefix,
its controlling principal, its delegating parent, and its
operational state.
* Controlling Principal: the account recorded against an allocation
as holding write authority over it, identified by the credential
or set of credentials that the registry verifies when a write to
that allocation is attempted. Section 4.3 specifies how writes
are authenticated against it. This term does not imply legal
ownership.
Gersch Expires 22 March 2027 [Page 4]
Internet-Draft Protected Delegation September 2026
* Protected Delegation: an allocation for which the protocol has
divested superior authorities of specified capabilities, including
reclaim, conflicting issuance, and validity suppression from
above.
* Protected Range: the IPv4 or IPv6 prefix of a Protected
Delegation.
* Protected Subtree: the Protected Delegation and allocations
validly delegated beneath it.
* Ordinary Delegation: an allocation for which the parent retains
normal recovery and hierarchical validity authority.
* Route-Origin Authorization (ROA): in this document, and except
where the term is qualified as "RPKI ROA", a registry
authorization tuple consisting of an issuing allocation, prefix,
maximum length, and origin AS. It is conceptually equivalent to
the origin-authorization content that produces an RPKI VRP, but is
not an [RFC9582] CMS object.
* VRP: a tuple of prefix, maximum length, and origin AS consumed by
ROV.
* Asserted State: registry authority derived from an external
source, such as an RIR, RDAP, WHOIS or RPKI import, that the named
controlling principal has not yet exercised or attested.
* Confirmed State: registry authority that has been
cryptographically exercised or attested by the controlling
principal, rather than merely imported or asserted by a registry
operator.
* Final State: registry state that satisfies the deployment's
explicit consensus finality rule and is therefore eligible to
influence exported routing authority. This term concerns
consensus finality only. A Protected Delegation that is in Final
State may still be within the provisional interval of Section 5.1,
during which the grantor can reverse it.
* Authority Traversal Boundary: a Protected Delegation at which
validation ceases to depend on ancestors above that allocation.
* Protected-Registry-Aware Consumer: a relying-party or aggregation
component that validates registry state, applies protected-range
conflict semantics, and exports VRPs.
Gersch Expires 22 March 2027 [Page 5]
Internet-Draft Protected Delegation September 2026
3. Problem Statement
A conventional hierarchical delegation establishes that a child is
authorized by a parent; it does not necessarily remove the parent's
authority over the same resource. In RPKI, resource certificate
validation establishes resource containment through a certification
path [RFC3779]. A parent can cease to validate a subordinate path,
and the hierarchy can contain other authorizations over resources
that numerically overlap a subordinate allocation.
This document does not assume that superior authorities will misuse
those capabilities. The problem is structural rather than an
allegation about registry behavior. Some resource holders or
deployments may require a technical property stronger than
contractual non-interference: after an elective protected delegation
becomes irreversible, the authorization system itself must no longer
accept superior actions that recreate authority inside the protected
range or make the holder's valid state depend on an ancestor above
the protected boundary.
A second problem arises during coexistence. A simple union of VRPs
from independent authority systems can authorize two conflicting
origins simultaneously. Therefore a second source of origin
authority is not safe merely because it can emit syntactically valid
VRPs; the consuming system needs deterministic source-precedence
semantics.
3.1. Observed Coverage Gap
Route-origin authorization coverage is not uniform across the address
space. The following measurements were taken on 23 August 2026
against public RPKI repositories and public BGP data, and are
reproducible from those sources.
* 1,525 prefixes within Apple's legacy /8 allocation were announced
from AS714. No RPKI ROA covered any of them, so every such
announcement evaluates as NotFound under [RFC6811].
* The United States Department of Defense legacy /8 allocations
carried 4,325 announced routes covering approximately 218 million
addresses, with no RPKI coverage.
Gersch Expires 22 March 2027 [Page 6]
Internet-Draft Protected Delegation September 2026
* Within that uncovered space, one /24 was announced from AS27651,
an autonomous system registered in Chile, and four prefixes within
another Department of Defense legacy /8 were announced from
AS64140, an autonomous system registered in Colombia. Because no
covering RPKI ROA exists for that space, origin validation
classifies these announcements identically to any other
announcement within it.
These figures are stated as measurements of origin-validation
coverage. This document does not assert why any particular holder
has or has not published RPKI ROAs, and does not characterise the
conduct of any registry or holder. The measurements establish only
that a substantial quantity of address space remains outside origin-
validation coverage, and that announcements within such space cannot
be distinguished by [RFC6811] from announcements made by the
registered holder.
3.2. Legacy Resources and Contractual Mechanisms
Legacy address resources are a motivating deployment case, but the
protocol does not depend on any claim that a particular contract,
including a legacy registration services agreement, is inadequate.
Contractual protections and protocol-enforced divestiture address
different layers. A holder may consider contractual protection
sufficient; another may require that superior authority be absent
from the technical state machine. Registration agreements are also
revised over time, and a holder's assessment of them may change
accordingly; the population for which the contractual layer is
insufficient is therefore not fixed. The mechanism is elective.
3.3. Design Goals
* Preserve existing router-side ROV and RTR behavior.
* Represent IPv4 and IPv6 allocation, suballocation, control, and
route-origin authority as first-class registry state.
* Permit ordinary hierarchical delegations and elective Protected
Delegations in the same registry.
* Prevent both addition of conflicting authority and subtraction of
protected-holder authority from above.
* Require holder-confirmed provenance before registry state can
influence routing.
* Provide deterministic coexistence with RPKI-derived VRPs.
Gersch Expires 22 March 2027 [Page 7]
Internet-Draft Protected Delegation September 2026
* Make finality, recovery, governance, and failure modes explicit.
4. Hierarchical Resource Registry Model
This section defines the minimum registry state model required to
express the protected-delegation invariant specified in Section 5.
It is not a proposal to replace the registry operations of the
Regional Internet Registries, and it does not define number-resource
allocation policy. Allocation policy remains the responsibility of
the registry system within which a deployment operates.
The authoritative registry is a replicated ordered state machine.
The replication technology is not itself the protocol objective; a
permissioned distributed ledger is one implementation because it
provides ordered multi-writer state, cryptographic write
authorization, deterministic execution, and an auditable history.
A registry operated as a conventional database can apply the same
admission rule and will reach the same refusals. What it does not
obtain are three properties that follow from replicated execution.
The rule is evaluated identically for every party, including the
operator of the registry itself. Its application to a particular
record is observable by parties other than the one that wrote the
record. The cost of evaluating it falls on the party attempting the
write rather than on the registry operator, so a registry does not
bear a cost that grows with the number of parties it constrains. The
separate property that the evaluation itself is bounded is a
consequence of Section 6, not of replication.
The first of these is why the choice of substrate is not merely
operational. A holder electing a Protected Delegation is
constraining the authority of a party that would, in a conventionally
operated registry, also be the party operating the registry and
applying the rule to itself. Replicated execution separates the two
roles. A deployment that does not separate them can still conform to
this specification, but it asks a protected holder to rely on the
continued good behaviour of the party whose capability the protection
is intended to remove.
The registry MUST support IPv4 and IPv6 allocations. Each allocation
MUST identify a canonical prefix, a controlling principal, a parent
allocation, an active/inactive state, and any expiration semantics
used by the deployment. A child allocation MUST be numerically
contained by its parent at the time the child is created or re-
parented, except for a distinguished virtual root used only to anchor
the registry.
Gersch Expires 22 March 2027 [Page 8]
Internet-Draft Protected Delegation September 2026
Two live allocations MUST NOT cover the same address space unless one
is an ancestor of the other in the delegation hierarchy. A
deployment that permits overlapping allocations that are not in an
ancestor-descendant relationship MUST define which allocation is
authoritative for origin authorization within the overlapping space.
Without such a rule the VRP derivation described in Section 9 admits
two independent authorities over the same prefix.
A parent controlling principal MAY create an Ordinary Delegation
within its resource. A controlling principal MAY create further
suballocations within its own allocation. Repeating this operation
represents a hierarchy such as IANA to RIR to ISP to organization to
customer, without requiring the protocol to assert that those
administrative roles must be occupied by particular institutions.
The registry MUST distinguish transfer of control from re-parenting.
A control transfer changes the controlling principal while preserving
the delegation parent. Re-parenting changes the delegation parent
and MUST require authorization sufficient to prevent unilateral
movement of a resource into another authority subtree.
The registry's 'owner' or equivalent implementation field identifies
protocol control. Implementations and user interfaces SHOULD
describe this as a controlling principal, holder, or controller
unless legal ownership is actually established by an external
process.
4.1. Canonical Prefix Representation
IPv4 and IPv6 prefixes MUST have a single canonical representation.
Host bits outside the prefix length MUST be zero. IPv4 and IPv6
identifier spaces MUST remain distinct even if represented in a
common fixed-width storage type.
4.2. Origin Authorizations
A controlling principal MAY create a route-origin authorization for a
prefix contained by its allocation. The authorization MUST include
an origin AS and maximum prefix length. The maximum length MUST be
no shorter than the authorized prefix and MUST NOT exceed the width
of the address family. AS 0 retains the semantics described by
[RFC6483]. The registry does not require the address holder to
control the origin AS; this follows the RPKI ROA model.
Gersch Expires 22 March 2027 [Page 9]
Internet-Draft Protected Delegation September 2026
4.3. Controlling Principals and Authentication of Writes
Control over an allocation is expressed as an account. An
implementation SHOULD support accounts that are threshold or multi-
signature and that permit credential rotation and recovery, so that
loss or compromise of a single credential does not imply
irrecoverable loss of the resource. This document does not mandate a
particular account scheme.
Every write to the registry MUST be authenticated against the account
recorded as the controlling principal of the affected allocation, and
MUST be refused otherwise. Write authority is therefore held in
exactly one place, and the rules of Section 5 and Section 6 determine
what that authority may do. A conforming registry provides no second
path by which a record may be created or altered.
Authority under this document is proven when a record is written and
is not carried by the record afterwards. This differs from RPKI and
the difference should be stated rather than inferred. An RPKI ROA is
a signed object that a relying party verifies offline against a
certification path, long after issuance and without trusting the
party that supplied it. A record in this registry is authenticated
when it is written; a consumer that reads registry state directly, or
that operates a node, re-executes that check. A consumer that reads
only an exported VRP set does not, and is therefore trusting the
exporter: the export carries no signature of the holder's, and this
document defines none. A consumer that requires proof rather than
trust MUST obtain it from registry state, by operating a node or by
verifying a proof of inclusion against a committed state root.
Where a protected holder holds a Protected Delegation for which no
recovery policy is in force, loss of the controlling credentials is
unrecoverable. Section 5.3 requires a recovery policy to be recorded
before protection becomes irreversible, so a conforming deployment
does not produce this state; it is described here because it is the
consequence the requirement exists to prevent, and because a
deployment that relaxes the requirement will produce it. This
follows from the guarantee rather than from an oversight: no ancestor
may reclaim an irreversible Protected Delegation, so no ancestor can
reassign it to a holder that has lost its credentials. The
allocation persists and its authorizations continue to be served
while they remain valid. When they lapse nothing replaces them,
because only the holder may create an authorization, release the
allocation, or delegate it further. The range is thereafter neither
usable nor recoverable by any party.
Gersch Expires 22 March 2027 [Page 10]
Internet-Draft Protected Delegation September 2026
A deployment MUST make this consequence plain to a holder before
protection is granted, and SHOULD treat the provisional interval of
Section 5.1 as the last point at which a holder can reconsider.
Implementations MUST NOT offer single-credential control of a
Protected Delegation, and SHOULD make threshold accounts with
rotation and recovery the default rather than an option.
5. Protected Delegations
A Protected Delegation is an elective state transition that removes
specified superior-authority capabilities for one address range.
Protection becomes irreversible only after the delegation has reached
Final State, has been confirmed under Section 7, and any provisional
interval under Section 5.1 has elapsed. These are three separate
conditions and all of them apply.
A conforming implementation MUST enforce the protected-delegation
invariant at write time. For a candidate allocation or route-origin
authorization whose effective scope intersects a live Protected
Range, the write MUST be refused unless the candidate authority
originates within the corresponding Protected Subtree and the
candidate operation is authorized by the controlling principal or a
valid delegate in that subtree.
The invariant applies to both allocations and origin authorizations.
Applying it to only one leaves a path for a superior authority to
recreate the other form of authority.
A superior authority MUST NOT be able to recover or transfer an
irreversible Protected Delegation to itself merely by virtue of being
its former or numerical ancestor. The protected holder MAY transfer
control, establish holder-controlled recovery, suballocate, and
voluntarily release the resource.
When validating state below a Protected Delegation, authority
traversal MUST terminate at that Protected Delegation for
capabilities protected by this specification. The Protected
Delegation is therefore the Authority Traversal Boundary for
everything delegated beneath it. Expiration, suspension, removal, or
other state changes in ancestors above the boundary MUST NOT
invalidate otherwise valid protected-holder origin authority.
These rules jointly deny two distinct capabilities: addition of
competing authority from above and subtraction of the holder's
authority through ancestor state changes.
Gersch Expires 22 March 2027 [Page 11]
Internet-Draft Protected Delegation September 2026
The necessity of denying both capabilities can be shown by applying
[RFC6811] at each step of a sequence available to an ancestor.
Consider a holder announcing 192.0.2.128/25 from AS64496 under a
covering authorization for 192.0.2.0/24 to AS64496 with a maximum
length of 25, issued under the ordinary hierarchy.
+=========================+=======================+==========+
| Step | Covering VRPs | Verdict |
+=========================+=======================+==========+
| 1. Holder publishes | 192.0.2.0/24, | Valid |
| its authorization | AS64496, maxLength 25 | |
+-------------------------+-----------------------+----------+
| 2. Ancestor withdraws | none | NotFound |
| the holder's authority | | |
+-------------------------+-----------------------+----------+
| 3. Ancestor authorizes | 192.0.2.0/24, AS 0, | Invalid |
| 192.0.2.0/24 to AS 0 | maxLength 25 | |
+-------------------------+-----------------------+----------+
Table 1: Effect of each ancestor action under RFC 6811
Step 2 alone does not remove the route. The holder's authorization
ceases to contribute a VRP, so the announcement reverts to NotFound,
an outcome that relying parties and routers predominantly still
accept. Withdrawal removes the holder's protection rather than its
reachability.
Step 3 removes the route. With none of the holder's VRPs remaining,
the ancestor's authorization over the same range is uncontradicted,
and every announcement it covers evaluates as Invalid. An AS 0
authorization [RFC6483] is the most direct form. It is not the only
one: an authorization naming the holder's own origin AS with a
maximum length shorter than the holder's announcements produces the
same verdict and is indistinguishable from a common misconfiguration.
The order is material. Performing step 3 without step 2 leaves both
authorizations covering the announcement, and because [RFC6811]
treats an announcement as Valid when any covering VRP authorizes it,
the route remains Valid. This is what distinguishes an ancestor from
an unrelated party. An unrelated party can only add an
authorization, which any-match neutralises. Only an ancestor can
remove the holder's own.
A Protected Delegation denies the two steps by different means. Step
2 has no counterpart, because an allocation is removable only by its
own controlling principal and there is no ancestor-side withdrawal to
perform. Step 3 is refused when the record is written, so the
conflicting authorization never reaches the VRP set. The protected
Gersch Expires 22 March 2027 [Page 12]
Internet-Draft Protected Delegation September 2026
holder's authorizations therefore survive both the deactivation of
every ancestor above the protected boundary and any attempt by an
ancestor to record authority over the same range.
5.1. Provisional Protection Window
A deployment MAY provide a bounded provisional interval after
creation of a Protected Delegation during which the grantor can
correct an erroneous grant. If such an interval exists, its duration
and semantics MUST be part of the public registry rules. After the
interval expires, superior recovery MUST be refused. The elapse of
this interval is a separate condition from Final State, which
concerns consensus finality alone.
5.2. Nested and Partial Delegation
A Protected Delegation MAY contain Ordinary Delegations or further
Protected Delegations. The same write-time invariant applies
recursively. A holder MAY delegate only part of its range while
retaining control of the remainder. No child protection can grant
authority outside the parent's resource.
5.3. Holder-Controlled Recovery
Protection from superior recovery MUST NOT be interpreted as a
requirement for unrecoverable single-key control. Deployments MUST
support holder-controlled recovery, by mechanisms such as threshold
multisignature, pre-authorized recovery principals, signer rotation,
or successor-transfer procedures. Such recovery MUST be established
by the protected holder and MUST NOT restore a unilateral recovery
capability to an ancestor unless the holder explicitly authorized
that capability.
A Protected Delegation MUST NOT become irreversible unless a recovery
policy for it has been recorded. The policy identifies the
credentials, threshold, approvers or successor by which control can
be re-established, and it is recorded as registry state before the
protection becomes irreversible, so that a consumer or a subsequent
holder can determine from the record that a path exists. A
deployment MUST refuse the transition to irreversible protection
where no such policy is present.
The purpose of this requirement is to bound the consequence described
in Section 4.3 without returning any capability to an ancestor. A
recovery policy makes credential loss recoverable by a party the
holder selected; it does not make the resource reclaimable by the
party whose authority the protection removed. These are different
outcomes and this specification permits only the first.
Gersch Expires 22 March 2027 [Page 13]
Internet-Draft Protected Delegation September 2026
A recovery policy MAY include a succession condition that is
triggered by holder inactivity. In one form, the holder records a
successor together with an interval, and where no operation
authorized by the holder is recorded for that resource within the
interval, the successor becomes able to assume control. The interval
and the successor are fixed when the policy is recorded, and the
successor MUST NOT be an ancestor of the Protected Delegation unless
the holder named that ancestor expressly. A succession condition is
evaluated from recorded registry state and MUST NOT depend on an
assertion made by any party at the time the condition is exercised.
A deployment MAY permit a holder to record, at the time protection is
elected, a bounded term after which the protection lapses. Where
such a term is recorded it is a property of the holder's election,
evaluated from recorded state. A deployment MUST NOT impose a term,
a renewal requirement, or any other recurring action as a condition
of continued protection, because a protection that lapses unless
periodically renewed restores to the party controlling admission of
records the ability to end the protection by declining to admit the
renewal.
5.4. Who May Grant Protection
Protection is created by a state transition that some existing
authority must be able to make. In a deployment whose hierarchy is
rooted in an incumbent registry structure, the capability to grant a
Protected Delegation therefore rests initially with the operator of
the root, or with the holder of an ancestor allocation. This
specification does not remove that asymmetry, and it is structurally
similar to the condition described in Section 3: a party outside the
eventual protected boundary determines whether the boundary comes
into existence.
The asymmetry is bounded in one respect. A grant is exercised once
and, once the protection has become irreversible, cannot be revisited
by the granting authority, whereas a retained revocation capability
persists for the lifetime of the delegation. The two are therefore
not equivalent in duration, even though both originate with a
superior party.
A deployment MUST state which principals may grant Protected
Delegations. A deployment MUST also state whether any path exists by
which a holder can obtain protection without the cooperation of an
ancestor or root operator. A deployment in which no such path exists
SHOULD state that explicitly, rather than describing the resulting
delegations as independent of superior authority without
qualification.
Gersch Expires 22 March 2027 [Page 14]
Internet-Draft Protected Delegation September 2026
6. Bounded Protected-Range Conflict Detection
An implementation MUST be able to determine whether a candidate
allocation or authorization intersects a Protected Range without
requiring work proportional to the total number of Protected
Delegations.
For prefix address spaces, one implementation maintains (1) a mapping
keyed by canonical prefix identifying an exact live Protected
Delegation and (2) a mapping keyed by canonical prefix summarizing
the number of live Protected Delegations strictly below that prefix.
Creation or removal updates the exact-prefix entry and the summaries
of strict ancestors. A candidate operation enumerates at most the
finite set of ancestor prefixes of the candidate and consults the
descendant summary at the candidate prefix. This bounds the prefix-
containment portion of the check by address-family bit depth rather
than protected-population size.
The two tests are exhaustive for prefix-structured identifiers,
because two prefixes that overlap are necessarily nested: a Protected
Range overlapping a candidate either contains the candidate or lies
strictly within it. An implementation that extends this approach to
an identifier space in which two resources may overlap partially
cannot rely on that property and MUST use a structure that detects
partial overlap directly.
The upward enumeration may be shortened. Where the requesting
holder's own resource contains the candidate, any Protected Range no
longer than the holder's resource also contains the holder's resource
and therefore cannot cause a refusal, so the enumeration may begin
one bit below the prefix length of the holder's resource. This
shortening is valid only while its premise holds. Where a registry
uses a distinguished virtual root whose resource is a placeholder
rather than a real prefix, a resource recorded directly beneath that
root is not contained by its holder's resource, and an implementation
MUST begin the enumeration at prefix length zero in that case. An
implementation that applies the shortening unconditionally can fail
to refuse a candidate in a different address family from the
Protected Range it should have matched.
Equivalent tries, interval structures, authenticated indexes,
bitmaps, or range indexes MAY be used if they enforce the same
invariant and provide bounded or otherwise operationally safe
evaluation.
A Boolean 'protected descendant exists' result is not sufficient for
every route-origin authorization. When maximum-length semantics
[RFC9319] cause an authorization's effective scope to cover more-
Gersch Expires 22 March 2027 [Page 15]
Internet-Draft Protected Delegation September 2026
specific prefixes, the index MUST return or permit retrieval of
enough information to determine semantic intersection, such as the
protected-prefix identity, depth, range endpoints, implicated-record
reference, or a verifiable conflict witness.
7. Provenance and Holder Confirmation
Imported registry data is not equivalent to holder-authorized state.
A deployment that seeds allocations from RIR, RDAP, WHOIS, RPKI, or
other external data is asserting what it believes the allocation
state to be; the named holder has not necessarily authorized the
corresponding registry principal.
Each allocation that can contribute routing authority MUST therefore
have a provenance state. At minimum, implementations MUST
distinguish Asserted State from Confirmed State. Asserted State is
externally derived and has not been cryptographically exercised by
the named controlling principal. Confirmed State has been attested
by an action of that principal or by an equivalent holder-
verification procedure defined by the deployment.
An authoritative VRP export produced under this document MUST contain
only Confirmed State. Asserted allocations MAY be exposed through a
separate diagnostic or onboarding interface, but MUST NOT influence
router ROV by default.
A deployment MUST publish the provenance of genesis or bulk-import
data, including source, date, derivation method, and responsible
importing authority. Cryptographic replication can prove what was
recorded and when; it cannot prove that an initial external assertion
was correct.
8. Finality and Canonical State
A VRP MUST NOT be exported merely because a transaction appeared in a
recent block or log entry. Each deployment MUST define an explicit
finality rule identifying the canonical state eligible to influence
routing.
The finality rule MUST specify how a consumer determines a finalized
checkpoint, how conflicting histories are detected or resolved, and
what a consumer does when finality cannot be established. A consumer
that cannot establish finality MUST retain its last known finalized
state or withdraw protected-registry-derived authority according to a
documented fail-safe policy; it MUST NOT silently select an arbitrary
competing history.
Gersch Expires 22 March 2027 [Page 16]
Internet-Draft Protected Delegation September 2026
A permissioned deployment MAY use a Byzantine-fault-tolerant or other
consensus protocol with deterministic finality. A chain with
probabilistic or operational finality MUST define a confirmation rule
and the residual reorganization risk. Terms such as 'effectively
final' are not sufficient for interoperable behavior.
Validator control and resource control are distinct. Validators
order and replicate authorized state transitions; they MUST NOT be
treated as resource holders merely because they participate in
consensus. A validator quorum can nevertheless censor, halt, or
equivocate depending on the consensus protocol, and these are
security properties of the deployment.
9. Deriving VRPs and Route Origin Validation
A Protected-Registry-Aware Consumer builds a validated view of
allocations and origin authorizations from Final, Confirmed State.
An authorization contributes a VRP only when its issuing allocation
is valid under the applicable authority traversal rules.
For Ordinary Delegations, the consumer validates the allocation chain
through its parent hierarchy, including active and expiration state.
For a Protected Delegation, traversal for protected capabilities
terminates at the protected boundary; state above that boundary
cannot suppress the protected holder's otherwise valid authorization.
The resulting tuple is an ordinary VRP: prefix, maximum length, and
origin AS. Router-side origin validation remains the ROV algorithm
[RFC6811] used for RPKI-derived VRPs. No new router validation state
is defined by this document.
A trie or other prefix index MAY be used to derive containing
allocations and covering origin authorizations. Such a structure is
a relying-party implementation choice and is not authoritative
registry state. Derived databases, caches, and tries MUST be
rebuildable from authoritative finalized state.
10. Coexistence with RPKI
The mechanism specified in this document is intended to coexist with
RPKI. The router-facing interface remains a VRP set delivered
through RTR [RFC8210] or another existing VRP distribution mechanism.
The router does not need to know the provenance of each VRP.
The relying-party or aggregation layer is not provenance-blind. It
MUST know which ranges are Protected Ranges and MUST apply the
conflict rules below before exporting a combined set. Therefore this
document does not claim that an arbitrary unmodified RP can safely
Gersch Expires 22 March 2027 [Page 17]
Internet-Draft Protected Delegation September 2026
concatenate the two sources. Existing RP and aggregation software
may be usable through configuration, SLURM, VRP-set aggregation and
relay tooling, or equivalent mechanisms, but a Protected-Registry-
Aware Consumer or equivalent aggregation step is required.
Operators that do not adopt the mechanism are unaffected. Adoption
of a Protected Range is also local to the consuming operator:
trusting a protected registry's root or feed is a deliberate relying-
party policy decision analogous in consequence, though not identical
in mechanism, to selecting a trust anchor.
10.1. What Coexistence Claims, and What It Does Not
This document describes the mechanism as coexisting with RPKI rather
than replacing it. That claim is made at the level of the system and
is not valid at the level of an individual prefix.
At the system level it holds without qualification. RPKI is
unmodified, no RPKI object is deprecated, no relying-party behaviour
is changed, no router sees anything new, and every resource whose
holder has not elected protection continues to derive its authority
from its existing registry exactly as before. No flag day and no
migration is required of anyone.
Within a Protected Range the relationship is different, and that
difference is the purpose of the range. A consumer applying the
precedence rules below is excluding RPKI-derived authority for that
range and using the protected registry's authority instead. For
those prefixes, and only those, the protected registry is
authoritative and RPKI is not. That relationship is substitutive
rather than complementary, and a deployment MUST NOT describe it
otherwise to a consumer that is being asked to apply protected-range
precedence.
Three properties bound what is substituted, and together they are why
the system-level statement survives the prefix-level one. The holder
elects, per range, and only for its own resources. The consumer
elects, per deployment, because the exclusion takes effect only where
protected-range precedence has been deliberately enabled. Outside
Protected Ranges the incumbent source is preferred, so the
substitution cannot spread through error.
Stated briefly: the mechanism is additive to RPKI as a system, and
authoritative in place of it for ranges that a holder has elected and
a consumer has agreed to honour.
Gersch Expires 22 March 2027 [Page 18]
Internet-Draft Protected Delegation September 2026
10.2. Protected-Range Precedence
Inside a Protected Range, the protected registry is authoritative for
origin authorization. Before combining sources, a conforming
consumer MUST ensure that no RPKI-derived VRP contributes origin
authorization for any prefix within a Protected Range, unless that
VRP was independently accepted under the protected registry's
authority. The effective scope calculation MUST account for both the
VRP prefix and its maximum length.
The exclusion MUST be scoped to the Protected Range. Where the
effective authorization scope of an RPKI-derived VRP covers prefixes
both inside and outside a Protected Range, a conforming consumer MUST
NOT discard that VRP in its entirety. The consumer MUST instead
suppress only the portion of the VRP's effective scope that falls
within the Protected Range, for example by emitting one or more
replacement VRPs covering the remaining scope, or by evaluating the
exclusion per candidate announcement rather than per VRP. Discarding
the entire VRP would withdraw origin authority from address space
that the Protected Delegation does not cover, and can cause
announcements outside the Protected Range that would otherwise
evaluate as Valid to evaluate as NotFound.
After this exclusion, only Final, Confirmed protected-registry
authority determines origin authorization inside that range.
10.3. Outside Protected Ranges
Outside all Protected Ranges, RPKI remains the preferred authority
source for ordinary RPKI-covered space. A default deployment SHOULD
export protected-registry-derived VRPs only for Protected Ranges
unless the operator has explicitly enabled an ordinary-registry
coexistence policy. An implementation that exports ordinary
protected-registry VRPs outside Protected Ranges MUST define
deterministic conflict handling and MUST NOT allow a plain union to
create unintended additional valid origins where the two sources
disagree.
10.4. Why Plain Union Is Insufficient
ROV considers an announcement Valid when at least one covering VRP
authorizes the origin and prefix length. Consequently, unioning two
conflicting authority sources can make both origins acceptable.
Protected-range precedence is therefore a security rule, not merely
an operator preference.
Gersch Expires 22 March 2027 [Page 19]
Internet-Draft Protected Delegation September 2026
10.5. Conveying Protected Ranges to Relying Parties
The precedence rule above requires a consumer to know which ranges
are Protected Ranges. A deployment SHOULD therefore publish,
alongside its VRP export, a filter artifact identifying the current
set of live Protected Ranges.
In one profile that artifact is a SLURM [RFC8416] file whose
validationOutputFilters.prefixFilters member contains one entry per
live Protected Range, giving the range as the prefix and omitting
asn, so that the entry matches every RPKI-derived payload covering
the range irrespective of origin. Authority for that range is then
supplied by the protected-registry export alone. A holder that
publishes in both systems is unaffected: filtering removes its RPKI-
derived payloads for the range and the protected-registry export
supplies equivalents.
Where this profile is used, the file MUST contain one entry in
validationOutputFilters.prefixFilters for each live Protected Range,
with asn absent. The file MUST NOT use locallyAddedAssertions,
because protected-registry authority is supplied by the VRP export
and not by SLURM assertions. Entries for ranges that are no longer
live MUST be removed rather than retained. The file SHOULD be
refreshed whenever the set of live Protected Ranges changes, and a
consumer SHOULD treat a stale filter artifact as it treats a stale
VRP set.
A consumer that does not implement this profile sees a syntactically
ordinary SLURM file and, if it loads the file at all, obtains the
intended exclusions. The profile constrains what a producer writes
and requires nothing of a consumer beyond [RFC8416] conformance.
This profile has a limitation that a deployment MUST account for. A
SLURM prefix filter removes payloads whose prefix lies within the
filter prefix. It therefore does not remove a less-specific RPKI-
derived payload whose authorization scope extends into a Protected
Range from outside it. That payload is precisely the case that
Section 10.2 requires to be suppressed in part rather than discarded,
so a deployment relying on prefix filters alone does not satisfy that
requirement. Such a deployment MUST either supply the scoped
replacement payloads described in Section 10.2 or use a conveyance
mechanism able to express partial suppression.
Gersch Expires 22 March 2027 [Page 20]
Internet-Draft Protected Delegation September 2026
10.6. Trust Conveyed by a Filter Artifact
Loading a filter artifact is a stronger act than loading additional
payloads, and a deployment MUST NOT present the two as equivalent.
Additional payloads can only move a route from NotFound toward Valid
or Invalid for resources that RPKI does not cover. A filter causes
RPKI-derived payloads to be discarded, so an erroneous or hostile
filter artifact can suppress legitimate RPKI authority for the range
it names, which is a denial of service against the incumbent system.
A consumer that loads the artifact is electing to treat the protected
holder's assertion as authoritative over the incumbent registry's for
that range. That election is local policy. This document specifies
the mechanism and the default; it does not require any consumer to
make that election.
10.7. Incremental Deployment
A deployment MAY expose its validated VRP set as JSON for existing
aggregation software, as SLURM [RFC8416] local assertions and
filters, or directly over RTR. These are deployment mechanisms
rather than new router protocols. A native consumer MAY instead read
and validate authoritative registry state directly.
11. Trust, Governance, and Upgradeability
The registry does not eliminate trust anchors; it changes their
representation and the constraints placed on them. A deployment MUST
identify the principals authorized to create top-level delegations,
the validator set or consensus governance, and the software or state-
transition rules that define valid writes.
If the state-transition implementation is upgradeable, the deployment
MUST state whether an upgrade can remove protected-delegation
guarantees. A deployment claiming irreversible protection MUST
provide a mechanism by which the relevant invariant becomes non-
upgradeable, or an equivalent governance rule whose violation is
detectable and causes consumers to reject the changed system.
Consumers SHOULD pin or otherwise authenticate the deployment
identity, rule version, and finalized checkpoint mechanism they
trust. A software upgrade, chain migration, or fork MUST NOT
silently convert a Protected Delegation into an Ordinary Delegation.
Migration procedures MUST preserve protected boundaries or require an
explicit new trust decision by consumers.
Gersch Expires 22 March 2027 [Page 21]
Internet-Draft Protected Delegation September 2026
A protected registry intentionally limits emergency intervention.
Abuse, legal process, or operational disputes do not create a
protocol exception unless such an exception was part of the protected
capability set when the holder elected protection. This consequence
MUST be disclosed to holders and operators.
12. Transfers, Re-parenting, and Ordinary Recovery
An Ordinary Delegation retains the recovery model of the hierarchy in
which it sits. A deployment MAY provide an operation by which the
holder of a parent allocation reassigns the controlling principal of
an Ordinary Delegation beneath it, for use on credential loss,
expiry, or administrative error. Where such an operation exists, the
deployment MUST publish the conditions under which it may be invoked.
The operation MUST be refused where the target allocation is an
irreversible Protected Delegation, which is the distinction between
the two delegation kinds.
A transfer of control SHOULD use a two-party or otherwise receiver-
confirmed mechanism so that an allocation cannot be pushed to a
principal unable to exercise it. Transfer of control does not by
itself change the allocation's parent.
Re-parenting moves an allocation between authority subtrees. It MUST
verify that the new parent contains the resource and that all
applicable protected-range rules remain satisfied. A Protected
Delegation MUST NOT be re-parented in a way that restores superior
capabilities that protection removed.
Cross-registry or cross-root transfer can therefore be represented
without deleting and recreating the resource or its child
allocations. Implementations SHOULD preserve dependent origin
authorizations when the transfer leaves their authorization semantics
valid.
13. Availability and Replication
A replicated registry replaces retrieval from multiple publication
repositories with replication of a single ordered state machine; it
does not eliminate distributed-systems failure modes. Nodes can lag,
consensus can halt, networks can partition, and software versions can
disagree.
A consumer SHOULD validate against a local or independently operated
replica when practical. Derived services SHOULD identify the
finalized checkpoint from which their VRP set was built. Multiple
independent consumers can then compare checkpoint identity as well as
VRP content.
Gersch Expires 22 March 2027 [Page 22]
Internet-Draft Protected Delegation September 2026
Availability and correctness are separate. Replication improves
availability of recorded state, while cryptographic authorization,
deterministic execution, protected-range admission rules, and
finality determine whether that state is acceptable.
14. Implementation Considerations
A proof-of-concept implementation uses a permissioned Ethereum-
compatible state machine, Solidity contracts, multisignature and
passkey-controlled accounts, an event indexer, an in-memory Patricia
trie, a JSON VRP projection, and RTR delivery through existing
tooling. These choices demonstrate feasibility but are not normative
requirements of this specification.
Implementations SHOULD separate authoritative state from derived
presentation and validation data. Human-readable organization names,
login credentials, cached RDAP information, portal configuration, and
derived indexes do not confer number-resource authority.
Operational limits such as maximum authorizations per allocation,
transaction gas limits, batch sizes, and index-rebuild procedures are
deployment-specific. They MUST NOT create a condition in which a
holder can make a required release or recovery operation permanently
unexecutable through unbounded self-created state.
15. Security Considerations
The primary security objective is preservation of the Protected
Delegation invariant. Implementations must consider conflicting
issuance, ancestor suppression, superior recovery, stale or
unconfirmed provenance, consensus equivocation, reorganization before
finality, unauthorized key use, index inconsistency, upgrade bypass,
migration downgrade, and source-merging errors.
A compromised protected-holder key can authorize malicious origin
changes within that holder's authority. Protection deliberately
prevents a superior authority from acting as an automatic recovery
mechanism. Holder-controlled threshold and recovery mechanisms are
therefore strongly recommended.
A compromised or colluding validator quorum may censor writes, halt
progress, or present competing histories depending on the consensus
protocol. Independent validation of state-transition rules does not
by itself solve canonical-history selection; this is why explicit
finality is REQUIRED.
Gersch Expires 22 March 2027 [Page 23]
Internet-Draft Protected Delegation September 2026
Incorrect genesis or imported holder data can be made tamper-evident
without becoming true. Only Confirmed State is eligible for
authoritative VRP export under this specification.
Incorrect merging of RPKI-derived and protected-registry-derived
authority can broaden valid origin sets. Consumers MUST apply
protected-range semantic filtering before union. Prefix-only
filtering that ignores maximum-length authorization scope can fail to
remove a conflicting authorization.
A consumer that ingests only an exported VRP set relies on the
exporter rather than on the registry, because an export carries no
holder signature. Section 4.3 states the conditions under which a
consumer obtains proof instead of trust.
This mechanism provides route-origin authorization only. It does not
validate AS_PATH, prevent route leaks, authenticate forwarding, or
guarantee reachability.
16. Operational Considerations
Operators should introduce the system as an additional relying-party
authority source and inspect the combined VRP set before applying it
to production routers. Protected-range selection should be explicit
and auditable.
The system should expose the finalized checkpoint, protected-range
set, confirmation state, and resulting VRPs in forms suitable for
independent comparison. Operators should alert on unexpected changes
to any of those inputs.
Because protected delegation intentionally removes superior recovery,
organizations should establish recovery procedures before protection
becomes irreversible. A deployment may enforce a provisional
interval to permit correction of erroneous grants, but that interval
must not be represented as final protection.
Electing protection changes which source supplies origin authority
inside the Protected Range. Because conforming consumers suppress
RPKI-derived authority within that range, a holder whose Protected
Delegation carries no Final, Confirmed origin authorizations will
cause announcements inside the range to evaluate as NotFound for
those consumers, even where valid RPKI ROAs exist for the same space.
A holder SHOULD publish protected-registry origin authorizations
before, or in the same operation as, the protection becoming
irreversible. A deployment SHOULD warn a holder that elects
protection for a range having no corresponding origin authorizations.
Gersch Expires 22 March 2027 [Page 24]
Internet-Draft Protected Delegation September 2026
The protocol does not require a holder to leave RPKI. A holder may
maintain RPKI objects for compatibility while protected-range
consumers apply the precedence rules in this document.
17. Implementation Status
At the time of this -00 document, a proof-of-concept implementation
has been exercised on a permissioned proof-of-authority chain.
Implemented components include hierarchical IPv4/IPv6 allocations and
suballocations, route-origin authorizations, control transfer,
parent-initiated recovery for Ordinary Delegations, Protected
Delegations, protected-range write guards, authority-boundary
validation, re-parenting, provenance/confirmation handling, an event-
derived read model, prefix-trie validation, a JSON VRP feed, and RTR
delivery through existing tooling.
The implementation also includes a prefix-decomposed protected-range
index and an upgrade/backfill path. Deployment-specific account
systems and web interfaces are not part of this specification.
Work remaining for broader experimentation includes interoperable
native consumers, independent implementations, explicit production
consensus/finality profiles, operational measurements at Internet
scale, and experience with holder onboarding and recovery.
18. IANA Considerations
This document requests no IANA actions.
19. Privacy Considerations
Internet number-resource allocations and route-origin authorizations
are normally public operational data. Implementations should
nevertheless avoid placing authentication credentials, personal
contact data, or unnecessary organizational metadata into immutable
authoritative state. Human identity and login information should
remain outside the public registry unless required for a separately
defined purpose.
20. Acknowledgements
The author thanks ARIN for early technical feedback on the concepts
described in this document.
21. Normative References
Gersch Expires 22 March 2027 [Page 25]
Internet-Draft Protected Delegation September 2026
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC6483] Huston, G. and G. Michaelson, "Validation of Route
Origination Using the Resource Certificate Public Key
Infrastructure (PKI) and Route Origin Authorizations
(ROAs)", RFC 6483, 2012,
<https://www.rfc-editor.org/rfc/rfc6483>.
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
Austein, "BGP Prefix Origin Validation", RFC 6811, 2013,
<https://www.rfc-editor.org/rfc/rfc6811>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", RFC 8174, 2017,
<https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8210] Bush, R. and R. Austein, "The Resource Public Key
Infrastructure (RPKI) to Router Protocol, Version 1",
RFC 8210, 2017, <https://www.rfc-editor.org/rfc/rfc8210>.
[RFC8416] Ma, D., Mandelberg, D., and T. Bruijnzeels, "Simplified
Local Internet Number Resource Management with the RPKI
(SLURM)", RFC 8416, 2018,
<https://www.rfc-editor.org/rfc/rfc8416>.
[RFC9582] Snijders, J. and T. Harrison, "A Profile for Route Origin
Authorizations (ROAs)", RFC 9582, 2024,
<https://www.rfc-editor.org/rfc/rfc9582>.
22. Informative References
[I-D.ietf-sidrops-constraining-rpki-trust-anchors]
Snijders, J., Buehler, T., and L. Qin, "Constraining RPKI
Trust Anchors", Work in Progress, Internet-Draft, draft-
ietf-sidrops-constraining-rpki-trust-anchors-02, 16
September 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-sidrops-constraining-rpki-trust-anchors-02>.
[I-D.nro-sidrops-ta-constraints]
Harrison, T., Bruijnzeels, T., Martinez-Cagnazzo, C.,
Kosters, M., and Y. Chadee, "RPKI Trust Anchor
Constraints", Work in Progress, Internet-Draft, draft-nro-
sidrops-ta-constraints-00, October 2025,
<https://datatracker.ietf.org/doc/html/draft-nro-sidrops-
ta-constraints-00>.
Gersch Expires 22 March 2027 [Page 26]
Internet-Draft Protected Delegation September 2026
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", RFC 3779, 2004,
<https://www.rfc-editor.org/rfc/rfc3779>.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, 2012,
<https://www.rfc-editor.org/rfc/rfc6480>.
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates", RFC 6487, 2012,
<https://www.rfc-editor.org/rfc/rfc6487>.
[RFC8630] Huston, G., Weiler, S., Michaelson, G., Kent, S., and T.
Bruijnzeels, "Resource Public Key Infrastructure (RPKI)
Trust Anchor Locator", RFC 8630, 2019,
<https://www.rfc-editor.org/rfc/rfc8630>.
[RFC9319] Gilad, Y., Goldberg, S., Sriram, K., Snijders, J., and B.
Maddison, "The Use of maxLength in the RPKI", RFC 9319,
2022, <https://www.rfc-editor.org/rfc/rfc9319>.
Appendix A. Comparison with Alternative Approaches
The property specified in Section 5 could be pursued within RPKI
rather than by a separate registry. This appendix records the
strongest forms of that argument, and what each does and does not
resolve. One of them, described in Appendix A.3, is sufficient on
its own for a class of holders.
A.1. A Relying-Party Precedence Rule
A relying party could prefer a more-specific authorization and
discard a covering authorization naming a different origin. This is
not viable, because that shape is ordinary delegation: a provider
authorizing an aggregate while a customer authorizes a more-specific
prefix inside it.
Measured over a global rpki-client validated set for IPv4 in July
2026, 958,366 such combinations of covering authorization, more-
specific authorization, and differing origin occur. A rule of this
form would discard 33,501 covering VRPs, approximately 4.5 percent of
all IPv4 VRPs. Prefix relationships alone therefore do not separate
a conflicting authorization from normal operation.
Gersch Expires 22 March 2027 [Page 27]
Internet-Draft Protected Delegation September 2026
A.2. A Separate Trust Anchor for the Holder
The most direct alternative is structural: give the holder its own
trust anchor, so that it is not subordinate to a Regional Internet
Registry. A relying party installing the holder's Trust Anchor
Locator [RFC8630] obtains the holder's authority directly, with no
ancestor in the certification path able to reissue over it.
A separate trust anchor on its own does not produce exclusivity,
because it removes nothing. Appendix A.3 describes the case where a
consumer additionally constrains the incumbent trust anchor, which
does. Absent such a constraint, trust anchor certificates assert the
entire resource space. Retrieved 23 August 2026, ARIN's trust anchor
certificate carried all IPv4 address space, IPv6 ::/0, and Autonomous
System Numbers 0-4294967295, and the RIPE NCC, LACNIC and AFRINIC
trust anchors likewise asserted all IPv4 address space. This is
deliberate: an all-resources trust anchor need not be reissued as
allocations change. A trust anchor has no issuer above it, so under
[RFC6487] its resource extension is authoritative rather than checked
for containment.
Installing a holder's Trust Anchor Locator therefore adds an issuer
without removing the existing one. The incumbent trust anchor still
covers the holder's prefixes, may still issue a subordinate
certificate and an authorization over them, and that path validates.
A relying party evaluates each trust anchor independently and emits
the union, and [RFC6811] treats a route as Valid on any match. The
outcome is two simultaneously valid origins for the same prefix, with
no state in [RFC6811] distinguishing them.
[I-D.nro-sidrops-ta-constraints], authored by staff of all five
Regional Internet Registries, records the same condition. Its
problem statement observes that "for example, one TA could issue a
Route Origin Authorization (ROA) for resources that have actually
been assigned to another TA". It proposes constraint validation
performed by the relying party against consensus objects published by
a group of trust anchors, and states that "[t]he constraint
validation process must operate in such a way that TAs can continue
to enumerate the complete set of INRs, notwithstanding that
constraint validation will apply additional restrictions with respect
to the set of INRs for which a given TA may make statements". Trust
anchor certificates therefore remain as they are.
The two approaches differ in where a constraint is enforced, and by
whom.
Gersch Expires 22 March 2027 [Page 28]
Internet-Draft Protected Delegation September 2026
* Constraint validation applies when authority is read, by relying
parties that have deployed the mechanism and are consulting a
current consensus object. The mechanism in this document applies
the constraint when authority is written, so no conflicting record
is created and none is distributed.
* Constraint validation derives a holder's exclusivity from the
agreement of a consensus group of trust anchors, and
[I-D.nro-sidrops-ta-constraints] notes that "[a] consensus group
may effectively revoke any other TA". For a holder whose
requirement is that no other party be able to withdraw its
authority, that relocates the requirement rather than satisfying
it.
* A trust anchor for each holder scales with the number of holders,
each requiring distribution to every relying party, key rollover,
and inclusion in relying-party software. A protected registry
carries any number of Protected Delegations behind a single feed
and enforces exclusivity within the registry rather than in each
relying party's configuration.
A separate trust anchor remains useful, and Appendix A.3 sets out the
conditions under which it is sufficient on its own.
A.3. Locally Configured Trust Anchor Constraints
A relying party can constrain the effective authority of a trust
anchor locally, without agreement among trust anchors.
[I-D.ietf-sidrops-constraining-rpki-trust-anchors] specifies such an
approach, in which a relying party applies a locally configured set
of Internet number resources to a trust anchor and accepts
subordinate products only where their resources fall within that set.
This is a stronger alternative than the consensus-group form
discussed in Appendix A.2, because a single operator can apply it
unilaterally and it therefore does not derive a holder's exclusivity
from the agreement of other trust anchors.
Where a holder operates its own trust anchor and consumers locally
constrain the incumbent trust anchor away from that holder's
resources, the holder obtains exclusivity at those consumers without
any mechanism from this document. For such deployments the approach
described here is unnecessary.
Three differences remain, and they concern where the constraint lives
rather than whether it works.
Gersch Expires 22 March 2027 [Page 29]
Internet-Draft Protected Delegation September 2026
* The constraint is configured and applied by each consumer.
Exclusivity holds only at consumers that have configured it, and a
holder cannot determine from registry state which consumers those
are. The invariant in this document is applied once, at the point
of record, and holds for every consumer of that registry's export.
* Local configuration scales with the number of constrained trust
anchors multiplied by the number of consumers, because each
consumer must obtain and maintain the resource set for each trust
anchor it constrains. [I-D.nro-sidrops-ta-constraints] exists in
part to supply that input at scale, which reintroduces the
consensus group discussed in Appendix A.2.
* A constraint limits what a trust anchor may validly assert to a
constraining consumer. It does not prevent the assertion from
being created or published. The conflicting object continues to
exist and continues to validate for any consumer that has not
applied the constraint.
The practical consequence is that the two approaches address
different holders. Where a holder's obstacle to RPKI participation
is the terms of a registration agreement, a separate trust anchor
together with locally configured constraints is likely to be
sufficient, and requires none of the mechanism described in this
document. The mechanism specified here addresses the narrower case
in which a holder requires that the capability be absent from the
authorization system itself, rather than constrained at each consumer
that chooses to constrain it.
Appendix B. Conformance Vectors for the Enumeration Bound
The following vectors distinguish a conforming implementation of
Section 6 from a plausible but incorrect one. Each gives the
registry state, the candidate record and its writer, and the required
verdict. An implementation reaching a different verdict on any of
them does not conform and will diverge from one that does.
The vectors assume a registry using a distinguished virtual root
whose resource is a placeholder representing all IPv4 address space,
as described in Section 4. In the table below, M is the controlling
principal of the Protected Delegation named in the state column, and
H6 is the controlling principal of an allocation outside the
corresponding Protected Subtree.
Gersch Expires 22 March 2027 [Page 30]
Internet-Draft Protected Delegation September 2026
+===+======================+=============================+=========+
| # | State | Writer and candidate | Verdict |
+===+======================+=============================+=========+
| 1 | 2001:db8::/32 | H6 records an allocation of | REFUSE |
| | protected, held by M | 2001:db8:1::/48 | |
+---+----------------------+-----------------------------+---------+
| 2 | as vector 1 | M records an authorization | ACCEPT |
| | | for 2001:db8:1::/48 | |
+---+----------------------+-----------------------------+---------+
| 3 | ::/0 protected | the virtual root records an | REFUSE |
| | | allocation of 2001:db8::/32 | |
+---+----------------------+-----------------------------+---------+
Table 2: Vectors for the upward enumeration in IPv6
For IPv4 the upward enumeration is bounded at 33 lookups; for IPv6 it
is bounded at 129. An implementation that has hard-coded the smaller
figure, or sized an index by it, can satisfy every IPv4 case and fail
vectors 1 through 3.
Vector 3 is the case in which the shortened enumeration described in
Section 6 MUST NOT be taken. The virtual root's resource is a
placeholder representing all IPv4 address space, so it does not
contain an IPv6 candidate. The premise for beginning one bit below
the holder's prefix length therefore fails, and an implementation
that begins there regardless does not examine prefix length zero,
misses the Protected Range, and wrongly accepts the record.
Author's Address
Joseph Gersch
Invykta LLC
Email: jgersch@invykta.com
Gersch Expires 22 March 2027 [Page 31]