Considerations for Incremental Validation in RPKI Relying Parties

Introduction RPKI Relying Parties (RPs) validate resource certificates and signed objects, such as Route Origin Authorizations (ROAs) and Autonomous System Provider Authorization (ASPA) objects, to derive validated payloads for use in routing security. The validation process evaluates objects in the context of the applicable certification relationships, resource authorizations, manifests, Certificate Revocation Lists (CRLs), and validation time. These checks ensure that the resulting validated payloads reflect the applicable RPKI validation rules and the current validation context. Repository synchronization and validation are distinct operations. Repository synchronization mechanisms, such as the RPKI Repository Delta Protocol (RRDP) , can incrementally retrieve repository changes without requiring the complete retrieval of all repository data after every update. However, incremental synchronization does not necessarily imply incremental validation. After an incremental repository update, an RP may still repeat validation processing for many unchanged objects. Such processing may include parsing and decoding object contents, verifying cryptographic signatures, evaluating certificate and signed-object validity, and deriving validated payloads. Incremental validation aims to reduce repeated validation work by retaining state from previous validation cycles and reusing it when the information relevant to a validation result remains applicable to the current repository snapshot and validation context. Different approaches may retain different kinds of state and therefore differ in the amount of work they can avoid and the state they need to maintain. Regardless of the approach used, for the same repository snapshot, trust anchor set, validation policy, validation time, and applicable RPKI validation rules, incremental validation is expected to produce the same validated payload output as full validation. This document discusses the operational problem and design space of incremental validation in RPs, together with general principles for correct reuse, failure handling, and security considerations. It does not define a particular incremental validation algorithm, mandate a specific cache structure, or require all RP implementations to adopt incremental validation. It does not change RPKI object formats, repository synchronization protocols, or the validation semantics defined by the applicable RPKI specifications.

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.

Operational Problem

Repository Synchronization and Validation RPKI repository synchronization and validation address different tasks. Repository synchronization updates the local set of repository data, while validation determines which objects are valid under the applicable RPKI specifications and derives validated payloads from valid payload-carrying signed objects. The RPKI Repository Delta Protocol (RRDP) supports incremental synchronization through delta files when applicable, allowing an RP to retrieve repository changes without retrieving a complete repository snapshot for every update. However, reducing the amount of data transferred during synchronization does not necessarily reduce the amount of validation work performed afterward. For example, consider a CA publication point containing many RPKI objects, including ROAs. When a ROA changes, the corresponding manifest must reflect the current object set and the hash of the changed object. The RP needs to process the current manifest and check the objects it references against the current repository data. Even if most other objects referenced by the manifest remain unchanged, an RP that performs full validation after each synchronization cycle may repeat parsing and decoding, cryptographic signature verification, certificate and signed-object validation, and validated payload generation for those unchanged objects. Similar repeated processing may occur for subordinate CA certificates and objects in other parts of the RPKI tree.

Operational Impact Repeated validation processing can affect RP operation in several ways:

Validation latency and payload freshness: Validation processing contributes to the time between the availability of updated repository data and the production of updated validated payloads. Even when repository synchronization completes quickly, repeated validation work may delay the availability of the resulting payloads. Reducing unnecessary validation work may shorten validation cycles and enable RPs to validate more frequently, thereby improving validated payload freshness.
Computational and memory resource consumption: Repeated parsing, cryptographic verification, and other validation operations can increase CPU consumption. Processing large numbers of objects may also increase transient memory requirements. At the same time, retaining cached validation state introduces its own memory, storage, and maintenance costs. The benefits of incremental validation therefore depend not only on the processing time avoided, but also on the resources required to maintain and use the cached state.
Growth in RPKI data and future cryptographic transitions: As the number and size of RPKI objects increase, the amount of work performed during a full validation cycle may also increase. This can place additional pressure on validation latency and computational resources, particularly when only a portion of the repository changes between successive validation cycles. In addition, a future transition to post-quantum cryptography (PQC), if adopted for RPKI, may change cryptographic verification costs, signature sizes, and other processing requirements. These potential changes provide an additional reason to consider approaches that avoid unnecessary repeated processing.

Terminology The following terms are used in this document.

