Network Working Group T. Bruijnzeels Internet-Draft O. Muravskiy Updates: draft-tbruijnzeels-sidr-delta-protocol-00 (if approved)RIPE NCC Intended status: Standards Track B. Weber Expires: August 15, 2013 Cobenian February 11, 2013 RPKI Repository Delta Protocol draft-tbruijnzeels-sidr-delta-protocol-01 Abstract In the Resource Public Key Infrastructure (RPKI), certificate authorities publish certificates, including end entity certificates, and CRLs to repositories on publication servers. Relying Parties (RP) retrieve the published information from the repository and MAY store it in a cache. This document specifies a delta protocol which provides relying parties with a mechanism to query a repository for changes, thus enabling the RP to keep its state in sync with the repository. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 15, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Bruijnzeels, et al. Expires August 15, 2013 [Page 1] Internet-Draft RPKI Repository Delta Protocol February 2013 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 3. RPKI Repository Delta Protocol Implementation . . . . . . . . 3 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Transport protocol . . . . . . . . . . . . . . . . . . . 4 3.3. File Format . . . . . . . . . . . . . . . . . . . . . . . 4 3.4. Update Notification File . . . . . . . . . . . . . . . . 4 3.4.1. Root Element . . . . . . . . . . . . . . . . . . . . 5 3.4.2. Contents . . . . . . . . . . . . . . . . . . . . . . 5 3.4.3. Sample Notification File . . . . . . . . . . . . . . 7 3.4.4. Snapshot and Delta Availability Requirements . . . . 9 3.5. Snapshot Segment Format . . . . . . . . . . . . . . . . . 9 3.5.1. Root Element . . . . . . . . . . . . . . . . . . . . 9 3.5.2. Contents . . . . . . . . . . . . . . . . . . . . . . 10 3.5.3. Sample SNAPSHOT SEGMENT file . . . . . . . . . . . . 11 3.5.4. Applying changes from snapshot segments . . . . . . . 11 3.6. Incremental Delta Format . . . . . . . . . . . . . . . . 11 3.6.1. Root Element . . . . . . . . . . . . . . . . . . . . 12 3.6.2. Contents . . . . . . . . . . . . . . . . . . . . . . 12 3.6.3. Sample DELTAS file . . . . . . . . . . . . . . . . . 14 3.6.4. Applying changes from delta segments . . . . . . . . 14 3.7. Pointing to the update notification file . . . . . . . . 15 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 6. Normative References . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] . 2. Introduction In the Resource Public Key Infrastructure (RPKI), certificate authorities publish certificates, including end entity certificates, and CRLs to repositories on publication servers. Relying Parties (RP) retrieve the published information from the repository and MAY store it in a cache. This document specifies a delta protocol which Bruijnzeels, et al. Expires August 15, 2013 [Page 2] Internet-Draft RPKI Repository Delta Protocol February 2013 provides relying parties with a mechanism to query a repository for changes, thus enabling the RP to keep its state in sync with the repository. This protocol aims to minimize the amount of data that traverses the network and thus helps minimize the amount of time until repository convergence occurs. This protocol also provides a standards based way to obtain consistent, point in time views of a single repository eliminating a number of consistency related issues. The protocol is designed to be consistent with the publication protocol (http:// datatracker.ietf.org/doc/draft-ietf-sidr-publication/) wherever possible. 3. RPKI Repository Delta Protocol Implementation 3.1. Overview 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. Bruijnzeels, et al. Expires August 15, 2013 [Page 3] Internet-Draft RPKI Repository Delta Protocol February 2013 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. 3.2. Transport protocol 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. 3.3. File Format This protocol uses XML for the update notification, snapshot and delta files. 3.4. Update Notification File 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. Bruijnzeels, et al. Expires August 15, 2013 [Page 4] Internet-Draft RPKI Repository Delta Protocol February 2013 A RP MUST NOT process any update notification file that is incomplete or not well formed. 3.4.1. Root Element 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 | notification | | | message. | | | version | The RRDP protocol version of | 1 | | | this message. | | +---------------+-------------------------------+-------------------+ 3.4.2. Contents 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. Bruijnzeels, et al. Expires August 15, 2013 [Page 5] Internet-Draft RPKI Repository Delta Protocol February 2013 3.4.2.1. SNAPSHOT ELEMENT 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. | +-----------------+-------------------------------------------------+ 3.4.2.2. SNAPSHOT SEGMENT ELEMENT A snapshot-segment contains information about one segment of a full snapshot. +----------+--------------------------------------------------------+ | Attribut | Description | | e | | +----------+--------------------------------------------------------+ | 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. | +----------+--------------------------------------------------------+ 3.4.2.3. DELTAS ELEMENT 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. Bruijnzeels, et al. Expires August 15, 2013 [Page 6] Internet-Draft RPKI Repository Delta Protocol February 2013 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. 3.4.2.4. DELTA SEGMENT ELEMENT 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. +---------+---------------------------------------------------------+ | Attribu | Description | | te | | +---------+---------------------------------------------------------+ | 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. | +---------+---------------------------------------------------------+ 3.4.3. Sample Notification File It should be noted that the length of the UUID and SHA-256 hash are not correct, this example is only for illustrative purposes. 3.4.4. Snapshot and Delta Availability Requirements 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. 3.5. Snapshot Segment Format 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. 3.5.1. Root Element 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: Bruijnzeels, et al. Expires August 15, 2013 [Page 9] Internet-Draft RPKI Repository Delta Protocol February 2013 +-----------+--------------------------------------------+----------+ | Attribute | Description | Value | +-----------+--------------------------------------------+----------+ | type | The type of this RRDP message. | snapshot | | version | The RRDP protocol version of this message. | 1 | +-----------+--------------------------------------------+----------+ 3.5.2. Contents 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. | +--------------+----------------------------------------------------+ 3.5.2.1. PUBLISH 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 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. Bruijnzeels, et al. Expires August 15, 2013 [Page 10] Internet-Draft RPKI Repository Delta Protocol February 2013 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. 3.5.3. Sample SNAPSHOT SEGMENT file 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. 3.5.4. Applying changes from snapshot segments 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. 3.6. Incremental Delta Format An incremental delta segment file contains all changes between the start and end versions. Bruijnzeels, et al. Expires August 15, 2013 [Page 11] Internet-Draft RPKI Repository Delta Protocol February 2013 3.6.1. Root Element 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 | +-----------+--------------------------------------------+--------+ 3.6.2. Contents 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. | +--------------+----------------------------------------------------+ 3.6.2.1. DELTA ELEMENT +-----------+-----------------------------------+ | Attribute | Description | Bruijnzeels, et al. Expires August 15, 2013 [Page 12] Internet-Draft RPKI Repository Delta Protocol February 2013 +-----------+-----------------------------------+ | version | The version of the delta changes. | +-----------+-----------------------------------+ The delta element contains withdraw and publish elements. 3.6.2.1.1. WITHDRAW ELEMENT 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. | +-----------------+-------------------------------------------------+ 3.6.2.1.2. PUBLISH 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. Bruijnzeels, et al. Expires August 15, 2013 [Page 13] Internet-Draft RPKI Repository Delta Protocol February 2013 3.6.3. Sample DELTAS file 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. 3.6.4. Applying changes from delta segments 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. Bruijnzeels, et al. Expires August 15, 2013 [Page 14] Internet-Draft RPKI Repository Delta Protocol February 2013 3.7. Pointing to the update notification 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 4. Security Considerations TBD 5. Acknowledgements TBD 6. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Authors' Addresses Tim Bruijnzeels RIPE NCC Email: tim@ripe.net Oleg Muravskiy RIPE NCC Email: oleg@ripe.net Bryan Weber Cobenian Email: bryan@cobenian.com Bruijnzeels, et al. Expires August 15, 2013 [Page 15]