]> Zhongguancun Lab

Beijing China lingst@zgclab.edu.cn

Tsinghua University

Beijing China xuke@tsinghua.edu.cn

Tsinghua University

Beijing China qli01@tsinghua.edu.cn

Tsinghua University

Beijing China zhuotaoliu@tsinghua.edu.cn

Capital Normal University

Beijing China wangxiaoliang@cnu.edu.cn

Security SIDROPS RPKI, ROV, BGP, security This document defines a Cryptographic Message Syntax (CMS) protected content type for ROV Deployment Transparency (ROV_TAG) objects for use with the Resource Public Key Infrastructure (RPKI). An ROV_TAG is a digitally signed object through which an Autonomous System (AS) that has deployed Route Origin Validation (ROV) can declare its ROV deployment status. When validated, an ROV_TAG's eContent can be used by ASes to identify which ASes have deployed ROV, enabling secure path selection and optimized ROV validation that reduces redundant validation operations in partial ROV deployment scenarios.

Introduction Route Origin Validation (ROV) is a critical security mechanism for BGP routing that uses the Resource Public Key Infrastructure (RPKI) to verify the legitimacy of route announcements. However, ROV deployment is currently partial, with a significant portion of ASes not yet having deployed ROV. In partial ROV deployment scenarios, two problems arise:

1. Security vulnerabilities: Even if an AS has deployed ROV and filters invalid route announcements, the AS may still have its traffic hijacked if upstream ASes have not deployed ROV. This occurs because upstream ASes that have not deployed ROV may accept and propagate hijacked routes, allowing attackers to redirect traffic through upstream paths where ROV has not been deployed.
2. Validation redundancy: Each AS independently re-validates ROV and is unable to leverage previous validation results.

This document defines a profile for ROV Deployment Transparency (ROV_TAG) objects that allows ASes to register their ROV deployment status in RPKI. This provides transparency about which ASes have deployed ROV, enabling secure path selection and optimized ROV validation that reduces redundant validation operations. See Section 3 for detailed use cases. This CMS protected content type definition conforms to the template for RPKI signed objects. In accordance with Section 4 of , this document defines:

1. The object identifier (OID) that identifies the ROV_TAG signed object. This OID appears in the eContentType field of the encapContentInfo object as well as the content-type signed attribute within the signerInfo structure.
2. The ASN.1 syntax for the ROV_TAG content, which is the payload signed by the AS. The ROV_TAG content is encoded using the ASN.1 Distinguished Encoding Rules (DER) .
3. The steps required to validate an ROV_TAG beyond the validation steps specified in .

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

Terminology This document uses the following terminology:

• Origin AS: The Autonomous System (AS) that originates a BGP route announcement. The Origin AS is defined as the last AS in the AS_PATH attribute of the BGP route announcement, as specified in .
• Non-origin AS: Any AS in the AS_PATH of a BGP route announcement that is not the Origin AS. In an AS_PATH containing multiple ASes, all ASes except the last one (the Origin AS) are non-origin ASes.

The ROV_TAG

The ROV_TAG Content Type The content-type for an ROV_TAG is defined as id-ct-ROVTAG, which has the numerical value of 1.2.840.113549.1.9.16.1.TBD. This OID MUST appear both within the eContentType in the encapContentInfo structure as well as the content-type signed attribute within the signerInfo structure (see ).

The ROV_TAG eContent The content of an ROV_TAG identifies the AS that has deployed ROV. The eContent of an ROV_TAG is an instance of ROVDeploymentAttestation, formally defined by the following ASN.1 module: ``` RPKI-ROV-TAG-2026 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-rpki-rov-tag-2026(TBD) } DEFINITIONS EXPLICIT TAGS ::= BEGIN IMPORTS CONTENT-TYPE FROM CryptographicMessageSyntax-2010 -- RFC 6268 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) } ; id-ct-ROVTAG OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) id-smime(16) id-ct(1) rovtag(TBD) } ct-ROVTAG CONTENT-TYPE ::= { TYPE ROVDeploymentAttestation IDENTIFIED BY id-ct-ROVTAG } ROVDeploymentAttestation ::= SEQUENCE { version [0] INTEGER DEFAULT 0, asID ASID, rovDeployed BOOLEAN } ASID ::= INTEGER (0..4294967295) END ``` Note that this content appears as the eContent within the encapContentInfo as specified in .