Full Validation: Validation of the objects currently reachable from the accepted trust anchors in a repository snapshot, under the applicable RPKI validation rules and current validation context, without reusing previously computed validation state to skip otherwise applicable validation processing.
Incremental Validation: A validation process that uses state retained from an earlier validation cycle to avoid repeating selected validation processing, while accounting for changes to the current repository data, validation dependencies, and validation context. Incremental validation is intended to produce the same validated payload output as full validation under the same inputs and applicable validation rules.
Validation Cycle: A single execution of validation for a repository snapshot under a given validation context.
Cached Validation State: Validation results or intermediate data retained from an earlier validation cycle for possible reuse. Depending on the approach, this state may include signature-verification results, parsed-object data, object-validation results, or PP-level validation state.
Effective Resource Context: The effective set of IP address and AS number resources of a CA, as determined by the applicable RPKI validation rules. This resource set provides the resource authorization context for validating the RPKI objects published by that CA at its publication point.
Validated Payload: Information derived from a successfully validated payload-carrying RPKI signed object. Depending on the object type, this may include VRPs, VAPs, or Router Keys. The validated payload output of a validation cycle is the collection of such information produced for that cycle.

General Principles for Correct Incremental Validation The following principles describe how an RP can reuse cached validation state while preserving the results of full validation.

Equivalence with Full Validation. For the same repository snapshot, trust anchor set, validation policy, validation time, and applicable RPKI validation rules, incremental validation is expected to produce the same validated payload output as full validation. Reusing previously computed validation state must not change the validation result for the current inputs.
Top-Down Validation and Current Object Reachability. The RP must process the current RPKI validation tree top-down, starting from the trust anchors accepted for the current validation cycle, and determine which objects are currently reachable through valid certification relationships. Cached validation state may be used to avoid repeating validation checks, but it must not bypass the determination of current object reachability. Only objects that are currently reachable and valid can contribute to the validated payload output.
Object Identity and Current Publication State. Before reusing a cached validation result, the RP must establish that the current object corresponds to the object represented by the cached result and belongs to the current publication state defined by the manifest. The object's content must match the hash specified in the current manifest. An object that is no longer included in the current manifest must not contribute to the current output solely because its previous validation result remains cached.
Current Validation Context and Dependencies. A cached validation result can be reused only when the conditions affecting that result remain satisfied. These include, as applicable, the current validation time and certificate validity intervals, CRL and revocation status, effective IP address and AS number resources, trust anchor set, and validation policy. When one of these conditions changes, the RP must reassess the cached results that depend on it. Results that remain applicable may still be reused; affected results must be re-evaluated as necessary.
Unavailable or Inconsistent Cached State. If required information is missing, cached state is inconsistent with the current repository data, or its integrity cannot be established, the RP must not assume that the affected results remain valid. The RP should revalidate the affected objects and their dependent validation state, or perform full validation when necessary.

Incremental Validation Design Space

Signature-Verification Result Caching Basic approach. Signature-verification result caching retains the result of a previously successful cryptographic signature verification for possible reuse in a later validation cycle. It aims to avoid repeating the cryptographic computation when the same verification operation is encountered again. Cached information. An implementation using this approach needs to retain sufficient information to identify a signature-verification operation and its result. Such information may include:

The signed input used by the signature-verification operation, or its digest where applicable.
The signature value.
The public key used for verification.
The signature algorithm and its relevant parameters.
The successful verification result.

Reuse conditions. A cached successful result can be reused only when the current verification operation uses the same signed input, signature value, public key, algorithm, and relevant parameters as the operation recorded in the cache. If no matching successful result exists, or any of these inputs differs, the RP needs to perform the cryptographic signature verification again. Checks still required. Reusing a signature-verification result does not establish that the RPKI object is valid. The RP must still perform the other applicable validation checks for the object under the current validation context. Depending on the object type, these checks may include certificate and signed-object validity intervals, certificate revocation status, resource authorization, consistency with the current manifest, and other requirements defined by the applicable RPKI specifications. A cached signature-verification result cannot replace these checks or determine whether the object can contribute to the current validated payload output. Applicability and limitations. This approach can be applied to signature-verification operations for different RPKI object types without requiring the RP to cache the complete validation state of each object. Its main benefit is avoiding repeated cryptographic computations when the verification inputs remain unchanged. However, it does not, by itself, avoid the parsing and decoding needed to obtain the verification inputs, other object-validation checks, or validated payload generation. Its benefit may be greater when signature verification accounts for a substantial share of the total validation cost. A future transition to post-quantum cryptography (PQC) may change signature-verification costs and could increase the value of this approach if verification becomes more computationally expensive.

