RPKI-based Validation with Prioritized Resource Data

Introduction RPKI Route Origin Authorizations (ROAs) and other signed RPKI objects provide a practical and globally verifiable basis for routing security. Route Origin Validation (ROV), for example, uses ROAs to classify a route as Valid, Invalid, or NotFound/Unknown. The semantics of signed RPKI data are intentionally simple and strong: an RPKI object expresses authorization by the relevant resource holder and is validated according to the RPKI trust model. Operational routing environments, however, often contain additional information that can be useful for local decision making. Examples include SLURM files, operator-maintained allow or deny lists, IRR-derived route objects, customer-maintained records, and other operator-selected supplemental data. These inputs may be useful, but they are not equivalent to signed RPKI objects. Treating them as indistinguishable from authoritative RPKI data can create unsafe routing behavior and can make troubleshooting difficult. In addition, validation results are consumed by routing policy and route selection, where operators commonly use actions beyond simple accept or reject, such as depreference, monitoring, local exception handling, or preference adjustment. Operator-configured priority can therefore provide operational flexibility without changing the authorization semantics of signed RPKI data. Such priority may be based on data source, assurance level, operational policy, or other local criteria. This document describes a priority-safe framework for using such data in local RPKI-based route validation. The framework is intended to apply to RPKI-based validation mechanisms including ROA-based origin validation and ASPA-based path validation. It keeps signed RPKI semantics intact, supports provenance and auditability where needed, and defines deployment models that range from no RTR or router changes, to router-side priority-aware merging, to explicit RTR metadata support. The primary purpose is to document interoperable operational semantics and deployment guidance, rather than to require changes to the global RPKI architecture.

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.

Problem Statement and Gap Analysis

Local Supplemental Data Is Already Used Operators already use local data in addition to RPKI data. SLURM allows a relying party or local cache to add assertions and filters for local use. Some networks derive supplemental route-origin information from IRR data or from customer provisioning systems. These practices show that local augmentation is operationally relevant, but they do not by themselves define common semantics for priority, provenance, conflict resolution, monitoring, or rollback. Priority is useful when different sources have different authority or assurance. If a supplemental source is considered equivalent to signed RPKI data in a local deployment, it can be assigned the same priority. If only authoritative RPKI data is used, priority differentiation is generally unnecessary.

Unsafe Mixing of Data Sources A central gap is that data sources with different authority may be mixed before validation. If a lower-assurance source is merged into the same validation table as signed RPKI data, a router may be unable to distinguish an Invalid result derived from signed RPKI data from an Invalid result derived from a supplemental source. This can lead to overly aggressive filtering, operational surprises, or a loss of confidence in RPKI-based validation. The reverse conflict is also important. A lower-priority Valid assertion must not be allowed to override a higher-priority Invalid result derived from authoritative RPKI data. Without explicit conflict rules, adding supplemental data can accidentally weaken the protection provided by RPKI.

Framework The framework separates three functions: data collection, priority-aware import or merging, and routing policy. In this document, authoritative RPKI data refers to signed RPKI data validated under the RPKI trust model, and supplemental data refers to local or external data used by an operator to inform local routing decisions. Priority-safe validation means that lower-priority data can supplement local decisions but cannot silently override higher-priority data or authoritative RPKI semantics. These functions may be implemented in different places depending on the deployment model. The framework is intentionally local. A network operator may use supplemental data to influence its own routing policy, but this document does not make such data globally authoritative and does not require other networks to consume it. Signed RPKI data remains distinguishable from supplemental data throughout the local validation process. The framework also separates validation semantics from deployment mechanisms. The same priority-safe behavior can be realized by multiple existing caches and route tables, by a router-side priority-aware merge of multiple RTR sessions, or by explicit metadata support where such support is available.

Priority-Safe Validation Semantics

Preserve Provenance and Priority Context Implementations SHOULD preserve enough provenance and priority context for validation inputs at least until local policy has been applied. The priority assigned by an operator may be based on data source, assurance level, operational role, or other local criteria. If inputs are merged before policy evaluation, the implementation SHOULD keep enough information for audit, troubleshooting, and rollback.

Preserve Authoritative RPKI Semantics Supplemental data MUST NOT silently override a validation result derived from higher-priority authoritative RPKI data. In particular, a lower-priority Valid assertion MUST NOT cause a route that is Invalid under authoritative RPKI data to be treated as fully Valid. An operator may still define an explicit local exception, but that exception needs to be visible as local policy rather than as ordinary RPKI validity.

Conflict Resolution When multiple sources produce conflicting results, implementations SHOULD apply a deterministic conflict-resolution rule. A common default is highest-priority-wins, with ties resolved by the underlying validation algorithm or by an operator-configured merge rule. Implementations SHOULD report when a lower-priority source conflicts with a higher-priority source, since such conflicts are useful for correcting data and for assessing operational risk. Lower-priority Invalid results are useful, but they are usually not equivalent to authoritative RPKI Invalid results. Implementations can expose the configured priority and conflict information to local policy so that operators can select the appropriate action for each deployment.

Result Model A priority-aware result can be represented as a tuple consisting of the ordinary validation state, the configured priority or other context used to derive the state, and any conflict indicators. For example, an implementation may distinguish "Invalid by authoritative RPKI" from "Invalid by supplemental IRR-derived data" while still preserving the ordinary Valid/Invalid/Unknown state for compatibility with existing policy systems.

