Source Pre-validation in RPKI-based Route Origin Validation
draft-huang-sidrops-source-pre-validation-00

sidrops                                                         M. Huang
Internet-Draft                                   Zhongguancun Laboratory
Intended status: Best Current Practice                             D. Li
Expires: 25 December 2026                            Tsinghua University
                                                                W. Cheng
                                                            China Mobile
                                                                  C. Xie
                                                           China Telecom
                                                                 Z. Wang
                                                     Huawei Technologies
                                                            23 June 2026

      Source Pre-validation in RPKI-based Route Origin Validation
              draft-huang-sidrops-source-pre-validation-00

Abstract

   The Resource Public Key Infrastructure (RPKI) and Route Origin
   Validation (ROV) have significantly improved inter-domain routing
   security.  However, thousands of RPKI-invalid routes - the vast
   majority caused by misconfiguration or synchronization delays -
   persistently appear in the global routing table.  Many of these self-
   inflicted invalid routes originate from autonomous systems (ASes)
   that could have easily blocked them before advertisement.

   This document defines a *Best Current Practice (BCP)* for *source
   pre-validation*: the practice by which an originating AS checks its
   intended BGP announcement against its local RPKI cache *before*
   sending it to eBGP neighbors.  Routes that would be evaluated as
   Invalid (or NotFound for strict mode) are blocked, logged, and *MUST
   be cached* for later re-evaluation, enabling automatic recovery when
   RPKI data changes.  Routes evaluated as Valid or NotFound(for default
   mode) may be advertised normally.

   This BCP complements existing standards RFC8893 & RFC9324 by focusing
   on *mandatory deployment at the origin* and on *outbound caching* of
   suppressed routes.  It provides operational guidance for deployment,
   cache management, and handling of RPKI data updates.  Implementation
   of this BCP reduces self-inflicted invalid routes, improves global
   routing stability, and encourages wider ROV adoption.

Status of This Memo

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

Huang, et al.           Expires 25 December 2026                [Page 1]
Internet-Draft            Source Pre-validation                June 2026

   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 25 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.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   6
     1.2.  Requirements Language . . . . . . . . . . . . . . . . . .   6
   2.  Relationship to Existing Standards  . . . . . . . . . . . . .   7
     2.1.  Relationship to RFC8893 . . . . . . . . . . . . . . . . .   7
     2.2.  Relationship to RFC9324 . . . . . . . . . . . . . . . . .   7
   3.  Core Requirements for Source Pre-validation . . . . . . . . .   8
     3.1.  Enabling Source Pre-validation  . . . . . . . . . . . . .   8
     3.2.  Pre-validation Execution (Triggered by Route
           Originating)  . . . . . . . . . . . . . . . . . . . . . .   9
     3.3.  Handling RPKI Cache Updates (Triggered by ROA Changes)  .   9
   4.  Operational Recommendations . . . . . . . . . . . . . . . . .  10
     4.1.  Logging and Alerting  . . . . . . . . . . . . . . . . . .  10
     4.2.  Consistent Deployment Across Multiple Border Routers  . .  10
     4.3.  ROA Creation and Strict Mode Recommendations  . . . . . .  10
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   6.  Operational Considerations  . . . . . . . . . . . . . . . . .  12
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  13

