Summary

  • An RRDP session_id and serial locate synchronization state; they do not prove that every relying party received the same bytes. If a previously advertised delta hash changes under the same session and serial, incremental history has lost the immutability on which cache convergence depends.
  • The bounded repair is to preserve the evidence, warn, fetch the latest snapshot and repeat RPKI validation. A clean RRDP fetch still does not make a ROA valid or order a router to reject a route: manifests, certificates, CRLs, signed-object rules, validated-payload delivery and local routing policy remain separate authorities.

Imagine two validators serving the same network from different sites. This is an illustrative operating exercise, not a reported incident. Both poll one RRDP notification location. Both display the same session identifier and, after the next poll, the same current serial. The ordinary health view therefore calls them synchronized.

Their histories are not the same. The first validator recorded delta serial 1774 with one SHA-256 hash. The second, arriving later, sees a notification that assigns a different hash to that already-used combination of session and serial. Each downloaded file can match the notification visible at its own fetch time. Each process can be internally consistent. Yet their local repositories can contain different bytes, and the validated payloads they derive can disagree.

The dashboard compared names for state. It did not compare the history those names were supposed to preserve.

RFC 9697 specifies this failure and its recovery. A relying party retains serial-and-hash pairs from a previous successful notification fetch. When the next notification overlaps those serials, it compares the old and new hashes. A change for an already-seen serial is evidence of unexpected delta mutation. The relying party should issue a warning and should process the latest snapshot.

That rule looks small. Operationally, it allocates authority across an entire chain. The repository may publish change files. A CDN may replicate them. A validator may decide that incremental history can no longer be believed. A manifest may determine which signed files can enter validation. A cache may produce a different set of validated payloads. A router may receive those changes. The network operator still decides what validation state does to a live route.

RRDP distributes a history, not merely a directory

The RPKI contains certificates, certificate revocation lists and signed products such as route origin authorizations. RFC 6480 describes a distributed repository system that makes those materials available to relying parties. The repository is a public clearing house. Its availability matters, but its possession of bytes does not make it the source of their cryptographic authority.

RRDP supplies an efficient retrieval history for that public state. Under RFC 8182, a stable update-notification URL tells a relying party the current session_id, serial, snapshot location and a retained sequence of deltas. A snapshot contains the repository's current publish elements. Each delta contains the publish, replace and withdraw operations for exactly one serial increment.

The relying party has two ways to reach the current state. It can begin or begin again from the snapshot. Or, if its session matches and the notification exposes every missing increment, it can apply a contiguous delta chain in serial order. A delta must carry the same session as the notification. Its serial must be exactly one greater than the last processed serial. Its downloaded bytes must match the hash advertised by the notification.

Those rules make a local state transition reproducible. They do not create one global transaction across every validator. Polling happens at different times. Caches may temporarily expose different ages. Retrieval can fail. One relying party may hold a bounded older set while another has already validated a newer one.

RFC 6811 therefore describes the global RPKI view as loosely consistent because fetching and updating occur at different times. That ordinary timing difference is not a defect that one central clock can eliminate. But it is categorically different from reusing the same historical coordinate for different bytes. The first says two observers reached different points in a legitimate sequence. The second says the sequence itself no longer has one recoverable meaning.

A UUID is not a repository principal

The session_id sounds stronger than it is. RFC 8182 requires a relying party to interpret it together with the update-notification location. The random UUID alone must not be used as a unique session identifier because a malicious server could reuse a value from another repository server.

The location supplies scope. The session distinguishes one initialization history at that location. The serial orders changes inside that session. The hash commits the notification to particular snapshot or delta bytes. Remove any component and the evidence becomes ambiguous.

This layered key also prevents misleading fleet comparisons. A monitoring system that groups every process by UUID can merge unrelated repositories. One that compares only the highest serial can call divergent histories equal. One that checks only the newest file hash can miss mutation of an older delta still advertised in the overlapping window.

The useful record is therefore not “session 7, serial 1775 is green.” It is the notification origin and location, session, current serial, snapshot hash, every advertised delta serial and hash, the prior successful overlapping set, and the local result of applying those files. Health is a relation among artifacts, not a badge attached to two integers.

Immutability is the condition that makes caching safe