version The version number of the ROVDeploymentAttestation that complies with this specification MUST be 0 and MUST be explicitly encoded.

asID The asID field contains the AS number of the Autonomous System that is declaring its ROV deployment status.

rovDeployed The rovDeployed field is a BOOLEAN that indicates whether the AS has deployed ROV. Since only ASes that have deployed ROV register ROV_TAG objects, this field MUST be set to TRUE. For ASes that provide transit services (i.e., ASes that forward traffic for other ASes) that have deployed ROV, it is RECOMMENDED that they register an ROV_TAG object with rovDeployed set to TRUE. Stub ASes (end networks, content providers, etc. that do not provide transit services) MAY register ROV_TAG objects but are not required to do so.

ROV_TAG Validation To validate an ROV_TAG, a relying party MUST perform all the validation checks specified in as well as the following additional ROV_TAG-specific validation steps:

• The Autonomous System Identifier Delegation Extension MUST be present in the end-entity (EE) certificate contained within the ROV_TAG. The asID in the ROV_TAG eContent MUST match the ASId specified by the EE certificate's Autonomous System Identifier Delegation Extension.
• The Autonomous System Identifier Delegation Extension MUST contain exactly one "id" element (Section 3.2.3.6 of ) and MUST NOT contain any "inherit" elements (Section 3.2.3.3 of ) or "range" elements (Section 3.2.3.7 of ).
• The IP Address Delegation Extension MUST be absent.
• The rovDeployed field MUST be present and MUST be set to TRUE. Since only ASes that have deployed ROV register ROV_TAG objects, this field MUST always be TRUE.

If any of the above checks fail, the ROV_TAG in its entirety MUST be considered invalid and an error SHOULD be logged.

Use Cases

Secure Path Selection In partial ROV deployment scenarios, when an AS filters a hijacked route announcement received from an upstream AS through ROV validation, this indicates that the upstream AS has accepted and propagated the hijacked route. This may occur because the upstream AS has not deployed ROV or is not properly performing ROV validation. In this situation, the AS SHOULD avoid using paths through that upstream AS for traffic destined to the affected prefix. To implement this defensive measure, an AS can use ROV_TAG information obtained from its RPKI Relying Party (RP) to identify alternative paths from the BGP route announcements it has already received. An alternative path is one where the immediate upstream AS has deployed ROV (i.e., has registered an ROV_TAG object with rovDeployed set to TRUE). The AS checks the ROV deployment status of upstream ASes in the AS_PATH of received route announcements against the ROV_TAG information. If such alternative paths exist, the AS MAY prefer them over the path through the upstream AS that propagated the hijacked route. This approach is based on the following reasoning:

• If an upstream AS has deployed ROV, it will filter invalid route announcements and will not propagate hijacked routes.
• If an upstream AS has deployed ROV, it may also implement secure path selection (i.e., avoid paths through upstream ASes that have propagated hijacked route announcements when it detects such announcements). This creates a mechanism where ASes can prefer paths through upstream ASes that have deployed ROV. The logic is straightforward: if an AS detects that an upstream AS has propagated a hijacked route announcement (by filtering it through ROV validation), it SHOULD select an alternative secure path. Conversely, if no hijacked route announcements are detected from an upstream AS, that upstream AS is considered secure, and there is no need to select an alternative path.
• Therefore, if an alternative path exists where the immediate upstream AS has deployed ROV, that path is more likely to be secure from that point forward, reducing the risk that traffic will be hijacked.

The decision to use alternative paths is a matter of local policy. An AS MAY:

