RPKI Repository Delta Protocol

Relying parties in the RPKI retrieve information from repositories. In order to retrieve the information as efficiently as possible this protocol defines an update notification file which can be used to determine if the RP and repository are synchronized. If the RP is not in sync with the repository, the update notification file provides a means to locate files containing deltas from the past 24 hours or snapshot file(s) with a complete, point in time version of the repository no less than 24 hours old. When possible the use of deltas SHOULD be preferred as the means for synchronizing the state of the RP with the repository. When a RP is in a state such that the available deltas are insufficient to synchronize its state with the repository then the snapshot file(s) MUST be used. Such cases can occur when a new RP is first brought online, when a RP has not retrieved updates for more than 24 hours, when a RP has become out of sync with the repository due to an error or when the repository must transition to a new session id. After downloading a snapshot it MAY be necessary to apply deltas to synchronize with the current version of the repository. Therefore, it MUST always be possible to apply zero or more deltas to the snapshot to synchronize a RP with the current version of the repository. The snapshot and delta files are immutable in that the contents for a given URI never change and can safely be cached. Immutable files cause less processing to be done on the server and allow for safe caching of repository content. The snapshot provides a consistent, point in time view of the repository. The snapshot can be large so it is RECOMMENDED to break it into multiple segment files. Each file making up the snapshot MUST have a unique URI. It is RECOMMENDED to make each URI contain the session id, version and segment number. Each delta file describes changes in the repository from one point in time to another point in time. A single delta file MAY contain many updates. Due to the way that Certificate Authorities frequently sign new manifests and CRLs in large batches some deltas may contain a large number of changes. For this reason it is also RECOMMENDED to split large deltas into multiple segment files. Each delta segment file MUST be made available over a unique URI. It is recommended to include the following information in the URI; session id, from version number, to version number, and segment number if applicable. In this document we will assume that HTTP is used as the transport protocol. The unique URIs for snapshot and delta files are intended to support HTTP caching, possibly by Content Delivery Networks (CDNs). We will include HTTP specific hints with regards to the caching and retrieval of the update notification file. It should be noted that other transport protocols can also be used, provided that the same caching semantics are observed.

The delta protocol described here has been designed to use HTTP as the transport protocol although it is not strictly required. Any transport protocol that meets the requirements laid out in the following sections can be used in place of HTTP.

This protocol uses XML for the update notification, snapshot and delta files.

The update notification file is used by RPs to discover whether any changes exist between the state of the publication server's repository and the RP's cache. It describes the location of the files containing the snapshot and incremental deltas which can be used by the RP to synchronize with the repository. The update notification file can be cached, but it SHOULD NOT be cached for more than five minutes. The URIs for each snapshot and delta file MUST be unique and the contents of the files for each URI MUST not change. Assuming that HTTP is used as the transport protocol, publication servers SHOULD use appropriate cache headers. The maximum allowed time to cache MUST not exceed 5 minutes (e.g. add header: Cache-Control: max-age=300). It is RECOMMENDED that Relying Parties use the "If-Modified-Since" header in GET requests for the notification file. A RP MUST NOT process any update notification file that is incomplete or not well formed.

The XML namespace MUST be http://www.ripe.net/rpki/rrdp. The encoding MUST be us-ascii. The root element MUST be msg and it contains the following attributes: Attribute Description Value type The type of this RRDP message. notification version The RRDP protocol version of this message. 1

The message MUST contain one notification element. The element has the following attributes: Attribute Description session_id Unique identifier of the session id of the publication server. It is RECOMMENDED that a UUID is used as the session_id. current_version Unbounded, unsigned integer representing the current version of the repository. The current version number MUST be one greater than the previous version number for a given session id. If a repository server is no longer able to provide contiguous deltas it MUST reset the session id and start with version 0. The notification element MUST contain one 'snapshot' element and MAY contain a 'deltas' element. In practice the 'deltas' element will almost always be present because most Certificate Authorities re-sign manifests and CRLs at a frequency of at least once every 24 hours. The snapshot and deltas elements are each described below.

A snapshot is a point in time view of the state of the entire repository. A snapshot MUST have one or more 'snapshot-segment' elements. The snapshot segment files MUST not contain duplicate entries for the same certificate or CRL URI. This means that snapshot segments do not have to be applied in serial. Attribute Description version The version number of the repository for this full snapshot.

