A Profile for ROV Deployment Transparency

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 14 August 2026.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights 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

Route Origin Validation (ROV) [RFC6811] 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, the main security concern is:¶

When an AS has deployed ROV and performs ROV validation, it may detect a hijacked route announcement that was propagated by an upstream AS. This indicates that the upstream AS has not deployed ROV or is not properly performing ROV validation. If the AS continues using paths through that upstream AS, its traffic may be hijacked. However, the AS cannot determine which alternative paths go through upstream ASes that have deployed ROV, making it difficult to make informed path selection decisions to avoid the compromised upstream AS.¶

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. When an AS detects a hijacked route announcement from an upstream AS, it can use ROV_TAG information to identify alternative paths where the immediate upstream AS has deployed ROV, enabling it to avoid paths through upstream ASes that have propagated hijacked routes (see Section 3).¶

This CMS [RFC5652] protected content type definition conforms to the [RFC6488] template for RPKI signed objects. This document defines the object identifier (OID), ASN.1 syntax, and validation steps for ROV_TAG objects.¶

2. The ROV_TAG

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

3. Use Case: 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.¶

This use case describes a defensive mechanism that is triggered when an AS detects a security problem. Specifically:¶

1. The AS performs ROV validation and detects a hijacked route announcement.¶

2. The AS identifies that the hijacked route was propagated by an upstream AS (the immediate upstream AS).¶

3. The AS recognizes that the current path it is using also goes through this same immediate upstream AS that propagated the hijacked route.¶

4. At this point, if the AS continues using the current path through that upstream AS, the data plane traffic will go through the hijacked upstream AS, leading to the same hijacking.¶

5. As a defensive measure, the 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).¶

6. 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. This defensive measure is triggered only when a security problem is detected.¶

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

4. Operational Considerations

This section discusses operational aspects of ROV_TAG deployment and usage.¶

5. 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 [RFC6488]. 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.6.¶

• Make validated ROV_TAG information available to ASes (e.g., through RPKI-to-Router protocols such as [RFC6810] or [RFC8210]).¶

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 secure path selection described in Section 3 SHOULD:¶

• Obtain ROV_TAG information from the RPKI Relying Party (RP) (e.g., through RPKI-to-Router protocols such as [RFC6810] or [RFC8210]).¶

• Implement efficient ROV_TAG lookup mechanisms, such as hash tables keyed by AS number, to quickly determine whether upstream ASes in the AS_PATH have deployed ROV by querying the ROV_TAG information.¶

• Implement logic to detect when a hijacked route announcement is received from an upstream AS and identify alternative paths where the immediate upstream AS has deployed ROV.¶

• Provide configuration options to enable or disable secure path selection. This allows operators to make informed decisions based on their operational requirements and risk tolerance.¶

• Log secure path selection decisions (e.g., when alternative paths are selected) to facilitate troubleshooting and security auditing.¶

• Handle cases where ROV_TAG information is unavailable gracefully by falling back to normal BGP path selection.¶

6. Security Considerations

The security considerations of [RFC6481], [RFC6485], and [RFC6488] 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 integrity of an ROV_TAG MUST be established through cryptographic signing and validation according to [RFC6488].¶

A fundamental limitation of ROV_TAG is that the information is self-asserted: an AS may register an ROV_TAG with rovDeployed set to TRUE but not actually perform ROV validation. ROV_TAG does not provide cryptographic verification that ROV validation is actually being performed. A malicious AS could register an ROV_TAG to attract traffic when other ASes are looking for alternative paths. However, several factors mitigate this risk:¶

• The secure path selection mechanism is defensive in nature - it is triggered only when a security problem is detected (hijacked route), not used for general path selection. This reduces the opportunity for exploitation.¶

• Registering an ROV_TAG in RPKI creates a public record. ASes generally care about their reputation in the routing community, and false claims about ROV deployment could damage that reputation. While this does not provide cryptographic verification, it does provide some level of accountability.¶

• ASes could maintain local violation records (not in RPKI) to track when upstream ASes that have registered ROV_TAG propagate invalid route announcements. Such mechanisms are non-standardized and implementation-specific, but they demonstrate that ROV_TAG can enable accountability even without cryptographic verification of actual ROV deployment.¶

These factors reduce the risk of exploitation, though they do not eliminate it entirely.¶

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

8. References

Appendix A. 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 ¶

Authors' Addresses