• Continue using normal BGP path selection when no hijacked route announcements are detected.
• When an AS filters a hijacked route announcement received from an upstream AS, consider alternative paths (where the immediate upstream AS has deployed ROV) as a defensive measure to avoid the path through the upstream AS that propagated the hijacked route.
• Fall back to normal BGP path selection if no alternative paths with ROV-deployed upstream ASes are available.

This addresses the security vulnerability problem by enabling ASes to avoid paths through upstream ASes that have propagated hijacked routes. Such paths are identified through ROV validation. When alternative secure paths are available, this reduces the risk of route hijacking even in partial ROV deployment scenarios. Note: This is a heuristic defensive mechanism and does not provide cryptographic security guarantees. The use of alternative paths is OPTIONAL and subject to local policy.

Optimized ROV Validation When an AS receives a BGP route announcement, it can use ROV_TAG information obtained from its RPKI Relying Party (RP) to optimize ROV validation and reduce redundant validation operations. The AS checks the AS_PATH of the received route announcement against the ROV_TAG information to determine whether any non-origin ASes in the path have deployed ROV (i.e., have registered an ROV_TAG object with rovDeployed set to TRUE). For AS_PATH parsing, the AS MUST check all ASes in the AS_PATH, including ASes that appear multiple times due to AS_PATH prepending. If the AS_PATH contains AS_SET or AS_CONFED_SET segments (as defined in ), the AS MAY check ASes within these segments for compatibility, though these segment types are deprecated. The validation rule is as follows:

• If the AS_PATH contains only the Origin AS (i.e., the route is received directly from the origin), the AS MUST perform ROV validation.
• If the AS_PATH contains multiple ASes, the AS checks whether any non-origin AS in the AS_PATH has deployed ROV by querying the ROV_TAG information. If any non-origin AS in the AS_PATH has deployed ROV, the AS SHOULD skip ROV validation, assuming that at least one upstream AS that has deployed ROV has already performed validation. This assumption is based on the ROV_TAG information indicating ROV deployment, but does not guarantee that validation was actually performed. If no non-origin AS in the AS_PATH has deployed ROV, the AS MUST perform ROV validation.
• If ROV_TAG information is unavailable (e.g., due to repository synchronization issues or the AS not supporting ROV_TAG), the AS MUST perform ROV validation.
• If an implementer chooses not to skip validation even when a non-origin AS in the AS_PATH has deployed ROV, the AS MUST still perform ROV validation.

This addresses the validation redundancy problem by reducing redundant ROV validation operations. The logic is straightforward: if any non-origin AS in the AS_PATH has deployed ROV (as indicated by ROV_TAG information), it is assumed that validation has been performed, and downstream ASes can skip redundant validation. This ensures that at least one AS in the path performs ROV validation, maintaining security while reducing redundancy. Note: This optimization is OPTIONAL. ASes that do not implement this optimization will continue to perform ROV validation for all received route announcements, maintaining the same security properties as traditional ROV deployment.

Operational Considerations This section discusses operational aspects of ROV_TAG deployment and usage.

Querying ROV_TAG Information ROV_TAG objects are stored in the RPKI repository alongside other RPKI objects (e.g., ROAs, ASPAs). Relying Parties (RPs) process ROV_TAG objects as part of their standard RPKI repository synchronization and validation procedures, as specified in . ASes obtain ROV_TAG information from their RPKI Relying Party (RP) (e.g., through RPKI-to-Router protocols such as or ). ASes can query this information efficiently to determine whether upstream ASes have deployed ROV. Real-time queries to the RPKI repository or RP are not required during BGP path selection.

Performance Considerations The number of ASes that provide transit services is relatively small compared to the total number of ASes, which means the total number of ROV_TAG objects is expected to be manageable. This results in minimal storage and query overhead compared to other RPKI objects such as ROAs. Query operations for ROV_TAG information can be performed efficiently using standard data structures (e.g., hash tables keyed by AS number), enabling fast lookups during BGP path selection.

