RPKI-based Validation with Prioritized Resource Data
draft-zhang-sidrops-prioritized-route-validation-02

sidrops                                                         J. Zhang
Internet-Draft                                   Zhongguancun Laboratory
Intended status: Informational                                     M. Xu
Expires: 24 December 2026                                         CERNET
                                                                 N. Geng
                                                                  Huawei
                                                                  C. Xie
                                                           China Telecom
                                                                 Y. Wang
                                                     Tsinghua University
                                                            22 June 2026

          RPKI-based Validation with Prioritized Resource Data
          draft-zhang-sidrops-prioritized-route-validation-02

Abstract

   The Resource Public Key Infrastructure (RPKI) provides globally
   verifiable signed routing security data, such as Route Origin
   Authorizations (ROAs).  Operators also commonly use local or
   supplemental data sources, including SLURM files, operator-maintained
   exceptions, IRR-derived inputs, and other operator-selected
   supplemental data, to improve local routing decisions.  These sources
   may not have the same authority as signed RPKI objects and therefore
   may require operator-configured priority-safe handling.

   This document describes a framework for RPKI-based validation with
   prioritized resource data.  It defines priority-safe handling
   semantics that allow operators to use data sources with different
   levels of authority or assurance for local routing policy, while
   preserving the global authorization semantics of signed RPKI data.
   The document also discusses deployment models with different
   implementation costs and operational trade-offs.

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

Zhang, et al.           Expires 24 December 2026                [Page 1]
Internet-Draft          Prioritized Resource Data              June 2026

   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 . . . . . . . . . . . . . . . . . .   3
   2.  Problem Statement and Gap Analysis  . . . . . . . . . . . . .   3
     2.1.  Local Supplemental Data Is Already Used . . . . . . . . .   4
     2.2.  Unsafe Mixing of Data Sources . . . . . . . . . . . . . .   4
   3.  Framework . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Priority-Safe Validation Semantics  . . . . . . . . . . . . .   5
     4.1.  Preserve Provenance and Priority Context  . . . . . . . .   5
     4.2.  Preserve Authoritative RPKI Semantics . . . . . . . . . .   6
     4.3.  Conflict Resolution . . . . . . . . . . . . . . . . . . .   6
     4.4.  Result Model  . . . . . . . . . . . . . . . . . . . . . .   6
     4.5.  Path Validation Evidence Aggregation  . . . . . . . . . .   6
   5.  Deployment Models . . . . . . . . . . . . . . . . . . . . . .   7
     5.1.  Model A: Multi-Cache or Multi-Table . . . . . . . . . . .   7
     5.2.  Model B: Single Table with Session-Configured Priority  .   7
     5.3.  Model C: RTR Metadata or Tagging Extension  . . . . . . .   8
   6.  Deployment Considerations . . . . . . . . . . . . . . . . . .   8
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

Zhang, et al.           Expires 24 December 2026                [Page 2]
Internet-Draft          Prioritized Resource Data              June 2026

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

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.  Problem Statement and Gap Analysis

Zhang, et al.           Expires 24 December 2026                [Page 3]
Internet-Draft          Prioritized Resource Data              June 2026

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

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

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

Zhang, et al.           Expires 24 December 2026                [Page 4]
Internet-Draft          Prioritized Resource Data              June 2026

          +---------------------+       +------------------------+
          | Authoritative RPKI  |       | Supplemental Sources   |
          | Signed RPKI data   |       | SLURM/IRR/local data  |
          +----------+----------+       +-----------+------------+
                     |                              |
                     v                              v
          +---------------------+       +------------------------+
          | RPKI RP / Cache     |       | Supplemental Cache     |
          | local priority: high|       | local priority: lower  |
          +----------+----------+       +-----------+------------+
                     |                              |
                     | existing RTR sessions,       |
                     | local APIs, or metadata      |
                     v                              v
                +------------------------------------------+
                | Router validation tables, priority-aware |
                | merge logic, or metadata-aware policy    |
                +----------------------+-------------------+
                                       |
                                       v
                            BGP route selection policy

   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.

4.  Priority-Safe Validation Semantics

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

Zhang, et al.           Expires 24 December 2026                [Page 5]
Internet-Draft          Prioritized Resource Data              June 2026

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

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

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

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

Zhang, et al.           Expires 24 December 2026                [Page 6]
Internet-Draft          Prioritized Resource Data              June 2026

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

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

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

Zhang, et al.           Expires 24 December 2026                [Page 7]
Internet-Draft          Prioritized Resource Data              June 2026

   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.

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

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

Zhang, et al.           Expires 24 December 2026                [Page 8]
Internet-Draft          Prioritized Resource Data              June 2026

   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.

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

8.  IANA Considerations

   This document has no IANA action.

9.  References

Zhang, et al.           Expires 24 December 2026                [Page 9]
Internet-Draft          Prioritized Resource Data              June 2026

9.1.  Normative References

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

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

Authors' Addresses

   Jia Zhang
   Zhongguancun Laboratory
   Beijing
   China
   Email: zhangj@zgclab.edu.cn

   Mingwei Xu
   CERNET
   Beijing
   China
   Email: xmw@cernet.edu.cn

   Nan Geng
   Huawei
   Beijing
   China
   Email: gengnan@huawei.com

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

Zhang, et al.           Expires 24 December 2026               [Page 10]
Internet-Draft          Prioritized Resource Data              June 2026

   Yangyang Wang
   Tsinghua University
   Beijing
   China
   Email: wangyy@cernet.edu.cn

Zhang, et al.           Expires 24 December 2026               [Page 11]