RRDP was designed to scale across far more relying parties than publishers. RFC 8182 permits snapshots and deltas to move through HTTP servers and CDNs because their content and URLs are not changed after publication in a notification. A repository can precompute an artifact, allow it to be cached indefinitely and let many validators retrieve identical bytes.

That is an economic design as much as a data format. Publishing one immutable object lets bandwidth, storage and request work be shared. Rewriting an artifact under an established historical coordinate destroys that saving: a cache hit no longer means another relying party can reproduce the same transition.

The consequence can outlive the initial mistake. One edge cache may retain the first delta, another the replacement. Validators arriving at different moments build different local repositories. If the session lasts for months, as RFC 9697 notes is common, the split can persist unless clients compare historical hashes. A later agreement on the current serial does not cause the prior divergence to heal by itself.

RFC 9697 closes the evidentiary gap by asking the relying party to remember a bounded past. It does not require a universal archive of every RRDP file. It compares hash values for serials present in both the previous successful notification and the new one. That overlap is enough to detect that a file advertised as immutable has changed.

The alert should therefore name the violated invariant. “RRDP update available” is not the issue. “Delta download failed” is incomplete. The material finding is that a previously observed (location, session, serial) now maps to another hash. That fact identifies why incremental continuation is no longer defensible.

A snapshot is a reset of transport history, not a pardon

After a delta is unavailable or rejected, RFC 8182 directs the relying party to the current snapshot. RFC 9697 applies that recovery to unexpected historical mutation. The snapshot gives the relying party one complete repository view at the notification's current session and serial, so it no longer has to compose the disputed increments.

The reset remains conditional. The relying party verifies the snapshot format and its content hash against the notification. The snapshot session must match. Its serial must be acceptable under the processing rules. If the snapshot is rejected, RRDP itself cannot supply a usable new state.

Calling this action a fallback can obscure its risk. A fleet-wide move from small deltas to complete snapshots changes bandwidth, memory, CPU, repository and CDN load. If thousands of validators respond to the same defect together, the recovery mechanism can amplify the pressure on the system it is trying to repair. Operators need retry discipline, capacity headroom and staged observation, not an unbounded reset loop.

Nor should a snapshot erase the forensic record. Before replacing local state, a validator should preserve the old and new notification bytes or hashes, fetch times, origin checks, overlapping serial pairs, rejection reason and affected repository. Without that evidence, the resynchronization may restore service while destroying the explanation needed to distinguish publisher error, CDN incoherence, software failure or deliberate interference.

A successful snapshot answers one narrow question: the validator has reconstructed a repository state consistent with this notification. It does not prove that the state is the newest globally visible copy, that every expected signed product is present, that every contained product is valid, or that another validator has already converged.

Same origin bounds who can spend another repository's resources

RRDP's notification uses absolute URIs for snapshots and deltas. The original specification did not expressly prohibit those references or redirects from pointing to a different origin. RFC 9674 now requires the notification, referenced artifacts and redirects to keep the same scheme, host and port.

The control prevents one repository from using a relying party to direct load at another repository server. It also keeps the principal responsible for a notification aligned with the resources needed to realize it. A client that detects a cross-origin reference or redirect rejects the RRDP session and logs the condition.

Same origin is still not semantic authority. A TLS connection can deliver bytes from the expected host and those bytes can still contain an invalid, expired or stale RPKI product. Conversely, RFC 8182 observes that transport-certificate problems do not let an intermediary manufacture a valid RPKI signature. RRDP is concerned with getting public objects to relying parties; the objects retain their own security mechanisms.

This is a useful restraint. Transport authentication tells the validator which HTTPS origin answered. RRDP hashes tell it whether the fetched artifact matches the notification. Neither statement says the issuing CA was authorized for the resources, the certificate chain validates, the CRL is current, the manifest is acceptable or a ROA authorizes the route now on the wire.

The repository and the signer occupy different control surfaces

The separation is visible on the write side. RFC 8181 defines how a CA engine asks a publication service to publish, replace or withdraw repository products. The CA and repository can be operated by different organizations. The publication exchange uses a business PKI for message authentication, while the public RPKI products are authenticated under the RPKI itself.

RFC 8181 is explicit that the publication protocol does not establish the validity of the material it publishes. A successful write means that an authorized publication client completed a repository operation under the service's policy. It does not mean a relying party will accept the resulting certificate, CRL or signed product.