Deployment Recommendations For ASes that provide transit services and have deployed ROV, it is RECOMMENDED that they register an ROV_TAG object with rovDeployed set to TRUE. This provides transparency about ROV deployment. It also enables downstream ASes to make informed path selection decisions and enables optimized ROV validation that reduces redundant validation operations. Stub ASes (end networks, content providers, etc.) MAY register ROV_TAG objects but are not required to do so. This is because they typically do not provide transit services, and their ROV deployment status is less critical for path selection decisions.

Implementation Considerations This section provides guidance for implementers of ROV_TAG support. ROV_TAG is a new RPKI object type. Existing RPKI RP implementations that do not support ROV_TAG will simply ignore ROV_TAG objects during repository synchronization, as per the RPKI validation rules specified in . This ensures backward compatibility: ROV_TAG objects do not interfere with existing RPKI operations, and ASes that have not deployed ROV_TAG support can continue to operate normally. RP implementations that support ROV_TAG SHOULD:

• Validate ROV_TAG objects according to the validation steps specified in Section 2.7.
• Make validated ROV_TAG information available to ASes (e.g., through RPKI-to-Router protocols such as or ).

The number of ROV_TAG objects is expected to be relatively small compared to other RPKI objects such as ROAs. This is because only ASes that provide transit services are expected to register ROV_TAG objects. Implementers that choose to implement the optimized ROV validation described in Section 3.2 SHOULD:

• Obtain ROV_TAG information from the RPKI Relying Party (RP) (e.g., through RPKI-to-Router protocols such as or ).
• Implement efficient AS_PATH parsing to identify all ASes in the AS_PATH, including handling AS_PATH prepending and deprecated AS_SET or AS_CONFED_SET segments for compatibility.
• Implement efficient ROV_TAG lookup mechanisms, such as hash tables keyed by AS number, to quickly determine whether ASes in the AS_PATH have deployed ROV by querying the ROV_TAG information.
• Provide configuration options to enable or disable optimized ROV validation. This allows operators to make informed decisions based on their operational requirements and risk tolerance.
• Log optimized ROV validation decisions (e.g., when validation is skipped) to facilitate troubleshooting and security auditing.
• Handle cases where ROV_TAG information is unavailable gracefully by reverting to performing ROV validation for all received route announcements.

Security Considerations The security considerations of , , and also apply to ROV_TAG objects. There is no assumption of confidentiality for the data in an ROV_TAG; it is anticipated that ROV_TAG objects will be stored in repositories that are accessible to all ISPs, and perhaps to all Internet users. The purpose of an ROV_TAG is to convey transparency about ROV deployment status. Thus, the integrity of an ROV_TAG MUST be established. ROV_TAG objects are cryptographically signed and validated according to , ensuring that the ROV deployment status information cannot be tampered with by intermediate ASes. The secure path selection mechanism described in Section 3.1 is a heuristic approach and does not provide cryptographic security guarantees. The actual security properties depend on the operational practices of upstream ASes. Regarding the optimized ROV validation use case (Section 3.2), implementers and operators are advised to be aware of the following security considerations:

• Route Origin Hijacking vs. Path Hijacking: ROV and ROV_TAG address Route Origin Hijacking attacks, where an AS announces prefixes it does not own. However, ROV and ROV_TAG do not address Path Hijacking attacks, where an intermediate AS modifies the AS_PATH to redirect traffic. For example, an intermediate AS could modify the AS_PATH to include an AS that has deployed ROV, even if that AS is not actually in the path, which could cause downstream ASes to skip ROV validation based on incorrect information. However, even if downstream ASes perform ROV validation, an intermediate AS that modifies the AS_PATH can still redirect traffic through path hijacking. Path hijacking is a fundamental limitation of BGP and requires other solutions such as BGPsec.
• Registration vs. Actual Deployment: An AS may register an ROV_TAG with rovDeployed set to TRUE but not actually perform ROV validation. This could cause downstream ASes to skip validation based on incorrect information. However, if an upstream AS does not perform ROV validation, it may propagate invalid routes, which could be detected by downstream ASes that perform ROV validation. The optimized ROV validation is OPTIONAL, and implementers can choose to always perform validation if they prefer.