A snapshot-segment contains information about one segment of a full snapshot. Attribute Description uri A unique URI for this snapshot segment. The URI must be unique so the file can be cached indefinitely. It is RECOMMENDED to construct this URI based on the session id, version and segment number. E.g. http://host/snapshots/SESSION_ID/VERSION/SEGMENT.xml or with concrete data http://host/snapshots/9f735ad0-aef4-4d8b-820d-559472936265/203/4.xml hash The SHA-256 hash of the snapshot segment file (similar to RFC 6485). This does not provide any additional security, it merely helps detect transport errors.

The deltas element contains delta segment elements with information about the available deltas. It does not have any attributes. The delta segments MUST be listed in chronological order and MUST be replayed in the order specified in the updated notification file. While one version MAY be covered in more than one file there MUST NOT be any overlap in version numbers. There are two possible valid cases. The first is that the from and to versions are identical to the previous segment and the segment number is one greater than the previous delta. The other valid case is when the from version is equal to the to version of the previous delta and the to version of the element is greater than or equal to the from version of the element. In this case the segment number MAY be present and have a value of 1 or MUST NOT be present. Any case that does not meet one of these two requirements MUST be considered invalid.

A delta segment file element contains information about one or more sets of deltas specified by the starting 'from' version and going until the ending 'to' version. These deltas may be aggregated over time, however each delta file remains immutable. The delta element serves for deltas that are too large to fit in one file. It is broken into segments similar to the way that the snapshot file is broken into segments. Attribute Description from The first version contained in the delta. to The last version contained in the delta. uri A URI pointing to the file containing the changes in this delta. The URI must be unique so the file can be cached indefinitely. It is RECOMMENDED to construct this URI based on the session id, from version, to version and segment number (if applicable) for this delta. E.g. http://host/deltas/SESSION_ID/FROM/TO/SEGMENT.xml or http://host/deltas/9f735ad0-aef4-4d8b-820d-559472936265/173/174/5.xml hash The SHA-256 hash of the delta segment file (similar to RFC 6485). This does not provide any additional security, it merely helps detect transport errors.

]]> It should be noted that the length of the UUID and SHA-256 hash are not correct, this example is only for illustrative purposes.

It is RECOMMENDED that publication servers aggregate deltas after some time to reduce the number of fetches that RPs need to perform and to keep the notification file small. There are several strategies possible to optimize this, so this is not limited strictly here. The publication server MUST provide a set of deltas that allow RPs to synchronize to the current version number from the snapshot. The RP MAY need to process more than one delta to achieve this.

A snapshot MUST contain all objects from the repository current as of the time of the publication. Each segment contains a subset of the objects such that the union of all the segments make up the full snapshot. Snapshot segments only contain publish elements. They MUST NOT contain withdraw elements.

The XML namespace MUST be http://www.ripe.net/rpki/rrdp. The encoding MUST be us-ascii. The root element MUST be msg and it contains the following attributes: Attribute Description Value type The type of this RRDP message. snapshot version The RRDP protocol version of this message. 1

The message MUST contain one snapshot element. The element has the following attributes: Attribute Description session_id Unique identifier of the session id of the publication server. It is RECOMMENDED that a UUID is used as the session_id. version Unbounded, unsigned integer representing the current version of the repository. index The index of this segment for the given version, as in, this is segment 2 of 9 for version 836. The index is one based so the first value is 1 and NOT 0.

The publish element is an exact copy of the publish element as described in the publication document (reference: http://tools.ietf.org/html/draft-ietf-sidr-publication-03#section-3.3). Attribute Description uri The URI that was included in the original 'publish' element. The content of each element is the base 64 encoded object. The URI is useful for current RP implementations that use URIs to work out relations in the RPKI. It should be noted though that RPs can also work this out based on manifests and object properties such as key identifiers, signatures and the hash of the binary object. See: http://www.ietf.org/internet-drafts/draft-tbruijnzeels-sidr-validation-local-cache-00.txt The extension of the filename can be used by the RP to determine the type of object.

MIIE+jCCA+KgAwIBAgIBDTANBgkqhkiG9w0BAQsFADAzMTEwLwYDVQQD jRBODAxN0U2NkE5RTkxNzJFNDYxMkQ4Q0Y0QzgzRjIzOERFMkEzMB4XE ........................................................ h8zeHoFVu6ghRPy5dbOA4akX/KG6b8XIx0iwPYdLiDbdWFbtTdPcXBau MIIE+jCCA+KgAwIBAgIBDTANBgkqhkiG9w0BAQsFADAzMTEwLwYDVQQD h8zeHoFVu6ghRPy5dbOA4akX/KG6b8XIx0iwPYdLiDbdWFbtTdPcXBau ........................................................ jRBODAxN0U2NkE5RTkxNzJFNDYxMkQ4Q0Y0QzgzRjIzOERFMkEzMB4XD MIIE+jCCA+KgAwIBAgIBDTANBgkqhkiG9w0BAQsFADAzMTEwLwYDVQQD h8zeHoFVu6ghRPy5dbOA4akX/KG6b8XIx0iwPYdLiDbdWFbtTdPcXBau ........................................................ jRBODAxN0U2NkE5RTkxNzJFNDYxMkQ4Q0Y0QzgzRjIzOERFMkEzMB4XD ]]> Lines containing only periods signify additional lines of base 64 encoded data.