That distinction supplies a precise incident vocabulary. A CA may have intended and authenticated a withdrawal, while a repository or RRDP distribution path fails to expose one coherent history. A repository may expose perfectly coherent bytes that contain an invalid signed product. A validator may retrieve and validate a correct product but fail to deliver the changed payload to routers. A router may receive a changed validation state but local policy may deliberately retain or de-preference rather than reject the route.

Flatten those events into “RPKI is wrong” and the response loses its target. Preserve the control surfaces and each actor can repair the state it actually owns.

Signed does not mean current, complete or usable

RFC 6488 defines generic validation for RPKI signed products. The CMS structure, embedded end-entity certificate, content type, message digest and signature must pass their checks. Those checks are necessary, not sufficient; every product type adds its own validation rules.

Even a correctly signed file can be obsolete. It can have been superseded while remaining inside a cryptographic validity interval. An attacker or faulty distributor may withhold a newer file or omit a file that should be present. Signatures make unauthorized modification detectable. They do not by themselves make absence and replay visible.

That is the function of the manifest. RFC 9286 describes a signed list of the files associated with a CA publication point and the hash of each file. A relying party uses the current manifest to control which certificates, ROAs and CRLs enter validation. If it cannot acquire every enumerated file, the fetch has failed and the relying party applies bounded cached-state rules rather than silently constructing whatever subset happened to arrive.

Manifest freshness has its own evidence. Manifest number, thisUpdate, nextUpdate, filename continuity and listed-file hashes belong to that layer. RFC 9981 updates the handling of replay-related manifest-number checks, including defined reset conditions. None of those fields is the RRDP repository serial.

An operations console that displays one generic “serial” column can therefore cause a serious category error. RRDP serial describes repository synchronization events. Manifest number orders manifests issued by a CA under its rules. RPKI-to-Router has another cache session and serial. BGP itself has no single version number for “the routes.” The numbers are meaningful only inside their own state machines.

RFC 6481 supplies the older repository-structure model behind these controls: a CA publication point should expose its products and avoid intermediate states in which a manifest and directory disagree. RRDP improves point-in-time retrieval, but it cannot make a bad publication choreography good. Coherence has to begin where the CA and repository assemble the state.

The relying party is a verifier, not a passive mirror

RFC 8897 gathers the baseline responsibilities that an RPKI relying party inherits from the certificate, repository, manifest, signed-product and router-cache specifications. Acquisition and validation are different functions. A relying party may divide them into components, but the operator still needs one trace that explains which retrieved bytes produced which validated payload.

That provenance matters when two validators disagree. Comparing only the final VRP count can reveal a difference but not assign it. Comparing the RRDP notifications can expose transport-history mutation. Comparing manifests can expose missing or stale publication-point state. Comparing certificate and CRL results can expose validation-time or revocation differences. Comparing software versions and trust-anchor inputs can expose local interpretation differences.

The correct question is not “Which validator is authoritative?” It is “Which evidence path is reproducible, current under the applicable rules and safe to use while the difference is investigated?” A validator earns operational confidence by making that path inspectable. It does not acquire sovereignty over routes merely by finishing a fetch.

Validated payloads still stop at local routing policy

RRDP and RPKI validation can change the set of validated prefix-to-origin mappings available to a router. RFC 6811 says an affected route must be revalidated when a mapping is added, removed or changed, and the BGP decision process runs as needed. It also requires implementations to let routing policy match and act on validation state.

The final verb remains local. A network may reject routes it classifies as Invalid, lower their preference, mark them for observation or apply a more specific exception policy. RPKI supplies evidence about origin authorization. It does not validate the AS path, prove current forwarding or compel one universal response.

This is why RRDP recovery must not be wired directly to an irreversible route purge. A detected mutation justifies abandoning one incremental history and rebuilding. Only after snapshot processing, manifest checks, certificate and signed-product validation, payload comparison and delivery to routers does the operator have evidence about which routes are affected.

The proof then continues. The router's received validation state does not prove its selected route changed. A changed RIB does not prove the FIB changed. A changed FIB does not prove customer traffic recovered. The control chain ends at packet and service evidence, not at the validator's green status.

Sources