Detecting RPKI Repository Delta Protocol (RRDP) Session Desynchronization
updates
- rfc-8182 — The RPKI Repository Delta Protocol (RRDP)
Extracted elements (10)
Comparing only the server-provided session_id and latest serial number across distinct RP instances is insufficient to detect divergence caused by mutated delta files. Hash comparison of all previously seen serial-to-hash mappings is required to surface this form of desynchronization.
RFC 8182 alluded to immutability as a property of RRDP files but did not make it an absolute requirement. If a server serves differing data for the same session_id and serial number, distinct Relying Party instances that connected at different moments will end up with divergent local repositories, violating the principle of least astonishment.
This document updates RFC 8182 Section 3.4.1 ('Processing the Update Notification File') by inserting a new paragraph that mandates hash comparison of previously seen delta serials when the session_id matches, and snapshot download when differences are detected. Implementations of RFC 8182 that do not implement this check cannot detect the mutation form of desynchronization.
Following detection of RRDP session desynchronization, RP implementations SHOULD issue a warning and SHOULD download the latest Snapshot File and process it as described in Section 3.4.3 of RFC 8182 to return to a synchronized state.
If the session_id matches the last known session_id, the Relying Party SHOULD compare whether hash values associated with previously seen files for serials match the hash values of the corresponding serials in the newly fetched Update Notification File. If any differences are detected, files were unexpectedly mutated.
Relying Parties should maintain persistent state consisting of the session_id and a mapping of serial numbers to hash values for each delta element from the most recently successful Update Notification File fetch, enabling comparison on subsequent fetches.
By detecting an inconsistent Repository Server immediately and switching to the latest Snapshot File, RPs increase the probability of replacing stale or incorrect objects before they expire under the staleness rules of RFC 9286 Section 6.6, thereby reducing the window of invalid route-origin decisions.
RRDP sessions often have lifetimes measured in months, so desynchronization can persist for an extended period if undetected. Caches in a desynchronized state emit a different set of Validated Payloads than they would from a consistent repository copy, causing route announcements to be incorrectly marked 'unknown' or 'invalid' for an indeterminate period.
Through the interaction of desynchronization and the failed-fetch mechanism in RFC 9286 Section 6.6, Relying Parties could spuriously omit Validated Payloads or continue to emit Validated Payloads that the Certification Authority intended to withdraw, directly degrading BGP prefix origin validation (RFC 6811) and ASPA-based path verification.
After fetching a new Update Notification File, if the session_id matches the last known session_id, the RP compares each previously recorded serial-to-hash pair against the corresponding entry in the new file. A hash mismatch for any previously seen serial triggers the desynchronization-detected state and initiates snapshot recovery.