Snapshot segments for a given session id and version MUST NOT contain publish elements for a given URI. Therefore snapshot segments do not have to be applied in a particular order.

An incremental delta segment file contains all changes between the start and end versions.

The XML namespace MUST be http://www.ripe.net/rpki/rrdp. The encoding MUST be us-ascii. The root element MUST be msg and it contains the following attributes: Attribute Description Value type The type of this RRDP message. deltas version The RRDP protocol version of this message. 1

The message MUST contain one deltas element. The deltas must be applied in the numeric order by version and then by the order in which they appear in this file. The deltas element has the following attributes: Attribute Description session_id Unique identifier of the session id of the publication server. It is RECOMMENDED that a UUID is used as the session_id. from Unbounded, unsigned integer representing the first version for this delta. to Unbounded, unsigned integer representing the last version for this delta. index The index of this delta IF the delta was not able to fit in one file, as in, this is segment 2 of 9 for the delta that covers the changes from version 3 to version 4. The index is one based so the first value is 1 and NOT 0. This attribute is OPTIONAL, but it MUST be present if the particular version range is covered by more than one file.

Attribute Description version The version of the delta changes. The delta element contains withdraw and publish elements.

The withdraw element is an exact copy of the withdraw element as described in the publication document (reference: http://tools.ietf.org/html/draft-ietf-sidr-publication-03#section-3.3). Attribute Description uri The URI that was included in the original withdraw element.

The publish element is an exact copy of the publish element as described in the publication document (reference: http://tools.ietf.org/html/draft-ietf-sidr-publication-03#section-3.3). Attribute Description uri The URI that was included in the original publish element. The content of each element is the base 64 encoded object. The URI is useful for current RP implementations that use URIs to work out relations in the PKI. It should be noted though that RPs can also work this out based on manifests and object properties such as key identifiers, signatures and the hash of the binary object. See: http://www.ietf.org/internet-drafts/draft-tbruijnzeels-sidr-validation-local-cache-00.txt The extension of the filename can be used by the RP to determine the type of object.

MIIE+jCCA+KgAwIBAgIBDTANBgkqhkiG9w0BAQsFADAzMTEw jRBODAxN0U2NkE5RTkxNzJFNDYxMkQ4Q0Y0QzgzRjIzOERFM ................................................ h8zeHoFVu6ghRPy5dbOA4akX/KG6b8XIx0iwPYdLiDbdWFbt MIIE+jCCA+KgAwIBAgIBDTANBgkqhkiG9w0BAQsFADAzMTEw h8zeHoFVu6ghRPy5dbOA4akX/KG6b8XIx0iwPYdLiDbdWFbt ................................................ jRBODAxN0U2NkE5RTkxNzJFNDYxMkQ4Q0Y0QzgzRjIzOERFM MIIE+jCCA+KgAwIBAgIBDTANBgkqhkiG9w0BAQsFADAzMTEw h8zeHoFVu6ghRPy5dbOA4akX/KG6b8XIx0iwPYdLiDbdWFbt ................................................ jRBODAxN0U2NkE5RTkxNzJFNDYxMkQ4Q0Y0QzgzRjIzOERFM ]]> The dotted lines signify additional lines of Base 64 encoded data.

Delta segment files which are not well formed MUST not be processed. The delta segment with the lowest from version for a given session id MUST be processed first. Each version for a given session id SHOULD NOT be applied more than once. Delta segments for a given session id, from version and to version MUST be applied in the order of the version and then by the order in which they are specified in the file.

The location of the update notification files for a CA certificate publication point is communicated by including a SIA pointer for them. We propose the to use 'http+rdp' for the URI scheme, implying http is used as the transfer protocol and this Rpki Repository Delta Protocol (rrdp) applies. E.g. http+rrdp://rpki.ripe.net/updates.xml