Object-Validation-State Caching Basic approach. Object-validation-state caching reuses the validation result previously computed for an individual RPKI object. When the object and the conditions affecting its validation remain unchanged, an RP can reuse the cached result instead of repeating object parsing, cryptographic signature verification, and other validation processing that is no longer necessary. This approach allows an RP to reuse the results for unchanged objects even when other objects in the same publication point have changed. Cached information. An implementation using this approach needs to retain sufficient information to identify the object, determine the context under which it was validated, and recover its previous validation result. Such information may include:

An identifier for the object.
The identity of the parent CA and its effective IP address and AS number resources under which the object was validated.
The relevant validity intervals.
The serial number of the certificate whose revocation status affects the object.
The previous validation status and, for an object that failed validation, the failure reason when needed to determine whether the cause of failure has changed.
For a valid manifest, the filenames and corresponding hashes of the objects it lists.
For a valid CRL, the serial numbers of revoked certificates.
For valid payload-carrying objects, the derived validated payload, such as VRPs or VAPs, as applicable. For valid subordinate CA certificates, the effective resources needed to continue processing their publication points.

Reuse conditions. A cached validation result can be reused when the current object corresponds to the cached object, is included in the current manifest with content matching the hash specified in that manifest, and is reached through a parent CA whose identity and effective resources match those associated with the cached result. Checks still required. Before using the cached result, the RP needs to check the object's relevant validity intervals against the current validation time and consult the current valid CRL to determine whether the relevant certificate is revoked. If a previously valid object is no longer valid at the current validation time, or the relevant certificate is revoked, the cached successful result cannot be used to treat the object as valid in the current validation cycle. If a previous validation failure occurred because the validation time was earlier than the object's notBefore time, and the current time has since entered its validity interval, the object needs to be fully validated before it can be treated as valid. Similarly, if a previous failure was caused by certificate revocation and the current valid CRL no longer lists the relevant certificate as revoked, the object needs to be validated again before it can be treated as valid. Use of cached results. After the required checks succeed, the cached result can be used in the current validation cycle. For a valid payload-carrying object, its cached validated payload can contribute to the current output. For a valid subordinate CA certificate, the RP can use its effective resources to continue processing the subordinate CA's publication point, where the applicability of cached results must be determined separately. Applicability and limitations. Object-validation-state caching can reduce repeated processing for individual objects without requiring an entire publication point to remain unchanged. Its effectiveness depends on how frequently cached object results remain applicable and on the cost of maintaining and checking the associated state. It requires the RP to determine reuse eligibility for each object and to account for changes in the object's parent CA context, validity, and revocation status.

Manifest-/Publication-Point-Level Reuse Basic approach. A CA publishes its RPKI objects at a publication point (PP). The manifest associated with the PP identifies the expected set of published objects and records their hashes. Although the manifest is an object and the PP is a publication location, both are directly associated with the set of objects published by the CA. This document therefore discusses reuse of validation state for this set as one design category, referred to as manifest-/publication-point-level reuse. This approach treats the validation state associated with a CA's PP as a unit for reuse. When the relevant inputs and validation context remain unchanged, an RP can reuse the cached state for the entire PP instead of repeating full validation of the manifest and each object. This can avoid substantial processing when a PP remains unchanged between validation cycles. Cached information. An implementation using this approach needs to retain sufficient state to determine whether the cached PP result remains applicable and to reconstruct the result for the current validation cycle. Such state may include:

The identity of the CA certificate and the effective IP address and AS number resources under which the PP was validated.
The identity and validity interval of the manifest and CRL.
For each object listed in the manifest, its identity, validation status, and relevant validity interval. A failure reason may also be retained when it helps determine whether a previous validation failure can be resolved in a later cycle.
For valid payload-carrying objects, the derived validated payload. For valid subordinate CA certificates, the effective resources needed to continue processing their PPs.

Reuse conditions. Whole-PP reuse can be considered when the following conditions hold:

The CA certificate accepted in the current top-down validation corresponds to the CA certificate associated with the cached PP state.
The current effective resources of the CA match those recorded in the cached state.
The current manifest and CRL are unchanged from their cached versions and remain valid at the current validation time.
All objects listed in the current manifest are present in the current repository, and their contents match the hashes recorded in the manifest.

