The RPKI Repository Delta Protocol (RRDP)
updated by
Extracted elements (29)
RRDP publishes repository changes as immutable Snapshot and Delta Files at unique URLs so that the server pre-calculates them once for all clients. This enables CDN or other caching infrastructure to serve most requests, drastically reducing load on the primary Repository Server.
RRDP was designed to replace rsync as the RPKI repository distribution mechanism because rsync requires significant per-connection CPU and memory on the server side, making central repositories vulnerable to denial-of-service attacks when thousands of Relying Parties connect. A secondary concern was the lack of supported rsync libraries, forcing all implementations to make system calls to an rsync binary.
The session_id must be verified in combination with the Update Notification File's URL — not alone — because a malicious server could replay a valid session_id from a different Repository Server. Using both the UUID and the URL together as the unique session key closes this attack vector.
Relying Parties encountering operational failures (unretrievable or invalid files) SHOULD attempt alternative repository access mechanisms listed in the certificate's SIA accessMethod elements (e.g., rsync), keep old cached objects for continued validation, and perform proactive re-validation before manifests or CRLs go stale.
RRDP coexists with rsync-based RPKI repositories by including the rsync URI of every object in Snapshot and Delta Files alongside the content hash. This allows the same set of files on a filesystem to be distributed via both rsync and RRDP, and allows Relying Party tools to combine objects from both repository types for validation.
A Relying Party MUST download and verify the Update Notification File format per Section 3.5.1.3; if verification fails the file MUST be rejected. The session_id MUST be verified against the last known session_id for that URL, and MUST NOT be used as a unique identifier without also considering the file's location.
Certificate Authorities that use RRDP MUST include an SIA AccessDescription extension with accessMethod id-ad-rpkiNotify in every resource certificate they produce, in addition to the extensions defined in RFC 6487.
Each new repository serial number MUST be exactly one greater than the current serial. Older Delta Files that, combined with all more recent deltas, exceed the total size of the snapshot MUST be excluded from the Update Notification File to prevent Relying Parties from downloading more data than necessary.
If the session_id does not match the last known value, the Relying Party MUST update its recorded session_id and MUST download and process the Snapshot File from the new Update Notification File rather than applying deltas.
On initialization, the Repository Server MUST generate a new random version 4 UUID as the session_id and MUST generate a Snapshot File for serial number ONE containing all currently known published objects, making it available at a URL unique to that session_id and serial.
Relying Parties MUST NOT poll the Update Notification File more than once per minute, and MUST use the 'If-Modified-Since' HTTP header in all polling requests to reduce unnecessary data transfer.
Repository Servers SHOULD retain old Snapshot Files for at least 5 minutes after a new Update Notification File is published, and SHOULD retain old Delta Files for at least 5 minutes after they are no longer referenced, to avoid race conditions where a Relying Party fetches a stale notification just before it is updated.
Snapshot and Delta Files MUST be published at URLs unique to their specific session_id and serial so they can be cached indefinitely. The Update Notification File URL, by contrast, remains stable across versions.
Snapshot Files MUST only be used when Delta Files are unavailable or were rejected. When downloading a Snapshot File, the Relying Party MUST verify its hash against the Update Notification File and MUST verify the session_id and serial match.
The accessLocation in the id-ad-rpkiNotify SIA entry MUST be an HTTPS URI pointing to the Update Notification File for the Repository Server that publishes the products of the Certificate Authority certificate.
The hash attribute in snapshot and delta reference elements MUST be the hexadecimal encoding of the SHA-256 hash of the referenced file, and the Relying Party MUST verify this hash upon retrieval, rejecting the file on mismatch.
The Update Notification File SHOULD NOT be cached for longer than 1 minute; setting Cache-Control to an interval longer than 1 hour is NOT RECOMMENDED. An exception is that serving a stale notification is better than serving none at all.
When a Relying Party encounters a 'withdraw' or replacement 'publish' element in a Delta File, it MUST verify the object to be withdrawn or replaced was retrieved from the same Repository Server before acting; failing to do so leaves the Relying Party vulnerable to malicious servers deleting or changing arbitrary objects.
When processing Delta Files, a Relying Party MUST verify the file's hash matches the hash listed in the Update Notification File, MUST verify the session_id matches, and MUST verify the serial is exactly one greater than the last processed serial; any mismatch requires falling back to the Snapshot File.
Whenever the Repository Server receives updates from a CA, it MUST generate new Snapshot and Delta Files within one minute. If combining updates from multiple CAs, publication MUST NOT be postponed longer than one minute for any involved CA.
The Delta File is an XML document with a root 'delta' element carrying version, session_id, and serial attributes, plus one or more 'publish' (uri, optional hash, base64 content) or 'withdraw' (uri, hash) child elements encoding all changes for exactly one serial increment of the repository.
The Snapshot File is an XML document with a root 'snapshot' element carrying version, session_id, and serial attributes, plus zero or more 'publish' child elements each with a uri attribute and base64-encoded object content. It represents the complete current state of the repository for that session and serial.
The Update Notification File is an XML document with a root 'notification' element carrying a version (must be '1'), a session_id (version 4 UUID), and an unbounded unsigned serial number. It contains exactly one 'snapshot' child element (with uri and SHA-256 hash) and zero or more 'delta' child elements (each with serial, uri, and hash), forming a contiguous chain of serials up to the current one.
IANA updated the 'SMI Security for PKIX Access Descriptor' registry so that id-ad-rpkiNotify (OID { id-ad 13 }) references RFC 8182 as its defining document.
A MITM on the HTTPS channel cannot forge validly signed RPKI objects but can perform withhold or replay attacks, preventing a Relying Party from learning about repository changes. Therefore Relying Parties SHOULD perform TLS certificate and hostname validation per RFC 6125; however, since RPKI object security does not depend on channel security, Relying Parties MUST continue to retrieve data even if TLS validation fails.
All RPKI objects (certificates, CRLs, CMS-wrapped signed objects) are protected by object-level security including signed manifests, so they can be validated even when the Repository Server itself is not trusted. RRDP makes no change to RPKI validation procedures.
Because RRDP treats an entire set of changes as one atomic delta, it may not be practical to begin processing any object in the delta until the full delta has been received. This increases RRDP's transactional correctness compared to rsync, which may deliver a partial set of updated objects.
Supporting both RRDP and rsync increases the attack surface for denial-of-service by a malicious RPKI CA, since the CA can supply an effectively infinite series of URIs for Relying Parties to follow. The document recommends Relying Parties apply bounds on how much work they will perform; this attack requires the attacker to be a legitimate RPKI CA.
All RRDP XML files MUST use the namespace 'http://www.ripe.net/rpki/rrdp', encoding 'US-ASCII', and version attribute '1'. Hash attributes are lowercase hexadecimal SHA-256 digests; object content in publish elements is base64-encoded binary. The RELAX NG compact schema in Section 3.5.4 is normative.