]> Zhongguancun Laboratory

Beijing China jiangshl@zgclab.edu.cn

Tsinghua University

Beijing China xuke@tsinghua.edu.cn

Tsinghua University

Beijing China zhuotaoliu@tsinghua.edu.cn

Tsinghua University

Beijing China wangxiaoliang0623@foxmail.com

Routing Inter-Domain Routing 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 Discussion of this document takes place on the Inter-Domain Routing Working Group mailing list (idr@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction The Resource Public Key Infrastructure (RPKI) and Route Origin Authorizations (ROAs) provide the foundation for Route Origin Validation (ROV) . 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 . 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. 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.

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 when, and only when, they appear in all capitals, as shown here.

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.

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 . 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 . 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. 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 ), and it places signature verification on, or adjacent to, the BGP processing path, with an associated denial-of-service surface that is discussed in . SODA further relies on the existing RPKI and on SODA signing certificate; it introduces no new public key infrastructure.

Relationship to Publishing an Additional ROA A prefix holder can already authorize a second origin AS by publishing an additional ROA . 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.

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 () 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 ), 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 .

The ROUTE_DELEGATION_ATTEST Attribute

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 .

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.

Attribute Format The value field of ROUTE_DELEGATION_ATTEST has the following format (all multi-octet values are in network byte order): 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 . Additional values may be registered as described in . 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 Section 4.3.

MaxLength (1 octet):

The maximum prefix length of routes the delegatee is authorized to originate, following the semantics of the maxLength field in 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 SODA signing certificate. The binding between the Delegator-ASN and the prefix, which establishes the delegator's authority to delegate origination, is verified as described in .

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 SODA signing certificate. Validators MUST compare this field against the current time during SODA evaluation, as specified in .

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 signatures in .

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 (), 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 a dedicated signing key for SODA. The corresponding public key MUST be authenticated through the RPKI. The signed data is defined in .

Signed Data The signature covers the following fields, concatenated in order without any additional framing: The Sig-Length and Signature fields are not covered by the signature. The signed fields are exactly the value fields in wire order () 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.

Operational Procedures

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 authority over the delegated prefix MUST be established through a valid RPKI resource certificate covering the prefix. The delegator MUST use a dedicated signing key for SODA. 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 , with the appropriate Delegatee-ASN, Prefix, MaxLength, and Delegation-Expiry values.
2. Compute the signature over the Signed-Data as specified in , using the SODA signing private key.
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.

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 . Intermediate ASes that receive an UPDATE carrying a ROUTE_DELEGATION_ATTEST attribute MUST NOT alter the attribute value. Per standard transitive attribute semantics , 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 () 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 ) 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 .

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.

Phase 1: Route Origin Validation Perform ROV as specified in and :

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 ().

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 . RPKI certificate validation and resource authorization checks are performed by an RPKI relying party (RP) or a validation component using RP-validated information.

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 that the SODA signing certificate is valid and that its certified IP address resources cover the delegated prefix. If the certificate does not authorize the delegated prefix, the result is SODA-Invalid. 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 ). This authorization check is performed using resource information validated by an RPKI relying party (RP), without requiring the BGP router to inspect the RPKI certificate tree.
3. Identify the corresponding SODA signing certificate using validated RPKI information and extract its public key. If no valid SODA signing 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 . 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.

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 , a router applies no SODA-derived policy to a route except as configured by the operator. Implementations SHOULD make the following behaviors configurable:

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

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 (, ):

Phase 1 of SODA validation performs standard ROV as defined in . 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 ():

SODA relies on BGPsec router certificates defined in 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) (, ):

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-holder authorization for a third party to originate, whereas an SPL is a self-description by an origin AS of its own intended originations.

Security Considerations

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 IP address resource holdership rather than in route origination authorization. The delegator's authority is established through the IP address resources associated with the validated SODA signing certificate, independently of any AS number held by the delegator.

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 and SHOULD configure delegatees to withdraw delegated routes promptly upon expiry.

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

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

Computational Cost and Denial of Service Phase 2 of validation (Section 6.2) requires resource authorization checks and signature verification. RPKI certificate processing is performed by an RP or an associated validation component, without requiring BGP routers to access the RPKI certificate tree. 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.

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 and ASPA , which address path validity. Operators requiring end-to-end path security SHOULD deploy SODA in conjunction with BGPsec or ASPA.

