idr W. Cheng Internet-Draft China Mobile Intended status: Informational C. Xie Expires: 24 December 2026 China Telecom M. Huang Zhongguancun Laboratory D. Li Tsinghua University N. Geng Huawei Technologies 22 June 2026 Information Asymmetry and Deployment Gaps in RPKI-based Route Origin Validation draft-cheng-sidrops-rpki-rov-gap-analysis-00 Abstract The Resource Public Key Infrastructure (RPKI) and Route Origin Validation (ROV) have made significant progress. Over 60% of IPv4 routes now have ROAs, and more than 70% of Internet traffic flows to ROA-covered prefixes. A growing number of large transit providers actively reject RPKI-invalid routes. Despite these achievements, however, thousands of RPKI-invalid routes persistently appear in the global routing table, and their count has not shown a sustained downward trend over the years. More importantly, the deployment of strict ROV drop policies is highly uneven. While large transit providers have largely embraced dropping invalids, the long tail - tens of thousands of stub ASes and small regional ISPs - remains on the sidelines, often keeping ROV in monitor-only mode or not deploying it at all. This document analyzes the root causes behind these persistent gaps: (1) inherent *synchronization asymmetry* between the RPKI management plane and router control planes, and (2) the inevitable possibility of *errors on both planes* (ROA configuration and router origin configuration). These causes lead to a fundamental *information asymmetry*: downstream routers cannot distinguish self-inflicted invalids (due to sync delays or misconfigurations) from true prefix hijacks. We examine the operational harms of this asymmetry - unnecessary blackholes, path shifts, global route churn, and long-lived connectivity loss - and explain why the long tail remains reluctant to deploy ROV. We then identify the informational requirements that any enhanced system would need to meet: source-side cross-validation Cheng, et al. Expires 24 December 2026 [Page 1] Internet-Draft RPKI-ROV Gap Analysis June 2026 to prevent self-inflicted invalids, and downstream consistency information to reconcile local ROV outcomes with the origin's intent. The goal is to enable more confident and widespread deployment of strict ROV policies while preserving the existing RPKI-ROV architecture. This document does not propose a specific protocol solution. It defines the problem space and information needs, providing a foundation for future work. 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 24 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 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Two Fundamental Technical Causes . . . . . . . . . . . . . . 4 2.1. 2.1 Synchronization Asymmetry . . . . . . . . . . . . . . 4 2.2. 2.2 Mis-coordination Across Planes . . . . . . . . . . . 5 Cheng, et al. Expires 24 December 2026 [Page 2] Internet-Draft RPKI-ROV Gap Analysis June 2026 3. Consequences: What Happens When Information Is Missing . . . 5 3.1. 3.1 Operational Harm When Dropping Aggressively . . . . . 6 3.2. 3.2 Security Harm When Tolerating Ambiguity . . . . . . . 7 3.3. 3.3 Disproportionate Impact on the Long Tail . . . . . . 8 3.4. 3.4 The Vicious Cycle . . . . . . . . . . . . . . . . . . 8 4. The Long Tail: Deployment Gap . . . . . . . . . . . . . . . . 8 4.1. 4.1 Uneven Deployment Landscape . . . . . . . . . . . . . 8 4.2. 4.2 Why the Long Tail Hesitates . . . . . . . . . . . . . 9 4.3. 4.3 Why the Long Tail Must Be On Board . . . . . . . . . 9 5. Limitations of Current Operational Mitigations . . . . . . . 10 6. Informational Requirements for an Enhanced System . . . . . . 11 6.1. 6.1 Source-Side Cross-Validation . . . . . . . . . . . . 12 6.2. 6.2 Downstream Consistency Information . . . . . . . . . 12 6.3. 6.3 Consistency Across Downstream Routers (Horizontal) . 13 6.4. 6.4 Relationship to Existing RPKI-ROV . . . . . . . . . . 13 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction RPKI-based ROV [RFC6480] [RFC6811] has become a cornerstone of inter- domain routing security. Over the past years, the community has witnessed remarkable progress: * ROA coverage exceeds 60% of IPv4 routes in the default-free zone (NIST RPKI Monitor, early 2026). * Traffic-weighted coverage is even higher: as early as May 2024, over 70% of Internet traffic already flowed to ROA-covered prefixes (Kentik). * A growing number of Tier-1 and large transit providers (e.g., Sparkle, Deutsche Telekom, Bell Canada) actively reject RPKI- invalid routes (IPinfo 2026). * Measurable ROV deployment exists in at least 27% of ASes (ATHENE, NDSS 2026). Cheng, et al. Expires 24 December 2026 [Page 3] Internet-Draft RPKI-ROV Gap Analysis June 2026 Despite these successes, persistent problems remain. The NIST RPKI Monitor shows that the number of RPKI-invalid IPv4 prefixes has stayed around 1% of the routing table for years - often thousands of routes, for example, 4,211 in April 2024 and 6,802 as of early 2026. Research [Demystifying_RPKI-Invalid_Prefixes] shows that over 96% of these invalid routes are false positives. More troubling, the deployment of strict ROV drop policies is highly uneven. While large transit providers have largely embraced dropping invalids, the long tail - tens of thousands of stub ASes and small regional ISPs - remains on the sidelines, often keeping ROV in monitor-only mode or not deploying it at all. This document seeks to answer: *Why, after years of progress, do these gaps persist?* And *what informational capabilities are needed to close them?* We analyze two fundamental technical causes and their consequences, examine the barriers faced by the long tail, and derive a set of informational requirements for any solution that aims to make ROV consistently actionable across the entire Internet. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Two Fundamental Technical Causes 2.1. 2.1 Synchronization Asymmetry The RPKI management plane (where ROAs are created and published) and the router control plane (which handles BGP announcements, route selection and propagation) are *independent and operate asynchronously*, with no guaranteed timing relationship between updates on the two planes. Data from publication points must propagate to Relying Parties (RPs) and then to individual routers. The RPKI Time-of-Flight study [RPKI_Time-of-Flight] measured these delays: * *Average delay*: >10 minutes * *Maximum delay*: >100 minutes Cheng, et al. Expires 24 December 2026 [Page 4] Internet-Draft RPKI-ROV Gap Analysis June 2026 * *High dispersion*: delays vary widely across different RPs and routers This inherent asynchrony creates: * *Transient false positives*: A route that should be Valid (because its ROA exists) may be marked Invalid at a downstream router until its local VRP cache catches up. * *Inconsistent router views*: At the same moment, two routers in different parts of the Internet may have different VRP snapshots, leading to divergent ROV outcomes for the same prefix. Synchronization asymmetry is an unavoidable property of distributed systems; it cannot be eliminated by engineering alone. 2.2. 2.2 Mis-coordination Across Planes The RPKI-ROV architecture relies on two independent planes - each susceptible to errors. *RPKI management plane errors* (ROA misconfigurations) are common: - Wrong ASN, incorrect maxLength, stale records after resource transfers. - Research [Demystifying_RPKI-Invalid_Prefixes] shows that *>96% of RPKI-invalid routes* are caused by such misconfigurations. *Router control plane errors* (route origin misconfigurations) are less frequent but occur in operational practice: - Announcing a prefix that the AS does not own. This type of mis-origination is a common cause of route leaks and hijacks (e.g., the Cloudflare route leak in 2026 and the AS17894 stealthy hijack case documented by APNIC). - (In extreme cases) A router's origin AS configuration could be mis-set, causing a large set of prefixes to be announced with an invalid origin ASN. The critical observation is that *neither plane can fully prevent its own errors*. The only way to catch mistakes before they affect global routing is to *cross-validate* the two planes: check that what the router intends to announce matches what the ROA authorizes (or the absence thereof). 3. Consequences: What Happens When Information Is Missing Cheng, et al. Expires 24 December 2026 [Page 5] Internet-Draft RPKI-ROV Gap Analysis June 2026 3.1. 3.1 Operational Harm When Dropping Aggressively An operator who wishes to enforce a strict "drop" policy on Invalid routes has to act without knowing the true cause. This blind action can directly harm reachability, stability, and performance, whether the Invalid originates from a transient sync delay or a persistent misconfiguration. *Harm from transient sync delays:* * *Unnecessary blackholes (single-homed scenarios)*: When the Invalid is a harmless transient delay and the affected downstream network is *single-homed* (i.e., has no alternative transit provider), dropping the route causes a complete, temporary loss of reachability to the prefix. Traffic is blackholed until the sync resolves. * *Unpredictable path shifts and route churn (multi-homed scenarios)*: For multi-homed networks, one transit provider may drop the Invalid route while another (with a different VRP freshness or no ROV deployment at all) continues to accept it. This forces traffic to shift to the remaining path - potentially longer, less preferred, or higher latency. Moreover, as different routers re-evaluate the route at different times, the set of accepting paths may change repeatedly, causing *BGP route churn and increased convergence time* across the global routing table. * *Recovery window with sustained impact*: Even if the route is later re-evaluated and reinstated (e.g., after the next RPKI cache refresh), the recovery period is unpredictable - ranging from minutes to over an hour (per RPKI Time-of-Flight). During this window, customers may experience degraded connectivity or, in single-homed cases, complete loss. *Harm from persistent misconfigurations* (e.g., ROA errors, wrong origin AS): * *Single-homed scenarios - long-lived blackholes*: When the affected downstream network is single-homed, dropping the route due to a persistent misconfiguration results in sustained, complete loss of reachability to the prefix. Unlike transient delays, there is no automatic recovery - the route remains blackholed until the misconfiguration is manually corrected and the corrected ROA propagates (which can take hours or days). * *Multi-homed scenarios - persistent path degradation*: For multi- homed networks, one transit provider may drop the persistently invalid route while another (with different ROV deployment or VRP Cheng, et al. Expires 24 December 2026 [Page 6] Internet-Draft RPKI-ROV Gap Analysis June 2026 freshness) continues to accept it. However, because the misconfiguration is not automatically fixed, the route may remain dropped on some paths indefinitely, forcing traffic onto potentially longer, less preferred, or higher-latency paths for an extended period. Moreover, as different upstream providers add or remove ROV filtering over time, the set of accepting paths may change unpredictably, causing intermittent BGP churn. * *Unpredictable fix cycles (common to both)*: The operator who drops the route has no insight into whether the origin AS is aware of the problem or plans to fix it. They may keep the route dropped indefinitely, or may later need to re-evaluate and reinstate it - each re-evaluation consumes resources and risks further instability. *Common operational paralysis*: Faced with both transient and persistent uncertainties, many operators choose *not* to enable strict drop policies at all. They keep ROV in "monitor only" mode, forfeiting its security benefit. 3.2. 3.2 Security Harm When Tolerating Ambiguity When operators avoid dropping Invalid - or even *avoid deploying ROV altogether* - due to the risks and uncertainties described above, they leave themselves and the Internet exposed to real hijacks. * *Avoidance of ROV deployment*: Many networks, especially smaller ones, decide not to deploy ROV at all because they cannot confidently handle Invalid outcomes. This perpetuates a large unprotected footprint - precisely where attackers can strike. * *True hijacks succeed*: For networks that have deployed ROV but keep it in monitor mode (or only filter a subset of sessions), a malicious origin announcing an Invalid route will not be blocked. The route propagates and may be accepted by other unprotected networks. * *Masked attacks ("invisible hijacking")*: Attackers can exploit less-specific routes or non-ROV paths to silently compromise traffic while ROV-enabled networks see a clean control plane ([Demystifying_RPKI-Invalid_Prefixes]). The very fallback mechanisms that "tolerate" false positives become a channel for real attacks. * *Delayed detection and response*: Without the ability to distinguish false positives (whether transient or persistent) from genuine attacks, every Invalid triggers a manual investigation. Alert fatigue leads to slow response to actual hijacks. Cheng, et al. Expires 24 December 2026 [Page 7] Internet-Draft RPKI-ROV Gap Analysis June 2026 3.3. 3.3 Disproportionate Impact on the Long Tail The harms described in Sections 3.1-3.2 are not evenly distributed. Networks with limited operational margin - stub ASes, small regional ISPs - suffer the most. * *Higher risk of self-inflicted outage*: Unlike large transit providers with redundant paths, a single false positive drop can disconnect an entire small network's customer base. * *Fewer resources to absorb harm*: They typically have smaller NOC teams, limited automation, and fewer fast recovery procedures compared to large providers. The recovery window tends to be longer, and the business impact of an outage is more severe. * *Lower incentive to deploy strict ROV*: For these networks, the cost of a mistake outweighs the abstract benefit of filtering others' routes. They remain on the sidelines, perpetuating the deployment gap. 3.4. 3.4 The Vicious Cycle These harms are not isolated - they reinforce each other, creating a self-sustaining barrier to deployment: Information missing -> Operators avoid strict drop -> Invalid routes persist -> False positive alerts continue -> Operators perceive ROV as "unsafe to enforce" -> Deployment stalls -> Information still missing 4. The Long Tail: Deployment Gap 4.1. 4.1 Uneven Deployment Landscape While precise statistics by network type are not formally published, a widely observed pattern emerges from multiple data sources (ATHENE, RoVISTA at NANOG 90, IPinfo 2026): * *Tier-1 and large transit providers*: High ROV adoption; most now reject invalids. * *Content / eyeball networks*: High ROA coverage, but lower incentive to reject others' invalids; their primary goal is protecting their own prefixes. Cheng, et al. Expires 24 December 2026 [Page 8] Internet-Draft RPKI-ROV Gap Analysis June 2026 * *Regional ISPs / smaller operators*: Moderate adoption, often partial (e.g., filtering only at IXPs). RoVISTA found only *12.3% of ASes are fully protected* (consistently filtering invalids across all paths). * *Stub ASes (>50,000 out of ~74,000 ASes)*: Very low deployment. Most operate in monitor mode or not at all. 4.2. 4.2 Why the Long Tail Hesitates For small and stub networks, the barrier to enabling strict ROV drop policies lies not in technical capability alone, but in the additional operational burden, resource demands, and potential business impact on their own customers that ROV deployment would impose - even when the technical knowledge exists, the cost of deployment in personnel, attention, and customer-facing risk often outweighs the perceived benefit: * *Asymmetric risk*: A single false positive or self-inflicted Invalid can disconnect their entire customer base. Large transit providers have redundant paths; stub ASes often do not. * *Limited operational resources*: Most have limited NOC capacity, with staff often handling multiple roles, and lack the automated tooling or security expertise that larger networks can afford. * *Information deficit*: Without knowing whether an upstream performed pre-validation or whether a sync delay caused an Invalid, they cannot confidently decide to drop. * *Weak direct incentive*: The benefit of filtering others' routes is indirect; the cost of a mistake is immediate and severe. 4.3. 4.3 Why the Long Tail Must Be On Board Even if all Tier-1 and IXPs dropped invalids, attackers can still reach victims through non-ROV paths that traverse the long tail. The ultimate defense against origin hijacking requires *both ends*: * *Source prevention* (clean at origin) * *Last-mile rejection* (customer-facing networks drop invalids) Cheng, et al. Expires 24 December 2026 [Page 9] Internet-Draft RPKI-ROV Gap Analysis June 2026 Core deployment alone limits the blast radius, but it cannot fully block hijacks - attackers can route around the core through non-ROV paths that lead to the long tail. These edge networks are not a secondary concern; they are the final layer of defense for end-user traffic. Unless the long tail is on board, comprehensive routing security will remain out of reach. 5. Limitations of Current Operational Mitigations The community has developed operational tools and practices to mitigate the problems described above. Before examining them, it is important to recall a *fundamental design principle* of RPKI-ROV: the *RPKI management plane* (where ROAs are created) and the *router control plane* (where BGP announcements are originated) *must remain independent*. They cannot be anchored to the same authoritative data source; otherwise, ROV would degenerate into a circular "self- verification" that defeats its purpose. Any operational tool or practice must respect this independence. With that principle in mind, the following measures are in use: * *Semi-automated ROA generation* (often integrated with IPAM) that reduces manual entry errors but still requires *human authorization* for each ROA. Fully automated "announcement- followed-by-ROA" would violate the independence principle, turning a *normative* security check into a *descriptive* one. * *Local RPKI static overrides (SLURM)* that allow an operator to locally correct stale or wrong RPKI data. These overrides are *site-specific and private* - they are not visible to other networks and cannot be relied upon by downstream ASes. * *Route caching and re-evaluation (RFC 9324)* that prevents route- refresh storms, but only operates on routes *already received and dropped*; it does not prevent the initial inconsistency from occurring. * *Work on faster publication-distribution protocols (e.g., ERIC)* that may reduce synchronization delays, but cannot eliminate them entirely - asynchrony is inherent in any distributed pull-based system. These measures are valuable for the networks that deploy them, yet they share *fundamental limitations* that prevent them from solving the core problem: Cheng, et al. Expires 24 December 2026 [Page 10] Internet-Draft RPKI-ROV Gap Analysis June 2026 * *Local or private, not interoperable*: SLURM, custom scripts, and per-network automation are not visible to other ASes. A downstream router *cannot know* whether an upstream has applied any of these mitigations. The information asymmetry remains. * *Reactive, not proactive*: They operate after an inconsistency has already caused route churn, blackholes, or path shifts. They do *not* prevent self-inflicted invalids from entering the global table in the first place. * *Cannot eliminate root causes*: Synchronization asymmetry is inherent to distributed systems; cross-plane errors (misconfigurations on either plane) cannot be fully eliminated by local tooling. No amount of automation can turn a descriptive "this is what we announce" into a normative "this is what is authorized" without breaking the independence principle. * *Lack of standardisation*: Many useful practices remain proprietary or informally documented. To benefit the wider community, they need to be *standardized, verifiable, and incrementally deployable* - not just locally effective. Thus, while operational best practices are valuable, they do *not* close the information gap. What is needed is a *standardized, verifiable, and incrementally deployable enhancement* to the existing RPKI-ROV framework - one that respects the independence of the two planes while enabling: * *Source-side cross-validation* to prevent self-inflicted invalids at the origin, and * *Downstream visibility* into whether the origin performed such validation and what result it obtained. Only with such an enhancement can the vicious cycle be broken and strict ROV drop policies be confidently adopted across all tiers of the Internet, including the long tail. 6. Informational Requirements for an Enhanced System To break the vicious cycle described in Section 3.4, the following informational capabilities are needed. These requirements are *functional* - they specify _what_ information is needed, not _how_ it is delivered. Cheng, et al. Expires 24 December 2026 [Page 11] Internet-Draft RPKI-ROV Gap Analysis June 2026 6.1. 6.1 Source-Side Cross-Validation The first line of defense is to minimize the injection of self- inflicted invalid routes at the source. *Requirement R1*: An originating AS that wishes to implement source- side consistency needs to perform cross-validation before advertising any route: check the intended announcement against its local RPKI cache. Routes that would be Invalid should not be announced; they should be logged and optionally cached for later re-evaluation. *Why this helps*: This reduces the volume of avoidable Invalid routes entering the global table. It also keeps the router control plane aligned with the RPKI management plane at the source. This can be achieved with operational guidance (a BCP) without new protocol extensions. 6.2. 6.2 Downstream Consistency Information Even with perfect source-side cross-validation, downstream routers still face ambiguity due to asynchronous RPKI propagation and uneven deployment across the Internet. To resolve this, downstream routers need *verifiable, timely information* about the origin's validation state. *Requirement R2*: A downstream router should be able to obtain, for each received route, at least the following pieces of information from the origin: * *Whether* the origin performed source-side cross-validation on this specific prefix. * *What the result was* (Valid or NotFound). * *When* that validation occurred (a timestamp), to assess freshness relative to the downstream's local VRP cache. *Requirement R3*: This information must be *verifiable* (cryptographically bound to the origin AS) to prevent forgery or denial by the origin. *Requirement R4*: The information should allow a downstream router to *reconcile a Local ROV = Invalid outcome* with the origin's attestation. Specifically: - If the origin attested Valid with a fresh timestamp, the downstream can infer that the Invalid is likely a sync delay and apply a lenient policy (e.g., lower LOCAL_PREF but do not drop). - If the attestation is absent, stale, or shows NotFound, the downstream falls back to traditional ROV. Cheng, et al. Expires 24 December 2026 [Page 12] Internet-Draft RPKI-ROV Gap Analysis June 2026 6.3. 6.3 Consistency Across Downstream Routers (Horizontal) Even with per-route attestations, different downstream routers with different cache ages may still reach inconsistent conclusions. The system should help routers *estimate the likelihood of inconsistency* so that they can avoid unnecessary divergence. *Requirement R5*: The timestamp from the origin should be usable by a downstream router to compare its own VRP cache age. If the local cache is significantly older than the attestation timestamp, the router can infer that its Invalid verdict may be a false positive and treat the route more conservatively. 6.4. 6.4 Relationship to Existing RPKI-ROV The capabilities described above are *enhancements, not replacements*. They do not change the core RPKI-ROV trust model or validation logic. Each router still performs its own independent ROV against its local VRP cache. The additional information only helps *reconcile discrepancies* caused by the inherent asynchrony of the system. The ultimate goal is to *accelerate deployment of strict ROV drop policies* across all network types - especially the long tail - by reducing fear of false positives and providing verifiable context for decision-making. 7. Conclusion RPKI-based ROV has achieved remarkable progress, but fundamental challenges remain: * *Technical root causes*: Synchronization asymmetry + error-prone planes. * *Consequences*: Operational harm (blackholes, path shifts, churn, long-lived outages) and security harm (unblocked hijacks, invisible attacks, alert fatigue). * *Derived barrier*: The long tail (stub and small ASes) hesitates to deploy strict ROV because they face disproportionate risk and lack visibility. Current operational mitigations (automation, SLURM, RFC 9324 caching) are valuable but cannot eliminate the architectural gaps. *What is needed is a standardized, verifiable, incrementally deployable enhancement* that provides: Cheng, et al. Expires 24 December 2026 [Page 13] Internet-Draft RPKI-ROV Gap Analysis June 2026 * *Source-side cross-validation* to prevent self-inflicted invalids. * *Downstream consistency information* (origin's validation result + timestamp) to reconcile local ROV outcomes with the origin's intent. These enhancements are *evolutionary*, not revolutionary. They preserve the existing RPKI-ROV framework, trust model, and validation logic. Their sole purpose is to add missing information that allows downstream routers to distinguish transient sync delays from persistent misconfiguration and from real attacks, reduce unnecessary churn and blackholes, and finally move ROV from "monitor" to "reject" with confidence. By closing the information gap, the enhancements can unlock the full security potential of RPKI-ROV and bring its benefits to the entire Internet - including the tens of thousands of networks that have hesitated to adopt it thus far. The community is encouraged to develop specific solutions that meet the informational requirements defined in this document, whether through BGP extensions, out-of-band mechanisms, or other approaches. 8. Security Considerations This document analyzes gaps in an existing security system (RPKI-ROV) and identifies informational requirements for enhancements. It does not introduce new security risks. Any future solution built on these requirements should be evaluated for its own security properties, including resistance to forgery, replay, and downgrade attacks. 9. IANA Considerations This document has no IANA actions. 10. References 10.1. Normative References [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, . [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, DOI 10.17487/RFC6811, January 2013, . Cheng, et al. Expires 24 December 2026 [Page 14] Internet-Draft RPKI-ROV Gap Analysis June 2026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 10.2. Informative References [RPKI_Time-of-Flight] "RPKI Time-of-Flight", March 2023, . [Demystifying_RPKI-Invalid_Prefixes] "Demystifying RPKI-Invalid Prefixes - Hidden Causes and Security Risks", February 2026, . Authors' Addresses Weiqiang Cheng China Mobile China Email: chengweiqiang@chinamobile.com Chongfeng Xie China Telecom China Email: xiechf@chinatelecom.cn Mingqing Huang Zhongguancun Laboratory China Email: huangmq@zgclab.edu.cn Dan Li Tsinghua University Beijing China Email: tolidan@tsinghua.edu.cn Cheng, et al. Expires 24 December 2026 [Page 15] Internet-Draft RPKI-ROV Gap Analysis June 2026 Nan Geng Huawei Technologies Beijing China Email: gengnan@huawei.com Cheng, et al. Expires 24 December 2026 [Page 16]