Huang, et al.           Expires 25 December 2026                [Page 2]
Internet-Draft            Source Pre-validation                June 2026

     8.2.  Informative References  . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   RPKI-based ROV has become a cornerstone of inter-domain routing
   security.  Over 60% of IPv4 routes now have ROAs ([NIST-Monitor]),
   and a growing number of large transit providers actively reject RPKI-
   invalid routes.  Despite these advances, thousands of RPKI-invalid
   routes ([NIST-Monitor]) continue to appear in the global routing
   table.  Research [Demystifying_RPKI-Invalid_Prefixes] shows that over
   96% of these invalid routes are *false positives* caused by
   misconfiguration or synchronization delays - not malicious hijacks.

   Many of these self-inflicted invalid routes originate from the very
   AS that announces them.  If the originating AS had checked its
   intended announcement against its local RPKI cache before advertising
   the route, it could have blocked the invalid route at the source,
   preventing it from ever entering the global routing system.

   *Source pre-validation* is that check.  It is a proactive,
   operationally straightforward practice that complements existing ROV
   mechanisms.  This document specifies a *Best Current Practice (BCP)*
   for source pre-validation, providing clear requirements and
   operational guidance for network operators.

   This BCP is *not* a new protocol.  It does not change BGP or RPKI
   semantics.  It builds upon existing standards [RFC8893] [RFC9324] by:
   - *Mandating* source pre-validation for all originating ASes when a
   covering ROA exists (whereas [RFC8893] leaves deployment optional). -
   *Extending* the caching and re-evaluation concept from the inbound
   direction [RFC9324] to the outbound direction, for routes suppressed
   at egress.

   The goal is to reduce the number of self-inflicted invalid routes,
   improve global routing stability, and encourage wider and more
   confident deployment of ROV drop policies across the Internet -
   including the long tail of stub and small regional ASes.

   *A foundational security principle* underpins the RPKI-ROV
   architecture: the *RPKI management plane* (where ROAs are created)
   and the *router control plane* (where BGP announcements are
   generated) *must remain independent*. They are not derived from a
   common authoritative data source.

   This principle is reflected in the very definition of a Route Origin
   Authorization (ROA): a ROA is a digitally signed object that provides
   a means of verifying that an *IP address block holder* has authorized

Huang, et al.           Expires 25 December 2026                [Page 3]
Internet-Draft            Source Pre-validation                June 2026

   an Autonomous System (AS) to originate routes [RFC9582].  The
   authority to sign a ROA belongs to the resource holder, not the
   network operator.  The router control plane, meanwhile, operates
   based on local configuration and routing policy.  These two planes
   have *different data origins and different error profiles*: -
   *Management plane errors* (e.g., ROA misconfigurations) tend to be
   systematic, often affecting entire prefixes or ASNs due to human
   oversight. - *Control plane errors* (e.g., announcing an unowned
   prefix or mis-setting the origin AS) tend to be operational, arising
   from router configuration mistakes.

   Because these error modes are *not correlated*, cross-validation
   between the two planes is meaningful.  A route that is misconfigured
   on the control plane will not, by coincidence, align with a
   misconfigured ROA on the management plane.  Cross-validation catches
   errors from either plane before they can affect global routing.

   Conversely, if the two planes were anchored to the same authoritative
   data source (e.g., if ROAs were automatically generated from BGP
   announcements), this independence would be lost.  Errors could become
   self-validating, defeating the purpose of ROV.  This is why
   preserving the independence of the two planes is a *non-negotiable
   design principle* for any operational practice that relies on RPKI-
   based validation.

   Self-inflicted invalid routes fall into two categories, each with a
   different root cause:

   1.  *Persistent misconfigurations*

       *  ROA errors (wrong ASN, incorrect maxLength, stale records)

       *  Router origin configuration errors (announcing a prefix not
          owned by the AS, wrong origin AS)

       *  *Effect*: The route is Invalid indefinitely until manually
          corrected.

   2.  *Transient inconsistencies due to synchronization asymmetry*

       *  The ROA exists and is correct, but the router's local VRP
          cache has not yet received the update (as measured by
          [RPKI_Time-of-Flight], delays average >10 minutes, maximum
          >100 minutes).

       *  *Effect*: The route is Invalid for a limited time window, then
          automatically becomes Valid once the cache catches up.