Checks still required. Even when the conditions for whole-PP reuse hold, the RP needs to check the validity intervals of the cached objects against the current validation time. An object that is no longer valid at the current validation time cannot contribute to the current validated payload output. If a previous validation failure occurred only because the validation time was earlier than the object's notBefore time, and the current time has since entered its validity interval, the object needs to be fully validated before it can be treated as valid. These checks allow time-dependent changes to be handled without requiring full validation of every object in the PP. Use of cached results. After these checks, the cached validated payloads of objects that remain valid can contribute to the current output. Valid subordinate CA certificates can be used to continue top-down processing of their respective PPs. The RP needs to determine separately whether each subordinate CA's cached validation state remains applicable; reuse of a parent PP does not establish that its subordinate PPs can also be reused. Applicability and limitations. This approach can avoid repeated validation work across an unchanged PP, but it requires the RP to retain and check sufficient state to determine whether the cached result remains applicable. Its effectiveness depends on how frequently PPs remain unchanged between validation cycles and on the cost of maintaining the associated cached state.

Hybrid Approaches Basic approach. Hybrid approaches can combine publication-point-level reuse and object-validation-state caching. They are useful when a CA's publication point has changed, but many of its published objects remain unchanged. For example, when a manifest is updated to reflect changes to a small number of ROAs, the previous validation result for the entire PP cannot be reused as the result for the current publication state. However, the validation results of unchanged ROAs may still be reusable. Reuse-path selection. An RP can first determine whether the conditions for whole-PP reuse described in Section 5.3 are satisfied:

Whole-PP reuse: If the CA certificate, effective resource context, manifest, and CRL remain unchanged and the other reuse conditions hold, the RP can reuse the cached validation state for its entire PP.
Full validation: If the CA certificate identity or effective resource context has changed, the affected PP needs to be fully validated under the current context.
Object-level reuse: If the CA identity and effective resource context remain unchanged but the manifest or CRL has changed, the RP can instead process the current manifest and CRL and attempt object-level reuse. The current manifest and CRL must be valid for the PP to be processed as valid in the current validation cycle.

Object-level reuse and revalidation. When object-level reuse is used, the current manifest determines the set of objects to be processed. For each object in that set, the RP can reuse its cached validation result if the object matches the cached object. The RP must check the current validity intervals and revocation status as applicable. Previously failed objects must also be revalidated when the condition that caused the failure no longer applies, such as when an object enters its validity interval or a previously revoked certificate is no longer listed as revoked in the current valid CRL. Objects that are new, have changed, or do not satisfy the reuse conditions need to be fully validated. Objects no longer included in the current manifest do not contribute to the current validated payload output. Use of cached results. After the required checks succeed, cached validated payloads can contribute to the current output, and valid subordinate CA certificates can be used to continue processing their publication points. Applicability and limitations. Combining publication-point-level and object-level reuse allows an RP to avoid repeating validation work both when an entire PP remains unchanged and when only some of its objects have changed. This approach is particularly useful when repository updates affect only a small portion of a PP. Its effectiveness depends on how frequently PP-level or object-level reuse conditions are satisfied and on the cost of maintaining and checking the associated cached state.

Correctness and Failure Handling

Correctness Target For the same repository snapshot, trust anchor set, validation policy, validation time, and applicable RPKI validation rules, incremental validation is expected to produce the same validated payload output as full validation. This equivalence is the primary correctness objective of incremental validation, regardless of the cache and reuse strategies used.

Uncertain or Inconsistent Cache State If cached validation state is missing, inconsistent with the current repository data, or insufficient to determine whether a previous result remains applicable, the RP should not reuse the affected result. The RP should revalidate the affected objects and their dependent validation state, or perform full validation of the affected PP when necessary. A partial or failed validation result should not replace a previously successful cache entry as though the current validation had completed successfully.

Fallback If the current repository data for a PP cannot be used, for example, because its manifest or CRL is invalid or the repository data is inconsistent with the manifest, an RP may fall back, according to local policy, to the last successfully validated version of that PP. If the cached validation state for that version still satisfies the PP-level reuse conditions, the RP may reuse the cached result, subject to checks required by the current validation time. Otherwise, the RP needs to validate the previous PP data under the current validation context before using its results.

Security Considerations Cached validation state can be corrupted, modified without authorization, or rolled back to an earlier state. Such changes may cause an RP to reuse incorrect validation results. Implementations should protect cached state against these risks. If the integrity of cached state cannot be established, the affected results should not be reused without revalidation. Incorrect reuse may also cause an RP to overlook changes in certificate validity, revocation status, effective resource context, or manifest membership. Implementations should ensure that cache reuse does not bypass the checks required to determine whether an object remains valid under the current validation context.

IANA Considerations This document has no IANA requests.

Acknowledgements