Source Pre-validation in RPKI-based Route Origin Validation

Introduction RPKI-based ROV has become a cornerstone of inter-domain routing security. Over 60% of IPv4 routes now have ROAs (), and a growing number of large transit providers actively reject RPKI-invalid routes. Despite these advances, thousands of RPKI-invalid routes () continue to appear in the global routing table. Research 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 by: - Mandating source pre-validation for all originating ASes when a covering ROA exists (whereas leaves deployment optional). - Extending the caching and re-evaluation concept from the inbound direction 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 an Autonomous System (AS) to originate routes . 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:

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

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

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

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

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.

Relationship to 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.

Relationship to 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.

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.

Core Requirements for Source Pre-validation

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.

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.

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. Already advertised routes are NOT automatically withdrawn due to VRP changes.

Operational Recommendations

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.

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.

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:

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.

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

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.

IANA Considerations This document has no IANA actions.