Huang, et al.           Expires 25 December 2026                [Page 4]
Internet-Draft            Source Pre-validation                June 2026

   Source pre-validation provides two distinct benefits that directly
   address these two categories:

   *  *Prevents persistent misconfigurations from ever entering the
      global table* By blocking Invalid routes at the origin, the AS
      cannot advertise a route that violates a ROA, regardless of
      whether the error is on the RPKI management plane or the router
      control plane.

   *  *Reduces the global impact of transient sync delays* When an
      originating AS performs pre-validation *at the time of route
      announcement*, it ensures that the route is only advertised when
      its local cache already reflects the correct ROA.  This
      effectively *compresses the synchronization window* from the
      perspective of the entire Internet.  As a result, downstream
      routers are less likely to encounter a Local ROV = Invalid
      situation caused purely by a delay at the origin's side.

      *Note*: Source pre-validation does not eliminate all transient
      false positives - because downstream routers may still have older
      caches than the origin.  However, it eliminates the portion of the
      delay that originates at the source, significantly reducing the
      overall incidence of such events.

   *Why control-plane pre-validation?*

   One might ask: could the same cross-validation be performed out-of-
   band, e.g., by checking ROA consistency against IPAM before route
   configuration is deployed to routers?

   Out-of-band checks can help catch persistent misconfigurations before
   they reach the control plane.  However, they *cannot* ensure that the
   router's local VRP cache is synchronized with the ROA state at the
   actual moment of route announcement.  The time gap between out-of-
   band validation and route origination still allows ROA updates to
   arrive in between, causing transient Invalid routes.

   Moreover, out-of-band validation relies on non-standardized IPAM
   implementations and internal operational workflows.  IPAM is not the
   actual point of route origination; the router control plane is the
   only place where BGP announcements are actually generated and sent.
   There is no standardized mechanism to guarantee that an out-of-band
   validation result remains valid at the time of announcement, nor that
   the route configuration actually deployed matches what was validated.

   Control-plane pre-validation addresses both gaps.  It executes *at
   the moment of route origination*, using the router's current local
   VRP cache.  It catches configuration errors *and* synchronization

Huang, et al.           Expires 25 December 2026                [Page 5]
Internet-Draft            Source Pre-validation                June 2026

   delays in one unified check, and it does so in a way that is
   independent of any particular IPAM system or operational workflow.
   This makes it a *standardizable, universally applicable practice*.

1.1.  Terminology

   *Originating AS*: The first AS in the BGP AS_PATH sequence; the AS
   that originates the route.

   *Source pre-validation*: The action of checking a self-originated BGP
   route against the local RPKI cache (VRP data) before advertising it
   to eBGP neighbors.

   *Local RPKI cache (VRP cache)*: The set of Validated ROA Payloads
   (VRPs) obtained from a Relying Party (RP) via the RPKI-RTR protocol
   [RFC8210].

   *Covering ROA*: A ROA that lists the local AS as the authorized
   origin AS for a prefix.

   *Valid route*: A route for which the local RPKI cache contains a
   covering ROA that authorizes the originating AS to announce the
   prefix.

   *Invalid route*: A route for which the local RPKI cache contains a
   covering ROA, but the originating AS does not match the authorized
   AS.

   *NotFound route*: A route for which the local RPKI cache contains no
   covering ROA.

   *Suppressed route*: A route that was evaluated as Invalid during
   source pre-validation (or as NotFound when strict mode is enabled)
   and therefore was not advertised to any eBGP neighbor.  The route is
   cached locally for later re-evaluation (see Section 3.3).

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

Huang, et al.           Expires 25 December 2026                [Page 6]
Internet-Draft            Source Pre-validation                June 2026

2.  Relationship to Existing Standards

   This document does not update or obsolete RFC8893 or RFC9324.
   Instead, it inherits and extends their principles to the specific
   case of source pre-validation.

2.1.  Relationship to RFC8893

   [RFC8893] defines how to correctly perform egress ROV when a BGP
   speaker chooses to do so.  Its main contribution is to clarify the
   handling of the "effective origin AS" (after private AS removal,
   confederation, etc.) in egress validation.

   This BCP inherits the validity of egress validation but shifts focus
   from "how to do it correctly" to "*that it MUST be done at the
   origin*".  Specifically:

   *  *Mandatory deployment*: RFC8893 does not require any network to
      deploy egress validation.  This BCP requires every originating AS
      to perform source pre-validation whenever a covering ROA exists.

   *  *Scope narrowed*: RFC8893 applies to egress validation at any AS
      along a path.  This BCP applies only to the *originating AS*.

   *  *Operational details*: RFC8893 does not specify what to do with
      routes that fail validation (e.g., logging, caching, alarming).
      This BCP provides such operational guidance.

   Thus, this BCP is an *operational enhancement* of RFC8893 for the
   origin, not a replacement.