Path Validation Evidence Aggregation Path validation may use multiple pieces of evidence along an AS path. If those pieces of evidence come from sources with different priorities, the final validation result needs to preserve the priority of the evidence that actually determines the result. For example, if high-priority evidence is sufficient to identify an invalid relationship or path segment, the result should expose that high-priority invalid indication even if lower-priority evidence was also consulted. This document states the general principle; mechanism-specific specifications can define the exact aggregation algorithm.

Deployment Models This document defines three deployment models, ordered by implementation cost and explicitness of priority signaling. Model A uses existing multiple caches or validation tables and may require no RTR protocol change and no router implementation change where such features already exist. Model B keeps the RTR protocol unchanged but requires router-side support to merge multiple RTR sessions into one validation table according to locally configured session priorities. Model C carries explicit priority and optional provenance metadata in RTR data and therefore requires both RTR protocol support and router support.

Model A: Multi-Cache or Multi-Table In this model, different priority classes or input groups are delivered through separate existing RTR sessions, separate cache instances, separate local files, or separate router validation tables. The router policy then compares separated validation results and applies priority-specific or input-specific actions. For example, authoritative RPKI data can be evaluated in one table, while supplemental IRR-derived or local data is evaluated in another table. The priority relationship is configured by local router policy rather than encoded in RTR or in the validation payload. Model A requires no change to RPKI object formats, no change to the RTR protocol, and no global change to RPKI semantics. Where routers already support multiple RTR sessions, multiple validation tables, or equivalent policy mechanisms, Model A can also be deployed without router implementation changes.

Model B: Single Table with Session-Configured Priority In this model, a router imports multiple RTR sessions or equivalent validation-data inputs into a single local validation table. Each session or input is assigned a local priority, and optionally other local classification, by router configuration. The RTR payload itself is unchanged; priority is associated with the session or input, not carried in each RTR object. The router applies priority-aware merge and conflict-resolution rules when constructing the single validation table. Model B does not require RTR protocol changes, but it does require router-side support for priority-aware merging of multiple inputs. Compared with Model A, it can reduce policy complexity because the router maintains one merged validation table instead of requiring route policy to compare several separated validation tables. Implementations SHOULD expose which input source and merge rule produced each entry through logs, counters, or management interfaces.

Model C: RTR Metadata or Tagging Extension In this model, validation data or validation results carry explicit priority, policy, and optional provenance metadata in RTR data or in an equivalent standardized tagging mechanism. In contrast to Model B, priority is not only associated with the RTR session or local input; it is carried with the validation data itself and remains visible to downstream policy logic, such as a router or another policy engine. Such metadata can support finer-grained policy, but it requires protocol and router support. Model C is optional. Deployments that do not support explicit metadata can still implement the priority-safe semantics using Model A or Model B. This document therefore does not require an RTR protocol extension for baseline deployment.

Deployment Considerations Operators can choose among the deployment models according to implementation cost, policy complexity, rollout requirements, and audit requirements. A practical deployment can start with the least disruptive model that provides the needed priority separation. Model A is suitable when existing router policy and multiple validation tables are sufficient. Model B is suitable when an operator wants a single validation table and can deploy router-side support for priority-aware merging of multiple RTR sessions or validation-data inputs. Operators may map configured priorities to local policy actions such as monitoring, depreference, rejection, or explicit local exception handling according to their own risk tolerance and operational requirements. Model A can be used as a low-disruption baseline for short-term deployment, experimentation, and implementation experience because it can rely on existing RTR sessions, validation tables, and router policy. Operators can use existing routing policy to distinguish drop, deprefer, warn, or monitor actions by configured priority, input group, or other local classification. When the number of priority classes, input groups, routers, or policy variants grows, operators may need consistent policy updates, staged rollout, rollback, and audit across multiple devices. Model B can centralize merge behavior inside the router validation subsystem, which may simplify route-policy configuration at the cost of router-side implementation support. Model C can expose priority and optional provenance metadata to downstream policy logic where explicit RTR metadata support is available. Implementations and deployments should expose provenance, conflict counters, data freshness, and the policy action selected for each configured priority or input group. These outputs help operators verify that supplemental data remains separate from authoritative RPKI data and that local exceptions are auditable and reversible.

Security Considerations The main security risk in this document is that lower-assurance data may be mistaken for authoritative RPKI data. Implementations and operational profiles need to preserve that distinction. Supplemental data can improve local visibility and coverage, but it can also introduce false positives, false negatives, stale assertions, or policy mistakes. Lower-priority data MUST NOT silently weaken authoritative RPKI validation. In particular, a route that is Invalid under signed RPKI data cannot become ordinary Valid merely because a supplemental source says so. If an operator intentionally overrides such a result, the override is local policy and needs to be logged and observable. Deployments need freshness and availability controls. If authoritative RPKI data becomes stale or unavailable, automatically falling back to lower-priority data can cause large routing changes. Implementations SHOULD expose stale-source alarms and allow operators to choose fail-open, fail-closed, or monitor-only behavior per configured priority or input group. Supplemental data sources require additional care. They should be treated as local evidence unless and until they have an independent authorization basis. Operators should monitor disagreement between supplemental data and authoritative RPKI data, and should use such disagreement to improve data quality rather than to obscure authoritative validation results.

IANA Considerations This document has no IANA action.