IANA Considerations

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

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

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths. This document obsoletes RFC 1771. [STANDARDS-TRACK] This document describes an architecture for an infrastructure to support improved security of Internet routing. The foundation of this architecture is a Resource Public Key Infrastructure (RPKI) that represents the allocation hierarchy of IP address space and Autonomous System (AS) numbers; and a distributed repository system for storing and disseminating the data objects that comprise the RPKI, as well as other signed objects necessary for improved routing security. As an initial application of this architecture, the document describes how a legitimate holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that address space. Such verifiable authorizations could be used, for example, to more securely construct BGP route filters. This document is not an Internet Standards Track specification; it is published for informational purposes. To help reduce well-known threats against BGP including prefix mis- announcing and monkey-in-the-middle attacks, one of the security requirements is the ability to validate the origination Autonomous System (AS) of BGP routes. More specifically, one needs to validate that the AS number claiming to originate an address prefix (as derived from the AS_PATH attribute of the BGP route) is in fact authorized by the prefix holder to do so. This document describes a simple validation mechanism to partially satisfy this requirement. [STANDARDS-TRACK] Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes BGPsec, an extension to the Border Gateway Protocol (BGP) that provides security for the path of Autonomous Systems (ASes) through which a BGP UPDATE message passes. BGPsec is implemented via an optional non-transitive BGP path attribute that carries digital signatures produced by each AS that propagates the UPDATE message. The digital signatures provide confidence that every AS on the path of ASes listed in the UPDATE message has explicitly authorized the advertisement of the route. This document defines a standard profile for X.509 certificates used to enable validation of Autonomous System (AS) paths in the Border Gateway Protocol (BGP), as part of an extension to that protocol known as BGPsec. BGP is the standard for inter-domain routing in the Internet; it is the "glue" that holds the Internet together. BGPsec is being developed as one component of a solution that addresses the requirement to provide security for BGP. The goal of BGPsec is to provide full AS path validation based on the use of strong cryptographic primitives. The end entity (EE) certificates specified by this profile are issued to routers within an AS. Each of these certificates is issued under a Resource Public Key Infrastructure (RPKI) Certification Authority (CA) certificate. These CA certificates and EE certificates both contain the AS Resource extension. An EE certificate of this type asserts that the router or routers holding the corresponding private key are authorized to emit secure route advertisements on behalf of the AS(es) specified in the certificate. This document also profiles the format of certification requests and specifies Relying Party (RP) certificate path validation procedures for these EE certificates. This document extends the RPKI; therefore, this document updates the RPKI Resource Certificates Profile (RFC 6487). This document specifies the algorithms, algorithm parameters, asymmetric key formats, asymmetric key sizes, and signature formats used in BGPsec (Border Gateway Protocol Security). This document updates RFC 7935 ("The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure") and obsoletes RFC 8208 ("BGPsec Algorithms, Key Formats, and Signature Formats") by adding Documentation and Experimentation Algorithm IDs, correcting the range of unassigned algorithms IDs to fill the complete range, and restructuring the document for better reading. This document also includes example BGPsec UPDATE messages as well as the private keys used to generate the messages and the certificates necessary to validate those signatures. This document defines a standard profile for Route Origin Authorizations (ROAs). A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to one or more prefixes within the address block. This document obsoletes RFC 6482. Informative References Yandex Qrator Labs Internet Initiative Japan & Arrcus, Inc. Arrcus BSD Software Development USA National Institute of Standards and Technology This document describes procedures that make use of Autonomous System Provider Authorization (ASPA) objects in the Resource Public Key Infrastructure (RPKI) to verify the Border Gateway Protocol (BGP) AS_PATH attribute of advertised routes. This AS_PATH verification enhances routing security by adding means to detect and mitigate route leaks and AS_PATH manipulations. BSD Software Development APNIC This document defines a "Signed Prefix List", a Cryptographic Message Syntax (CMS) protected content type for use with the Resource Public Key Infrastructure (RPKI) to carry the complete list of prefixes which an Autonomous System (the subject AS) may originate to all or any of its routing peers. The validation of a Signed Prefix List confirms that the holder of the subject AS produced the object, and that this list is a current, accurate and complete description of address prefixes that may be announced into the routing system originated by the subject AS. USA National Institute of Standards and Technology BSD Software Development USA National Institute of Standards and Technology The Signed Prefix List (SPL) is an RPKI object that attests to the complete list of prefixes which an Autonomous System (AS) may originate in the Border Gateway Protocol (BGP). This document specifies an SPL-based Route Origin Verification (SPL-ROV) methodology and combines it with the ROA-based ROV (ROA-ROV) to facilitate an integrated mitigation strategy for prefix hijacks and AS forgery. The document also explains the various BGP security threats that SPL can help address and provides operational considerations associated with SPL-ROV deployment. In order to verifiably validate the origin Autonomous Systems and Autonomous System Paths of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data and router keys from a trusted cache. This document describes a protocol to deliver them. This document describes version 1 of the RPKI-Router protocol. RFC 6810 describes version 0. This document updates RFC 6810. Deployment of BGP origin validation based on Resource Public Key Infrastructure (RPKI) is hampered by, among other things, vendor misimplementations in two critical areas: which routes are validated and whether policy is applied when not specified by configuration. This document is meant to clarify possible misunderstandings causing those misimplementations; it thus updates RFC 6811 by clarifying that all prefixes should have their validation state set and that policy must not be applied without operator configuration.

Acknowledgements The authors thank the researchers at CAIDA, Virginia Tech, and CableLabs whose measurement studies provided the empirical foundation for this work.