2.2.  Relationship to RFC9324

   [RFC9324] addresses the route-refresh storm problem caused by ROV-
   dropped routes.  It requires routers to cache dropped routes (from
   Adj-RIB-In) and re-evaluate them when RPKI data changes.

   This BCP extends the "cache and re-evaluate" principle from the
   inbound direction to the *outbound direction*:

   *  When source pre-validation blocks a route (Invalid), that route
      MUST be cached locally (a form of "Adj-RIB-Out negative cache") to
      enable automatic recovery.

   *  When the local RPKI cache later changes (e.g., a missing ROA
      appears), the router MUST re-evaluate the suppressed route.  If it
      becomes Valid or NotFound, it MAY be advertised following normal
      BGP procedures.

Huang, et al.           Expires 25 December 2026                [Page 7]
Internet-Draft            Source Pre-validation                June 2026

   This extension ensures that transient conditions (e.g., a ROA that
   arrives after the route was first considered) do not permanently
   prevent a legitimate route from being announced, while still avoiding
   unnecessary BGP updates.

3.  Core Requirements for Source Pre-validation

3.1.  Enabling Source Pre-validation

   *Control Interface*

   Implementations SHOULD provide a configuration command to enable or
   disable source pre-validation, independent of any egress ROV
   configuration described in RFC8893.

   *Enabling State Machine*

   When source pre-validation is enabled by the operator, it enters the
   Enabling state.  It transitions to the Enabled state only after both
   conditions are satisfied:

   *  *RPKI-RTR session is operational*: The router has established a
      valid RPKI-RTR session and received a complete initial VRP cache.

   *  *Relevant ROA exists*: The local VRP cache contains at least one
      covering ROA (see terminology).

   Until both conditions are met, the router *MUST NOT* perform source
   pre-validation.

   *Monitoring and Fallback*

   Once in the Enabled state, the router SHOULD continuously monitor the
   two conditions:

   *  If either condition fails and remains unavailable for a
      configurable period, the router SHOULD transition back to Enabling
      and raise an alert.

   *  While in Enabling, the router MUST NOT perform pre-validation but
      SHOULD continue monitoring and auto-re-enter Enabled once
      conditions are satisfied again.

   *Disabling*

   When the operator issues a disable command, the router MUST
   immediately transition to the Disabled state.  Pre-validation is
   deactivated immediately.

Huang, et al.           Expires 25 December 2026                [Page 8]
Internet-Draft            Source Pre-validation                June 2026

3.2.  Pre-validation Execution (Triggered by Route Originating)

   *1.  Trigger Condition*

   For any route that an originating AS intends to advertise, if source
   pre-validation is Enabled (see 3.1), the router MUST perform pre-
   validation before advertising the route.

   *2.  Execution Timing*

   Pre-validation is performed after all egress policy processing has
   been applied, such that the route being checked matches the actual
   route announced to the eBGP peer.

   *3.  Handling Pre-validation Results*

   *  Valid: The route proceeds to normal BGP advertisement.

   *  Invalid: The route MUST NOT be advertised.  It MUST be cached,
      logged, and an alert SHOULD be raised.

   *  NotFound:

      -  Default mode: The route may be advertised (treated as Valid).

      -  Strict mode (see Section 4.3): NotFound is subject to the same
         actions as Invalid - blocked, cached, logged, alerted.

3.3.  Handling RPKI Cache Updates (Triggered by ROA Changes)

   When the local VRP cache is updated (e.g., due to ROA issuance,
   modification, revocation, or expiration), the router MUST re-evaluate
   any previously suppressed routes (those cached due to Invalid
   results, or NotFound results when strict mode is enabled).

   If a suppressed route becomes acceptable (i.e., Valid in both modes;
   or NotFound in default mode), it proceeds to normal BGP advertisement
   and MUST be removed from the suppressed cache.  If it remains
   unacceptable, it stays suppressed.

   Implementations SHOULD provide a configurable aging time for
   suppressed routes.  When a suppressed route exceeds the configured
   aging time without becoming acceptable, it SHOULD be removed from the
   suppress cache and the event SHOULD be logged.  A recommended default
   aging time is 24 hours, but operators MAY adjust this value based on
   local operational practices.