The optimized ROV validation is OPTIONAL and SHOULD only be implemented after careful risk assessment. ASes that do not implement this optimization will continue to perform ROV validation for all received route announcements, maintaining the same security properties as traditional ROV deployment.

IANA Considerations This document will require IANA to assign values in several registries. The specific assignments will be determined during the IETF review process. The following registrations are anticipated:

• An OID for the RPKI-ROV-TAG-2026 ASN.1 module in the "SMI Security for S/MIME Module Identifier" registry.
• An OID for the ROV_TAG content type in the "SMI Security for S/MIME CMS Content Type" registry.
• An entry for ROV_TAG in the "RPKI Signed Object" registry.

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] 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 defines two X.509 v3 certificate extensions. The first binds a list of IP address blocks, or prefixes, to the subject of a certificate. The second binds a list of autonomous system identifiers to the subject of a certificate. These extensions may be used to convey the authorization of the subject to use the IP addresses and autonomous system identifiers contained in the extensions. [STANDARDS-TRACK] This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK] This document defines a profile for the structure of the Resource Public Key Infrastructure (RPKI) distributed repository. Each individual repository publication point is a directory that contains files that correspond to X.509/PKIX Resource Certificates, Certificate Revocation Lists and signed objects. This profile defines the object (file) naming scheme, the contents of repository publication points (directories), and a suggested internal structure of a local repository cache that is intended to facilitate synchronization across a distributed collection of repository publication points and to facilitate certification path construction. [STANDARDS-TRACK] This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size, and signature format for the Resource Public Key Infrastructure (RPKI) subscribers that generate digital signatures on certificates, Certificate Revocation Lists, and signed objects as well as for the relying parties (RPs) that verify these digital signatures. [STANDARDS-TRACK] This document defines a generic profile for signed objects used in the Resource Public Key Infrastructure (RPKI). These RPKI signed objects make use of Cryptographic Message Syntax (CMS) as a standard encapsulation format. [STANDARDS-TRACK] In order to verifiably validate the origin Autonomous Systems of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers. [STANDARDS-TRACK] 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] 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. BCP 172 (i.e., RFC 6472) recommends not using AS_SET and AS_CONFED_SET AS_PATH segment types in the Border Gateway Protocol (BGP). This document advances that recommendation to a standards requirement in BGP; it prohibits the use of the AS_SET and AS_CONFED_SET path segment types in the AS_PATH. This is done to simplify the design and implementation of BGP and to make the semantics of the originator of a BGP route clearer. This will also simplify the design, implementation, and deployment of various BGP security mechanisms. This document updates RFC 4271 by deprecating the origination of BGP routes with AS_SET (Type 1 AS_PATH segment) and updates RFC 5065 by deprecating the origination of BGP routes with AS_CONFED_SET (Type 4 AS_PATH segment). Finally, it obsoletes RFC 6472. ITU-T ITU-T Informative References The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates some auxiliary ASN.1 modules to conform to the 2008 version of ASN.1; the 1988 ASN.1 modules remain the normative version. There are no bits- on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes.

Example ROV_TAG eContent Payload Below is an example of a DER-encoded ROV_TAG eContent with annotation following the '#' character. Example: Transit AS with ROV deployed $ echo 30080201000203000D050201FF | xxd -r -ps | openssl asn1parse \ -inform DER -dump -i 0:d=0 hl=2 l= 8 cons: SEQUENCE 2:d=1 hl=2 l= 1 prim: INTEGER :00 # version = 0 5:d=1 hl=2 l= 3 prim: INTEGER :0D05 # asID = 3333 10:d=1 hl=2 l= 1 prim: BOOLEAN :FF # rovDeployed = TRUE