BGP Signed Origin Delegation Attestation (SODA)
draft-jiang-idr-bgp-soda-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) | |
|---|---|---|---|
| Authors | Shenglin(Forrest) Jiang , Ke Xu , Zhuotao liu , Xiaoliang Wang | ||
| Last updated | 2026-06-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-jiang-idr-bgp-soda-00
Inter-Domain Routing S. Jiang
Internet-Draft Zhongguancun Laboratory
Intended status: Standards Track K. Xu
Expires: 20 December 2026 Z. Liu
X. Wang
Tsinghua University
18 June 2026
BGP Signed Origin Delegation Attestation (SODA)
draft-jiang-idr-bgp-soda-00
Abstract
This document defines BGP Signed Origin Delegation Attestation
(SODA), an optional transitive BGP path attribute that carries a
signed authorization, issued by the holder of an IP prefix,
delegating origination of that prefix to a specified Autonomous
System (AS) until a stated expiry time. Using SODA, a validator
performing Route Origin Validation (ROV) can determine whether an
ROV-Invalid result reflects an authorized delegation rather than a
route hijack.
Discussion Venues
This note is to be removed before publishing as an RFC.
Discussion of this document takes place on the Inter-Domain Routing
Working Group mailing list (idr@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/idr/.
Source for this draft and an issue tracker can be found at
https://github.com/shenglinwh/bgp-soda.
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."
Jiang, et al. Expires 20 December 2026 [Page 1]
Internet-Draft BGP SODA June 2026
This Internet-Draft will expire on 20 December 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
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
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Why an In-Band Attribute Rather Than a Published
Object . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Relationship to Publishing an Additional ROA . . . . . . 5
3.3. Deployment Considerations . . . . . . . . . . . . . . . . 6
4. The ROUTE_DELEGATION_ATTEST Attribute . . . . . . . . . . . . 6
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Attribute Format . . . . . . . . . . . . . . . . . . . . 7
4.3. Signed Data . . . . . . . . . . . . . . . . . . . . . . . 9
5. Operational Procedures . . . . . . . . . . . . . . . . . . . 9
5.1. Delegator Procedures . . . . . . . . . . . . . . . . . . 9
5.2. Delegatee Procedures . . . . . . . . . . . . . . . . . . 10
6. Validation Procedure . . . . . . . . . . . . . . . . . . . . 11
6.1. Phase 1: Route Origin Validation . . . . . . . . . . . . 11
6.2. Phase 2: SODA Fallback Validation . . . . . . . . . . . . 11
6.3. Local Policy . . . . . . . . . . . . . . . . . . . . . . 12
7. Relationship to Existing Mechanisms . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8.1. Scope of Delegator Authority . . . . . . . . . . . . . . 14
8.2. Stale Route Window . . . . . . . . . . . . . . . . . . . 14
8.3. BGPsec Key Compromise . . . . . . . . . . . . . . . . . . 14
8.4. Replay of Valid SODA Attributes . . . . . . . . . . . . . 15
8.5. Removal of the Attribute . . . . . . . . . . . . . . . . 15
8.6. Computational Cost and Denial of Service . . . . . . . . 15
8.7. Path Validation . . . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9.1. BGP Path Attribute Type Code . . . . . . . . . . . . . . 16
9.2. SODA Signature Algorithm Identifiers . . . . . . . . . . 16
Jiang, et al. Expires 20 December 2026 [Page 2]
Internet-Draft BGP SODA June 2026
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . 18
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction
The Resource Public Key Infrastructure (RPKI) [RFC6480] and Route
Origin Authorizations (ROAs) [RFC9582] provide the foundation for
Route Origin Validation (ROV) [RFC6811]. A ROA authorizes a single
Autonomous System (AS) to originate routes for one or more specified
IP prefixes. When a BGP speaker performs ROV on a received UPDATE, a
route whose origin AS is not authorized by a covering ROA is
classified as Invalid.
ROV is effective at detecting unauthorized route origination.
However, an Invalid result does not necessarily indicate a route
hijack. In operational practice, a prefix holder may authorize
another AS to originate routes on its behalf without directly
modifying the corresponding ROA. Such arrangements arise in a
variety of scenarios, including address leasing, outsourced routing
services, DDoS mitigation, content delivery networks, and other forms
of delegated route origination [IMC2024][NDSS2026][Oakland26].
Although a prefix holder could authorize a delegatee by creating an
additional ROA, doing so requires modifying the global RPKI
repository state and may be operationally undesirable for short-
lived, dynamic, or frequently changing delegations. Furthermore,
ROAs are designed to express route origination authorization rather
than explicit delegation relationships between a resource holder and
a delegatee.
As a result, ROV alone cannot distinguish between a route hijack and
a route originated by an AS that has been legitimately authorized
through an out-of-band delegation arrangement. Both cases produce
the same ROV-Invalid outcome.
This document defines the BGP Signed Origin Delegation Attestation
(SODA), an optional transitive BGP path attribute named
ROUTE_DELEGATION_ATTEST. The attribute carries a cryptographically
signed delegation statement, issued by a prefix holder, authorizing a
specified AS to originate a prefix until a stated expiration time.
Jiang, et al. Expires 20 December 2026 [Page 3]
Internet-Draft BGP SODA June 2026
When standard ROV produces an Invalid result, a validator may
evaluate the SODA attribute to determine whether the route represents
a legitimate delegation rather than an unauthorized origination.
SODA therefore complements existing RPKI-based origin validation
while preserving the existing ROV trust model.
2. Conventions and Definitions
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.
3. Design Rationale
This section explains two design choices that are central to SODA and
that distinguish it from the obvious alternatives: carrying the
delegation authorization in band, as a BGP path attribute, rather
than as a published RPKI object; and introducing a new mechanism at
all, rather than expecting prefix holders to publish an additional
ROA. These choices also bound the situations in which SODA is the
appropriate tool.
3.1. Why an In-Band Attribute Rather Than a Published Object
The authorization that SODA conveys could in principle be expressed
as a new RPKI signed object, published to a repository and fetched by
relying parties, in the manner of ROAs [RFC9582]. SODA instead
carries the authorization in the BGP UPDATE that announces the
delegated route. This choice is motivated by the properties of the
delegations that SODA targets: short-lived, dynamic, or frequently
changing arrangements such as address leasing, outsourced routing,
DDoS mitigation, and content delivery [IMC2024][NDSS2026][Oakland26].
A repository-published object becomes usable only after it has been
published at the issuer's publication point, fetched by relying
parties on their polling cycle, validated, and distributed to
routers. The resulting end-to-end delay is independent of BGP
propagation and can be substantial relative to the lifetime of an
ephemeral delegation. An in-band attribute, by contrast, travels
with the route: the authorization and the announcement arrive
together and converge at BGP speed. For a delegation whose intended
lifetime is comparable to, or shorter than, repository convergence
latency, in-band delivery is the property that makes the
authorization useful at all.
Jiang, et al. Expires 20 December 2026 [Page 4]
Internet-Draft BGP SODA June 2026
In-band delivery also binds the authorization to a specific
announcement. A published object is global and standalone: it
authorizes the delegatee to originate the prefix toward every relying
party, for the object's entire validity period, independent of
whether any corresponding route is being announced. The SODA
attribute exists only while the delegatee announces the route,
propagates only as far as the route propagates, and is scoped to the
prefix and the AS pair carried in the UPDATE. The lifetime and reach
of the authorization in the routing system therefore track the
lifetime and reach of the route itself, rather than persisting in
global state after the delegation has ended.
These benefits come at a cost, which this document does not minimize.
In-band delivery requires that the validating AS implement SODA in
order to obtain any benefit (see Section 3.3), and it places
signature verification on, or adjacent to, the BGP processing path,
with an associated denial-of-service surface that is discussed in
Section 8.6. SODA further relies on the existing RPKI and on BGPsec
router certificates [RFC8209]; it introduces no new public key
infrastructure.
3.2. Relationship to Publishing an Additional ROA
A prefix holder can already authorize a second origin AS by
publishing an additional ROA [RFC9582]. Where the delegation is
long-lived and stable, this is the appropriate tool, and operators
SHOULD publish a ROA rather than rely on SODA: a ROA is honored by
every relying party that performs ROV today, requires no new
attribute support in the data path, and is the mechanism the RPKI is
designed to provide.
SODA targets the cases in which publishing a ROA is, by the prefix
holder's own choice, undesirable or insufficiently timely:
delegations that are too short-lived, too dynamic, or too numerous to
be reflected in the global repository without unacceptable churn or
latency. In these cases the relevant baseline is not "a ROA that
already solves the problem" but "no additional ROA, and therefore an
ROV-Invalid route that is discarded everywhere." Against that
baseline, SODA is strictly additive: at a SODA-aware validator it can
recover a legitimately delegated route, while at a validator that
does not implement SODA the route is treated exactly as it is today,
namely as ROV-Invalid. SODA does not weaken ROV and does not change
the outcome for any route that a prefix holder would have authorized
with a ROA.
Jiang, et al. Expires 20 December 2026 [Page 5]
Internet-Draft BGP SODA June 2026
3.3. Deployment Considerations
SODA provides benefit only between a delegator that issues attributes
and a validating AS that evaluates them; an AS that does not
implement Phase 2 (Section 6.2) ignores the attribute and continues
to treat the route as ROV-Invalid. SODA therefore offers no network-
wide benefit from unilateral adoption, and its value to a given
delegation grows with the number of validators on the relevant paths
that implement it. This is an inherent property of an in-band,
endpoint-evaluated mechanism and is the principal cost of the design.
The corresponding failure mode is, however, benign. Because a SODA-
Valid outcome only ever causes a validator to accept a route that ROV
alone would have rejected, the absence of SODA support, the removal
of the attribute in transit (see Section 8.5), and the expiry of a
delegation can each only cause a delegated route to be treated as
ROV-Invalid. None of these conditions can cause an unauthorized
route to be accepted. SODA thus fails safe with respect to hijack in
every partial-deployment scenario.
Operators deploying SODA should also account for the cost of
evaluating attributes attached to ROV-Invalid routes; this denial-of-
service surface, and the implementation measures that bound it, are
discussed in Section 8.6.
4. The ROUTE_DELEGATION_ATTEST Attribute
4.1. Overview
ROUTE_DELEGATION_ATTEST is a new BGP path attribute. Its type code
is TBD (to be assigned by IANA). It is defined with the following
flags:
* Optional (high-order bit of the Attribute Flags octet set to 1).
* Transitive (second-high-order bit set to 1).
* Extended Length (fourth-high-order bit set to 1) to accommodate
the variable-length signature field.
* The Partial bit (third-high-order bit) follows standard BGP
transitive attribute semantics per [RFC4271].
The attribute carries a signed statement, issued by the delegator AS,
authorizing the delegatee AS to originate a specified prefix until a
stated expiration time.
Jiang, et al. Expires 20 December 2026 [Page 6]
Internet-Draft BGP SODA June 2026
4.2. Attribute Format
The value field of ROUTE_DELEGATION_ATTEST has the following format
(all multi-octet values are in network byte order):
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Sig-Alg-ID | Prefix-Length | MaxLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delegator-ASN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delegatee-ASN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delegation-Expiry |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sig-Length | Prefix (octets 1-2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix (cont., variable, total 0-16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All fixed-length fields occupy fixed octet offsets. The two
variable-length fields, Prefix and Signature, appear last: their
lengths are determined by Prefix-Length and Sig-Length, respectively,
both of which are carried in the fixed-length portion of the value.
A parser reads the fixed fields at known offsets, derives the Prefix
length from Prefix-Length, and then reads the Signature using Sig-
Length.
Version (1 octet): The version of the SODA attribute format. This
document defines Version 1 (value 0x01). Implementations MUST
ignore (i.e., not use for validation) attributes with unknown
Version values, and MUST forward them unchanged per transitive
attribute semantics.
Sig-Alg-ID (1 octet): An identifier for the signature algorithm
used. This document defines the value 0x01 for ECDSA with P-256
and SHA-256, the algorithm suite defined for BGPsec in [RFC8608].
Additional values may be registered as described in Section 9.2.
Validators that do not recognize the Sig-Alg-ID MUST treat the
SODA attribute as invalid.
Prefix-Length (1 octet): The length, in bits, of the delegated
prefix, using the encoding of [RFC4271] Section 4.3.
MaxLength (1 octet): The maximum prefix length of routes the
Jiang, et al. Expires 20 December 2026 [Page 7]
Internet-Draft BGP SODA June 2026
delegatee is authorized to originate, following the semantics of
the maxLength field in [RFC9582] Section 3. The value MUST be
greater than or equal to Prefix-Length and MUST NOT exceed 32 for
IPv4 or 128 for IPv6, according to the address family of the
announced prefix (see Prefix below).
Delegator-ASN (4 octets): The 4-octet AS Number of the delegator,
i.e., an AS belonging to the holder of the delegated prefix. The
delegator signs this attribute with the private key of its BGPsec
router certificate ([RFC8209]). The binding between the
Delegator-ASN and the prefix, which establishes the delegator's
authority to delegate origination, is verified as described in
Section 8.1.
Delegatee-ASN (4 octets): The 4-octet AS Number of the delegatee,
i.e., the AS authorized to originate routes for the prefix. This
value MUST match the origin AS in the AS_PATH of the BGP UPDATE
carrying this attribute.
Delegation-Expiry (4 octets): The expiry time of this delegation,
expressed as a 32-bit unsigned integer representing seconds since
the Unix epoch (January 1, 1970, 00:00:00 UTC). This value
indicates the end of the intended delegation period, independent
of the validity period of any RPKI certificate or BGPsec router
certificate. Validators MUST compare this field against the
current time during SODA evaluation, as specified in Section 6.2.
Sig-Length (2 octets): The length, in octets, of the Signature
field. For Sig-Alg-ID 0x01 (ECDSA P-256), the signature is
encoded as a fixed 64-octet value, the concatenation of the two
32-octet integers r and s, as specified for BGPsec signatures in
[RFC8608].
Prefix (variable, 0-16 octets): The IP address prefix to which this
delegation applies, encoded as the minimum number of octets
necessary to represent the Prefix-Length most significant bits.
Any trailing bits beyond Prefix-Length within the final octet MUST
be set to zero so that the encoding (and therefore the signature)
is canonical. IPv4 prefixes require at most 4 octets; IPv6
prefixes require at most 16 octets. The address family is not
carried in the attribute; it is taken from the address family of
the announced NLRI against which the attribute is validated
(Section 6.2), and the Prefix MUST be interpreted, and the
MaxLength bound applied, in that address family.
Signature (variable): The digital signature produced by the
delegator using the private key corresponding to its BGPsec router
certificate. The signed data is defined in Section 4.3.
Jiang, et al. Expires 20 December 2026 [Page 8]
Internet-Draft BGP SODA June 2026
4.3. Signed Data
The signature covers the following fields, concatenated in order
without any additional framing:
Signed-Data = Version (1 octet)
| Sig-Alg-ID (1 octet)
| Prefix-Length (1 octet)
| MaxLength (1 octet)
| Delegator-ASN (4 octets)
| Delegatee-ASN (4 octets)
| Delegation-Expiry (4 octets)
| Prefix (variable, canonical, see above)
The Sig-Length and Signature fields are not covered by the signature.
The signed fields are exactly the value fields in wire order
(Section 4.2) with Sig-Length and Signature removed. Including
Version and Sig-Alg-ID in the signed data binds the format version
and the chosen algorithm to the signature and prevents version or
algorithm substitution.
5. Operational Procedures
5.1. Delegator Procedures
A delegator MUST be the holder of the delegated prefix in the RPKI,
i.e., the resource holder to whom the prefix is allocated or sub-
allocated. The delegator's AS and the delegated prefix MUST
therefore be covered by a common RPKI resource certificate, so that
the delegator's authority over the prefix can be verified as
described in Section 8.1. The delegator MUST also hold a BGPsec
router certificate for its AS, as defined in [RFC8209], whose private
key it uses to sign the attribute. Authority to delegate origination
follows from holding the address space; it is distinct from, and
stronger than, mere authorization to originate the prefix, which a
ROA alone conveys.
To issue a ROUTE_DELEGATION_ATTEST attribute value for a delegation:
1. Construct the ROUTE_DELEGATION_ATTEST attribute value as
specified in Section 4.2, with the appropriate Delegatee-ASN,
Prefix, MaxLength, and Delegation-Expiry values.
2. Compute the signature over the Signed-Data as specified in
Section 4.3, using the BGPsec router certificate private key.
Jiang, et al. Expires 20 December 2026 [Page 9]
Internet-Draft BGP SODA June 2026
3. Deliver the signed attribute value to the delegatee via an out-
of-band channel. The out-of-band delivery protocol is outside
the scope of this document.
The delegator SHOULD set Delegation-Expiry to a value no later than
the intended end of the delegation period. The delegator MAY issue a
replacement ROUTE_DELEGATION_ATTEST attribute value with an updated
Delegation-Expiry to extend an active delegation.
5.2. Delegatee Procedures
A delegatee that has received a valid ROUTE_DELEGATION_ATTEST
attribute value from the delegator SHOULD attach the attribute to BGP
UPDATE messages for the delegated prefix.
The delegatee SHOULD cease advertising the ROUTE_DELEGATION_ATTEST
attribute after the Delegation-Expiry timestamp has passed, and
SHOULD withdraw the corresponding route unless a renewed attribute
value has been obtained.
A delegatee MUST NOT modify the value of a ROUTE_DELEGATION_ATTEST
attribute received from the delegator; the value MUST be included in
BGP UPDATE messages exactly as provided by the delegator.
A delegatee MUST NOT construct a ROUTE_DELEGATION_ATTEST attribute
that names its own AS as the Delegator-ASN unless it is itself the
holder of the prefix. An attribute self-issued without such
authority will fail the delegator-authority check in Step 2 of
Section 6.2.
Intermediate ASes that receive an UPDATE carrying a
ROUTE_DELEGATION_ATTEST attribute MUST NOT alter the attribute value.
Per standard transitive attribute semantics [RFC4271], an AS that
does not recognize the attribute type code forwards it unchanged and
sets the Partial bit; setting the Partial bit does not affect SODA
validation, because the Signed-Data (Section 4.3) does not include
the attribute flags.
A BGP speaker that aggregates routes such that the announced prefix
or the origin AS of the resulting aggregate differs from the Prefix
or the Delegatee-ASN carried in a ROUTE_DELEGATION_ATTEST attribute
MUST remove the attribute from the aggregate, because the attestation
no longer corresponds to the announcement. If such an attribute is
nonetheless retained, it will fail validation (Step 5 or Step 6 of
Section 6.2) and the aggregate will be treated as ROV-Invalid; SODA
thus fails safe under aggregation. Determination of the origin AS in
the presence of an AS_SET follows the rules of [RFC6811].
Jiang, et al. Expires 20 December 2026 [Page 10]
Internet-Draft BGP SODA June 2026
6. Validation Procedure
Validation of routes carrying ROUTE_DELEGATION_ATTEST follows a two-
phase procedure. Phase 1 is standard ROV; Phase 2 is the SODA
fallback, activated only if Phase 1 produces an Invalid result.
6.1. Phase 1: Route Origin Validation
Perform ROV as specified in [RFC6811] and [RFC9582]:
1. Determine the effective origin AS from the AS_PATH attribute.
2. Query the local RPKI cache for ROAs covering the announced
prefix.
3. If a matching ROA is found (prefix covered, origin AS matches,
prefix length within maxLength), the result is ROV-Valid. The
route is accepted; SODA evaluation is not performed.
4. If no ROA covers the announced prefix, the result is ROV-
NotFound, and SODA evaluation is not performed: with no validated
ROA, there is no RPKI anchor from which the delegator's authority
over the prefix could be derived.
5. If a ROA covers the announced prefix but the origin AS does not
match, the result is ROV-Invalid. Proceed to Phase 2
(Section 6.2).
6.2. Phase 2: SODA Fallback Validation
Phase 2 is entered only when Phase 1 produces ROV-Invalid. This
indicates that a ROA exists for the prefix (establishing an RPKI
trust anchor) but the origin AS does not match the ROA. Phase 2
determines whether this mismatch is the result of a legitimate
delegation. The checks below are conjunctive: any failure yields the
indicated result and terminates Phase 2. They MAY be performed in
any order; for the performance implications of ordering, see
Section 8.6.
1. If the UPDATE does not carry a ROUTE_DELEGATION_ATTEST attribute,
if the attribute is syntactically malformed, if it carries an
unrecognized Version, or if it specifies an unrecognized Sig-Alg-
ID, then SODA evaluation cannot be completed: the ROV-Invalid
result stands and no further SODA processing is performed.
2. Verify, using the validated RPKI certificate tree, that the
Delegator-ASN and the announced prefix are covered by a common
RPKI resource certificate, i.e., that a single resource holder
Jiang, et al. Expires 20 December 2026 [Page 11]
Internet-Draft BGP SODA June 2026
holds both the Delegator-ASN (as an AS resource) and the
announced prefix (as an IP resource). If no such common
certificate exists, the result is SODA-Invalid. This step
anchors the delegation to address-space holdership: it
establishes that the delegator holds the prefix and thus has
authority to delegate its origination, rather than merely
permission to originate it (which a ROA conveys and which is not
sufficient; see Section 8.1). This check requires access to RPKI
certificate resource information, which is available to a relying
party with repository access (the same access used in Step 3).
3. Using the Delegator-ASN, retrieve the corresponding BGPsec router
certificate from the RPKI repository, as specified in [RFC8209],
and extract its public key. If no valid BGPsec router
certificate is found for the Delegator-ASN, the result is SODA-
Invalid.
4. Using the retrieved public key and the algorithm identified by
Sig-Alg-ID, verify the Signature over the Signed-Data defined in
Section 4.3. If signature verification fails, the result is
SODA-Invalid.
5. Verify that the announced prefix is consistent with the delegated
scope carried in the attribute: the most significant Prefix-
Length bits of the announced prefix MUST equal the Prefix field,
and the length of the announced prefix MUST be greater than or
equal to Prefix-Length and less than or equal to MaxLength. If
the announced prefix falls outside this scope, the result is
SODA-Invalid. This step ensures that a delegation signed for one
prefix cannot be used to authorize a different prefix.
6. Verify that the Delegatee-ASN field equals the effective origin
AS determined from the AS_PATH attribute of the BGP UPDATE. If
the values do not match, the result is SODA-Invalid.
7. Compare the Delegation-Expiry value against the current time at
the moment of evaluation. If the current time is greater than or
equal to Delegation-Expiry, the result is SODA-Expired.
Otherwise (the current time is strictly less than Delegation-
Expiry), the result is SODA-Valid.
6.3. Local Policy
This document defines the SODA validation outcomes SODA-Valid, SODA-
Invalid, and SODA-Expired, which operators can incorporate into local
routing policy. Consistent with [RFC8481], a router applies no SODA-
derived policy to a route except as configured by the operator.
Implementations SHOULD make the following behaviors configurable:
Jiang, et al. Expires 20 December 2026 [Page 12]
Internet-Draft BGP SODA June 2026
* Accept routes with a SODA-Valid outcome (RECOMMENDED for operators
with delegatee relationships).
* Log and alert on SODA-Expired outcomes to trigger delegator
notification.
* Apply a more restrictive local policy to routes with a SODA-
Invalid outcome than to routes with an ordinary ROV-Invalid
outcome, since the presence of a ROUTE_DELEGATION_ATTEST attribute
that fails verification may indicate an active attempt to misuse
the delegation mechanism.
Because BGP does not provide a mechanism for timed route withdrawal,
validators SHOULD periodically re-evaluate locally cached routes
against the Delegation-Expiry timestamps of any stored
ROUTE_DELEGATION_ATTEST attributes. The appropriate re-evaluation
interval is a matter of local policy; implementations SHOULD support
configuration of this interval.
7. Relationship to Existing Mechanisms
SODA is designed to complement, not replace, existing BGP security
mechanisms. The following summarizes the relationship between SODA
and related standards:
ROV and ROA ([RFC6811], [RFC9582]): Phase 1 of SODA validation
performs standard ROV as defined in [RFC6811]. A valid ROA
covering the announced prefix is a necessary precondition for SODA
evaluation; SODA does not substitute for ROV. The NotFound result
explicitly excludes SODA evaluation, preserving the integrity of
the RPKI trust chain.
BGPsec ([RFC8205]): SODA relies on BGPsec router certificates
defined in [RFC8209] for signature validation. No new PKI is
required. SODA and BGPsec address orthogonal properties (origin
delegation versus path integrity) and may coexist in the same
UPDATE message.
Signed Prefix Lists (SPL) ([I-D.ietf-sidrops-rpki-prefixlist],
[I-D.ietf-sidrops-spl-verification]): An SPL is an RPKI object,
published to the repository, in which an AS lists the complete set
of prefixes it may originate. As the SPL profile notes, an SPL is
self-asserted by the AS holder and carries no authority from any
prefix holder; that authority is conveyed separately by a ROA.
SODA differs in both trust root and delivery: a SODA attestation
is signed by the holder of the prefix (the delegator), is bound to
a specific announcement, and is carried in band rather than
published as a repository object. SODA is therefore a prefix-
Jiang, et al. Expires 20 December 2026 [Page 13]
Internet-Draft BGP SODA June 2026
holder authorization for a third party to originate, whereas an
SPL is a self-description by an origin AS of its own intended
originations.
8. Security Considerations
8.1. Scope of Delegator Authority
A ROA expresses that an AS may originate a prefix; it does not
express that the AS may further delegate origination of that prefix
to a third party. If SODA anchored delegation authority in a ROA's
origin AS, then any AS that a prefix holder had authorized to
originate the prefix (for example, a transit provider or a previous
delegatee) could in turn issue SODA attestations naming arbitrary
further delegatees, an escalation the prefix holder may not have
intended.
For this reason, SODA anchors delegation authority in address-space
holdership rather than in origination authorization. Step 2 of
Section 6.2 requires the Delegator-ASN and the announced prefix to be
covered by a common RPKI resource certificate, establishing that a
single resource holder holds both the AS and the prefix and therefore
that the delegator is entitled to delegate the prefix's origination.
8.2. Stale Route Window
BGP does not natively support timed route withdrawal. When a
Delegation-Expiry timestamp passes, the route remains in the RIB as
SODA-Expired until a BGP UPDATE or withdrawal is received or until
the validator performs a periodic re-evaluation sweep. Operators
SHOULD configure validators to perform periodic re-evaluation as
described in Section 6.3 and SHOULD configure delegatees to withdraw
delegated routes promptly upon expiry.
8.3. BGPsec Key Compromise
If a delegator's BGPsec router certificate private key is
compromised, an attacker can forge SODA attributes for any prefix
held by the same resource holder as the delegator's AS, i.e., any
prefix covered by a common RPKI resource certificate with that AS
(see Section 8.1). The delegator SHOULD revoke the compromised
BGPsec router certificate immediately, which will cause all
outstanding SODA attribute values signed by that key to fail Step 3
of Section 6.2. Certificate revocation follows BGPsec key rollover
procedures as defined in [RFC8209].
Jiang, et al. Expires 20 December 2026 [Page 14]
Internet-Draft BGP SODA June 2026
8.4. Replay of Valid SODA Attributes
A valid ROUTE_DELEGATION_ATTEST attribute may be replayed by an
attacker until the Delegation-Expiry timestamp is reached. The
prefix-consistency check in Step 5 of Section 6.2 confines any such
replay to the exact prefix and length range named in the signed
attribute; it cannot be used to authorize a different prefix.
This document relies on bounded delegation lifetimes to limit replay
exposure. Operators are encouraged to use relatively short
delegation lifetimes and to renew delegations as necessary.
8.5. Removal of the Attribute
Because ROUTE_DELEGATION_ATTEST is an optional, transitive attribute,
an on-path adversary on a BGP session can remove it from an UPDATE.
Removal does not enable a route hijack: without the attribute, the
route reverts to an ordinary ROV-Invalid result and is rejected by
validators applying the RECOMMENDED policy in Section 6.3. Removal
can, however, cause a legitimately delegated route to be rejected.
SODA therefore fails safe against hijack, but does not protect the
availability of a delegated route against an adversary able to strip
the attribute in transit.
8.6. Computational Cost and Denial of Service
Phase 2 of validation (Section 6.2) performs RPKI certificate-tree
lookups and a signature verification. Because Phase 2 is reached
only for ROV-Invalid routes, an adversary can attach a malformed or
unverifiable ROUTE_DELEGATION_ATTEST attribute to a large number of
announcements that are already ROV-Invalid, attempting to induce
expensive lookups and verifications at validators.
To bound this cost, and because the Phase 2 checks may be performed
in any order, implementations SHOULD perform the inexpensive checks
first: the attribute presence, well-formedness, Version, and Sig-Alg-
ID checks of Step 1; the prefix-consistency check of Step 5; and the
Delegatee-ASN match of Step 6. Only if those succeed should an
implementation perform the RPKI lookups of Steps 2 and 3 and the
signature verification of Step 4. Implementations SHOULD cache Phase
2 results keyed on the attribute value, so that repeated
announcements carrying the same attribute are not re-verified, and
SHOULD be able to rate-limit Phase 2 processing, including on a per-
peer basis. These measures keep the additional work introduced by
SODA bounded even under a flood of crafted attributes.
Jiang, et al. Expires 20 December 2026 [Page 15]
Internet-Draft BGP SODA June 2026
8.7. Path Validation
SODA provides attestation of route origin delegation only. It does
not validate the AS_PATH beyond checking that the origin AS matches
the Delegatee-ASN. SODA is orthogonal to and compatible with BGPsec
[RFC8205] and ASPA [I-D.ietf-sidrops-aspa-verification], which
address path validity. Operators requiring end-to-end path security
SHOULD deploy SODA in conjunction with BGPsec or ASPA.
9. IANA Considerations
9.1. BGP Path Attribute Type Code
IANA is requested to assign a new type code in the "BGP Path
Attributes" registry for the ROUTE_DELEGATION_ATTEST attribute
defined in this document:
+=======+=========================+===============+
| Value | Code | Reference |
+=======+=========================+===============+
| TBD | ROUTE_DELEGATION_ATTEST | This document |
+-------+-------------------------+---------------+
Table 1
9.2. SODA Signature Algorithm Identifiers
IANA is requested to create a new registry, "SODA Signature Algorithm
Identifiers", to record the one-octet Sig-Alg-ID values used by the
ROUTE_DELEGATION_ATTEST attribute. The registration policy is IETF
Review [RFC8126].
The initial contents of the registry are:
+===========+==========================+===============+
| Value | Algorithm | Reference |
+===========+==========================+===============+
| 0x00 | Reserved | This document |
+-----------+--------------------------+---------------+
| 0x01 | ECDSA P-256 with SHA-256 | RFC 8608 |
+-----------+--------------------------+---------------+
| 0x02-0xFF | Unassigned | |
+-----------+--------------------------+---------------+
Table 2
10. References
Jiang, et al. Expires 20 December 2026 [Page 16]
Internet-Draft BGP SODA June 2026
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/rfc/rfc4271>.
[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/rfc/rfc6480>.
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
Austein, "BGP Prefix Origin Validation", RFC 6811,
DOI 10.17487/RFC6811, January 2013,
<https://www.rfc-editor.org/rfc/rfc6811>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/rfc/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol
Specification", RFC 8205, DOI 10.17487/RFC8205, September
2017, <https://www.rfc-editor.org/rfc/rfc8205>.
[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/rfc/rfc8209>.
[RFC8608] Turner, S. and O. Borchert, "BGPsec Algorithms, Key
Formats, and Signature Formats", RFC 8608,
DOI 10.17487/RFC8608, June 2019,
<https://www.rfc-editor.org/rfc/rfc8608>.
Jiang, et al. Expires 20 December 2026 [Page 17]
Internet-Draft BGP SODA June 2026
[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/rfc/rfc9582>.
10.2. Informative References
[I-D.ietf-sidrops-aspa-verification]
Azimov, A., Bogomazov, E., Bush, R., Patel, K., Snijders,
J., and K. Sriram, "BGP AS_PATH Verification Based on
Autonomous System Provider Authorization (ASPA) Objects",
Work in Progress, Internet-Draft, draft-ietf-sidrops-aspa-
verification-25, 19 April 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
aspa-verification-25>.
[I-D.ietf-sidrops-rpki-prefixlist]
Snijders, J. and G. Huston, "A profile for Signed Prefix
Lists for Use in the Resource Public Key Infrastructure
(RPKI)", Work in Progress, Internet-Draft, draft-ietf-
sidrops-rpki-prefixlist-05, 10 December 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
rpki-prefixlist-05>.
[I-D.ietf-sidrops-spl-verification]
Sriram, K., Snijders, J., and D. Montgomery, "Signed
Prefix List (SPL) Based Route Origin Verification and
Operational Considerations", Work in Progress, Internet-
Draft, draft-ietf-sidrops-spl-verification-04, 17 June
2026, <https://datatracker.ietf.org/doc/html/draft-ietf-
sidrops-spl-verification-04>.
[IMC2024] Du, X., Fontugne, R., Testart, C., Snoeren, A. C., and kc.
claffy, "Sublet Your Subnet: Inferring IP Leasing in the
Wild", In Proceedings of the ACM Internet Measurement
Conference (IMC 2024), 2024.
[NDSS2026] Li, W., Wan, T., and T. Chung, "Demystifying RPKI-Invalid
Prefixes: Hidden Causes and Security Risks",
In Proceedings of the Network and Distributed System
Security Symposium (NDSS 2026), 2026.
Jiang, et al. Expires 20 December 2026 [Page 18]
Internet-Draft BGP SODA June 2026
[Oakland26]
Li, W., Xu, Y., and T. Chung, "The Threat Landscape of IP
Leasing in the RPKI Era", In Proceedings of the IEEE
Symposium on Security and Privacy (Oakland'26), San
Francisco, USA, May 2026,
<https://weitongli.com/publications/papers/li-
2026-hijack.pdf>.
[RFC8210] Bush, R. and R. Austein, "The Resource Public Key
Infrastructure (RPKI) to Router Protocol, Version 1",
RFC 8210, DOI 10.17487/RFC8210, September 2017,
<https://www.rfc-editor.org/rfc/rfc8210>.
[RFC8481] Bush, R., "Clarifications to BGP Origin Validation Based
on Resource Public Key Infrastructure (RPKI)", RFC 8481,
DOI 10.17487/RFC8481, September 2018,
<https://www.rfc-editor.org/rfc/rfc8481>.
Acknowledgements
The authors thank the researchers at CAIDA, Virginia Tech, and
CableLabs whose measurement studies provided the empirical foundation
for this work.
Authors' Addresses
Shenglin Jiang
Zhongguancun Laboratory
Beijing
China
Email: jiangshl@zgclab.edu.cn
Ke Xu
Tsinghua University
Beijing
China
Email: xuke@tsinghua.edu.cn
Zhuotao Liu
Tsinghua University
Beijing
China
Email: zhuotaoliu@tsinghua.edu.cn
Jiang, et al. Expires 20 December 2026 [Page 19]
Internet-Draft BGP SODA June 2026
Xiaoliang Wang
Tsinghua University
Beijing
China
Email: wangxiaoliang0623@foxmail.com
Jiang, et al. Expires 20 December 2026 [Page 20]