Huang, et al.           Expires 25 December 2026                [Page 9]
Internet-Draft            Source Pre-validation                June 2026

   Already advertised routes are NOT automatically withdrawn due to VRP
   changes.

4.  Operational Recommendations

4.1.  Logging and Alerting

   To assist operators in monitoring the operation of source pre-
   validation, implementations SHOULD provide logging and alerting for
   the following events:

   *  Suppressed routes: When a route is suppressed due to Invalid (or
      strict-mode NotFound), the router SHOULD log the prefix, origin
      AS, timestamp, and reason for suppression, and SHOULD raise an
      alert to notify operators.

   *  RPKI-RTR session failures: When the RPKI-RTR session remains down
      for longer than a configurable period, the router SHOULD log the
      event and raise an alert.

   *  Cache re-evaluation events: When a suppressed route becomes
      acceptable (i.e., Valid in both modes, or NotFound in default
      mode) and is subsequently advertised, the router MAY log this
      event at an informational severity level for troubleshooting
      purposes.

   *  Aging of suppressed routes: When a suppressed route is removed
      from the cache due to aging (see Section 3.3), the router SHOULD
      log the event to facilitate operational review and follow-up.

4.2.  Consistent Deployment Across Multiple Border Routers

   For an AS that operates multiple border routers originating routes,
   operators SHOULD strive to apply consistent pre-validation
   configuration and RPKI-RTR synchronization across all ASBRs.  This
   minimizes inconsistent outcomes for the same prefix advertised via
   different egress points.

   Minor inconsistencies due to different cache synchronization times
   are an inherent property of distributed systems and do not break the
   security model.  However, significant or persistent divergence SHOULD
   be investigated to avoid operational confusion.

4.3.  ROA Creation and Strict Mode Recommendations

   Operators who deploy source pre-validation are strongly encouraged to
   take the following steps to maximize the effectiveness of this
   practice:

Huang, et al.           Expires 25 December 2026               [Page 10]
Internet-Draft            Source Pre-validation                June 2026

   *  *Create ROAs for prefixes they own*: At a minimum, operators
      SHOULD create ROAs for all prefixes they hold and originate.  This
      ensures that their own legitimate announcements are properly
      covered and can be validated by downstream networks, while also
      reducing the likelihood of self-inflicted Invalid routes.

   *  *Adopt a "ROA-everywhere" policy*: Operators MAY take a more
      proactive approach by requiring that all routes originated within
      their network be covered by a ROA.  This can be achieved by
      enabling the strict mode described in Section 3.2, where NotFound
      is treated similarly to Invalid.  Before enabling strict mode,
      operators SHOULD ensure that all prefixes they intend to originate
      have appropriate ROA coverage to avoid unintended suppression of
      legitimate routes.

   *  *Preserve the independence of the two planes*: When using IPAM or
      other automation tools to generate ROAs, operators MUST ensure
      that the authorization decision is made by a human authority
      (e.g., the resource holder or designated approver).  Fully
      automated "announcement-followed-by-ROA" mechanisms MUST NOT be
      used, as they would effectively anchor the management plane and
      the control plane to the same data source, undermining the
      independence principle described in Section 1 and defeating the
      purpose of cross-validation.

   These recommendations are independent of whether source pre-
   validation is already deployed.  They represent good operational
   hygiene that benefits the entire Internet.

5.  Security Considerations

   Source pre-validation directly reduces the number of self-inflicted
   invalid routes.  By blocking Invalid routes at the source, it
   prevents:

   *  Unnecessary route churn and BGP update storms.

   *  Blackholes and path shifts caused by downstream ROV drops.

   *  Operational confusion (false positive alarms) that would otherwise
      require manual investigation.

   Potential risks and mitigations:

   *  *Stale cache leading to false blocking*: If the RPKI-RTR session
      fails and the cache becomes stale, a route that should be Valid
      might be incorrectly blocked.  This is mitigated by the monitoring
      and timeout recommendations in Section 3.1.

