Information Asymmetry and Deployment Gaps in RPKI-based Route Origin Validation
draft-cheng-sidrops-rpki-rov-gap-analysis-00

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, <https://www.rfc-editor.org/info/rfc6480>.

   [RFC6811]  Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
              Austein, "BGP Prefix Origin Validation", RFC 6811,
              DOI 10.17487/RFC6811, January 2013,
              <https://www.rfc-editor.org/info/rfc6811>.

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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

10.2.  Informative References

   [RPKI_Time-of-Flight]
              "RPKI Time-of-Flight", March 2023,
              <https://dl.acm.org/doi/10.1007/978-3-031-28486-1_18>.

   [Demystifying_RPKI-Invalid_Prefixes]
              "Demystifying RPKI-Invalid Prefixes - Hidden Causes and
              Security Risks", February 2026, <https://www.ndss-
              symposium.org/ndss-paper/demystifying-rpki-invalid-
              prefixes-hidden-causes-and-security-risks/>.

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]