Huang, et al.           Expires 25 December 2026               [Page 11]
Internet-Draft            Source Pre-validation                June 2026

   *  *Misconfigured ROA causing legitimate route to be blocked*: If an
      operator mistakenly creates an overly restrictive ROA, source pre-
      validation will block the affected route.  This is not a new risk
      - the same ROA would have caused the route to be Invalid for
      downstream ROV anyway.  The BCP's logging and alerting help
      operators detect and correct such errors quickly.

   *  *Increased complexity*: Operators need to set up RPKI-RTR and
      monitor its health.  However, this is already a recommended
      practice for any network deploying ROV, and the additional steps
      for source pre-validation are minimal.

   *  *Infinite suppression due to never-resolved routes*: If a
      suppressed route is never resolved, it could remain in the cache
      indefinitely.  This is addressed by the configurable aging
      mechanism described in Section 3.3, which removes aged entries and
      logs the event.

   This BCP does not introduce new security vulnerabilities.  It relies
   on the existing RPKI trust model and BGP protocol semantics.

6.  Operational Considerations

   *  *Backward compatibility*: Routers that do not implement this BCP
      continue to operate as before.  No changes are required on
      neighboring routers.

   *  *Incremental deployment*: An AS can enable source pre-validation
      for a subset of its prefixes (e.g., those with clean ROA coverage)
      and gradually expand to others.  The BCP does not require
      immediate full compliance.

   *  *Performance impact*: The additional lookup into the local VRP
      cache is lightweight.  For routers that already perform ingress
      ROV, the computational cost of also performing egress checks is
      negligible.

   *  *Troubleshooting*: When a route is suppressed, operators should
      check: 1) Whether source pre-validation is in the Enabled state
      (see Section 3.1). 2) The local VRP cache to see if a covering ROA
      exists and whether it correctly authorizes the originating AS and
      prefix length. 3) Whether strict mode is enabled, which would
      cause NotFound routes to be suppressed.

   Correcting the ROA or the BGP configuration will resolve the issue,
   and the suppressed route will be re-evaluated automatically
   (Section 3.3) once the VRP cache changes.

Huang, et al.           Expires 25 December 2026               [Page 12]
Internet-Draft            Source Pre-validation                June 2026

7.  IANA Considerations

   This document has no IANA actions.

8.  References

8.1.  Normative References

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

   [RFC8210]  Bush, R. and R. Austein, "The Resource Public Key
              Infrastructure (RPKI) to Router Protocol, Version 1",
              RFC 8210, DOI 10.17487/RFC8210, September 2017,
              <https://www.rfc-editor.org/info/rfc8210>.

   [RFC9582]  Snijders, J., Maddison, B., Lepinski, M., Kong, D., and S.
              Kent, "A Profile for Route Origin Authorizations (ROAs)",
              RFC 9582, DOI 10.17487/RFC9582, May 2024,
              <https://www.rfc-editor.org/info/rfc9582>.

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

8.2.  Informative References

   [RFC8893]  Bush, R., Volk, R., and J. Heitz, "Resource Public Key
              Infrastructure (RPKI) Origin Validation for BGP Export",
              RFC 8893, DOI 10.17487/RFC8893, September 2020,
              <https://www.rfc-editor.org/info/rfc8893>.

   [RFC9324]  Bush, R., Patel, K., Smith, P., and M. Tinka, "Policy
              Based on the Resource Public Key Infrastructure (RPKI)
              without Route Refresh", RFC 9324, DOI 10.17487/RFC9324,
              December 2022, <https://www.rfc-editor.org/info/rfc9324>.

   [NIST-Monitor]
              "NIST RPKI Monitor", n.d.,
              <https://rpki-monitor.antd.nist.gov/>.

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

Huang, et al.           Expires 25 December 2026               [Page 13]
Internet-Draft            Source Pre-validation                June 2026

   [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

   Mingqing Huang
   Zhongguancun Laboratory
   China
   Email: huangmq@zgclab.edu.cn

   Dan Li
   Tsinghua University
   Beijing
   China
   Email: tolidan@tsinghua.edu.cn

   Weiqiang Cheng
   China Mobile
   China
   Email: chengweiqiang@chinamobile.com

   Chongfeng Xie
   China Telecom
   China
   Email: xiechf@chinatelecom.cn

   Zhiyuan Wang
   Huawei Technologies
   Beijing
   China
   Email: wangzhiyuan51@huawei.com

Huang, et al.           Expires 25 December 2026               [Page 14]