RPKI Repository Delta Protocol
draft-tbruijnzeels-sidr-delta-protocol-02

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 March 9, 2015.

Copyright Notice

Copyright (c) 2014 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 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. Introduction
• 3. RPKI Repository Delta Protocol Implementation
• 3.1. Overview
• 3.2. Transport protocol
• 3.3. File Format
• 3.4. Update Notification File
• 3.4.1. Root Element
• 3.4.2. Contents
• 3.4.3. Sample Notification File
• 3.4.4. Snapshot and Delta Availability Requirements
• 3.5. Snapshot Segment Format
• 3.5.1. Root Element
• 3.5.2. Contents
• 3.5.3. Sample SNAPSHOT SEGMENT file
• 3.5.4. Applying changes from snapshot segments
• 3.6. Incremental Delta Format
• 3.6.1. Root Element
• 3.6.2. Contents
• 3.6.3. Sample DELTAS file
• 3.6.4. Applying changes from delta segments
• 3.7. SIA for CA certificates
• 4. Security Considerations
• 5. IANA Considerations
• 6. Acknowledgements
• 7. Normative References
• Authors' Addresses

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 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.

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.

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:

3.4.2. Contents

The message MUST contain one notification element. The element has the following attributes:

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.

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.

3.4.2.2. SNAPSHOT SEGMENT ELEMENT

A snapshot-segment contains information about one segment of a full snapshot.

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. 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.

3.4.3. Sample Notification File

 
<?xml version="1.0" encoding="us-ascii"?>
<msg type="notification" version="1" 
    xmlns="http://www.ripe.net/rpki/rrdp">
    <notification 
        session_id="d9f6dc91-0394-40b9-9663-66aef4bb62" 
        current_version="203">
        <snapshot version="202">
            <snapshot-segment
uri="http://host/d9f6dc91-0394-40b9-9663-66aeb62/snapshot/202/1.xml"
hash="279b79fd8389e20585f26735ee70e0e4d4f23bb2e2e611c70e92d2433e"/>
            <snapshot-segment
uri="http://host/d9f6dc91-0394-40b9-9663-66aeb62/snapshot/202/2.xml"
hash="a2d56ec180f2dde2a46be0565932e25829b852a0b47d5de6e41394c290"/>
            <snapshot-segment
uri="http://host/d9f6dc91-0394-40b9-9663-66aeb62/snapshot/202/3.xml"
hash="b2d56ec180f2dde2a46be0565932e2582952a0b4317d5de6e41394c29a"/>
            <snapshot-segment
uri="http://host/d9f6dc91-0394-40b9-9663-66aeb62/snapshot/202/4.xml"
hash="c2d56ec180f2dde2a46bf92e0565932e25829b2a0b4310de6e4139c29f"/>
            <snapshot-segment 
uri="http://host/d9f6dc91-0394-40b9-9663-66aeb62/snapshot/202/5.xml" 
hash="d2d56ec180f2dde2a46bf9565932e229b852a0b43107d5e6e41394c29b"/>
            <snapshot-segment 
uri="http://host/d9f6dc91-0394-40b9-9663-66aeb62/snapshot/202/6.xml" 
hash="e2d56ec180f2dde2a46bf92e0565932e258b852a0b3d5de6e41394c292"/>
            <snapshot-segment 
uri="http://host/d9f6dc91-0394-40b9-9663-66aeb62/snapshot/202/7.xml" 
hash="f2d56ec180f2dde2a42e0565932e2582952a0b43107d5de6e41394c29c"/>
            <snapshot-segment 
uri="http://host/d9f6dc91-0394-40b9-9663-66aeb62/snapshot/202/8.xml" 
hash="02d56ec180f2dde2a46bf92e032e25829b8a0b43107d5de6e41394c294"/>
            <snapshot-segment 
uri="http://host/d9f6dc91-0394-40b9-9663-66aeb62/snapshot/202/9.xml" 
hash="c2d56ec180f2dde246bf92e0565932e258252b43107d5de6e41394c29d"/>
            <snapshot-segment 
uri="http://host/d9f6dc91-0394-40b9-9663-66aeb62/snapshot/202/10.xml" 
hash="22d56ec180f2dde2a46bf92e0532e25829b852ab43107d5de41394c296"/>
            <snapshot-segment 
uri="http://host/d9f6dc91-0394-40b9-9663-66aeb62/snapshot/202/11.xml" 
hash="b2d56ec180f2dde2a46bf9265932e25829b852a0b4317d5de6e394c29e"/>
            <snapshot-segment 
uri="http://host/d9f6dc91-0394-40b9-9663-66aeb62/snapshot/202/12.xml" 
hash="42d56ec180f2dde2a46be0565932e25829b852a0b4315de6e41394c298"/>
        </snapshot>
        <deltas>
            <delta-segment from="156" to="183" 
uri="http://host/d9f6c91-0394-40b9-9663-66aeb62/deltas/156/183.xml" 
hash="a2d56ec180f2dde2a46bf9056592e25829b852a0b43107d5de6394c291"/>
            <delta-segment from="183" to="184"
uri="http://host/d9f6c91-0394-40b9-9663-66aeb62/deltas/183/184/1.xml" 
hash="a2d56ec180f2dde2a46b2e0565932e2582b852a0b43107e6e41394c292"/>
            <delta-segment from="183" to="184" 
uri="http://host/d9f6c91-0394-40b9-9663-66aeb62/deltas/183/184/2.xml" 
hash="a2d56ec180f2dde2a46b2e0565932e25829b82a0b43107d5e41394c292"/>
            <delta-segment from="183" to="184"
uri="http://host/d9f6c91-0394-40b9-9663-66aeb62/deltas/183/184/3.xml" 
hash="a2d56ec180f2dde2a46b2e0565932e25829a0b43107d5de6e41394c292"/>
            <delta-segment from="184" to="197" 
uri="http://host/d9f6c91-0394-40b9-9663-66aeb62/deltas/184/197.xml" 
hash="a2d56ec180f2dde2a46b2e5932e2582b852a0b43107d5de6e41394c292"/>
            <delta-segment from="197" to="203" 
uri="http://host/d9f6c91-0394-40b9-9663-66aeb62/deltas/197/203.xml" 
hash="a2d56ec180f2dde2a4e056593e25829b852a0b43107d5de6e41394c293"/>
        </deltas>
    </notification>
</msg>

It should be noted that the length of the UUID and SHA-256 hashes are not the correct length, 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:

3.5.2. Contents

The message MUST contain one snapshot element. The element has the following attributes:

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).

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.

3.5.3. Sample SNAPSHOT SEGMENT file

<?xml version="1.0" encoding="us-ascii"?>
<msg xmlns="http://www.ripe.net/rpki/rrdp"
    type="snapshot" version="1">
    <snapshot session_id="d9f6dc91-0394-40b9-9663-66aef4bb623a"
        repository_version="1" index="2">
        <publish uri="http://host/foo/bar/cer1.cer">
            MIIE+jCCA+KgAwIBAgIBDTANBgkqhkiG9w0BAQsFADAzMTEwLwYDVQQD
            jRBODAxN0U2NkE5RTkxNzJFNDYxMkQ4Q0Y0QzgzRjIzOERFMkEzMB4XE
            ........................................................
            h8zeHoFVu6ghRPy5dbOA4akX/KG6b8XIx0iwPYdLiDbdWFbtTdPcXBau
        </publish>
        <publish uri="http://host/foo/bar/cer2.cer">
            MIIE+jCCA+KgAwIBAgIBDTANBgkqhkiG9w0BAQsFADAzMTEwLwYDVQQD
            h8zeHoFVu6ghRPy5dbOA4akX/KG6b8XIx0iwPYdLiDbdWFbtTdPcXBau
            ........................................................
            jRBODAxN0U2NkE5RTkxNzJFNDYxMkQ4Q0Y0QzgzRjIzOERFMkEzMB4XD
        </publish>
        <publish uri="http://host/foo/bar/cer3.cer">
            MIIE+jCCA+KgAwIBAgIBDTANBgkqhkiG9w0BAQsFADAzMTEwLwYDVQQD
            h8zeHoFVu6ghRPy5dbOA4akX/KG6b8XIx0iwPYdLiDbdWFbtTdPcXBau
            ........................................................
            jRBODAxN0U2NkE5RTkxNzJFNDYxMkQ4Q0Y0QzgzRjIzOERFMkEzMB4XD
        </publish>
    </snapshot>
</msg>

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.

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:

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:

3.6.2.1. DELTA ELEMENT

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).

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).

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.

3.6.3. Sample DELTAS file

<?xml version="1.0" encoding="us-ascii"?>
<msg type="deltas" version="1"
    xmlns="http://www.ripe.net/rpki/rrdp">
    <deltas session_id="d9f6dc91-0394-40b9-9663-66aef4bb623a"
        from="0" to="3" index="4">
        <delta version="1">
            <publish uri="http://host/foo/bar/cer1.cer">
                MIIE+jCCA+KgAwIBAgIBDTANBgkqhkiG9w0BAQsFADAzMTEw
                jRBODAxN0U2NkE5RTkxNzJFNDYxMkQ4Q0Y0QzgzRjIzOERFM
                ................................................
                h8zeHoFVu6ghRPy5dbOA4akX/KG6b8XIx0iwPYdLiDbdWFbt
            </publish>
        </delta>
        <delta version="2">
            <withdraw uri="http://host/foo/bar/cer1.cer" />
            <publish uri="http://host/foo/bar/cer2.cer">
                MIIE+jCCA+KgAwIBAgIBDTANBgkqhkiG9w0BAQsFADAzMTEw
                h8zeHoFVu6ghRPy5dbOA4akX/KG6b8XIx0iwPYdLiDbdWFbt
                ................................................
                jRBODAxN0U2NkE5RTkxNzJFNDYxMkQ4Q0Y0QzgzRjIzOERFM
            </publish>
            <publish uri="http://host/foo/bar/cer3.cer">
                MIIE+jCCA+KgAwIBAgIBDTANBgkqhkiG9w0BAQsFADAzMTEw
                h8zeHoFVu6ghRPy5dbOA4akX/KG6b8XIx0iwPYdLiDbdWFbt
                ................................................
                jRBODAxN0U2NkE5RTkxNzJFNDYxMkQ4Q0Y0QzgzRjIzOERFM
            </publish>
        </delta>
        <delta version="3">
            <withdraw uri="http://host/foo/bar/cer2.cer" />
        </delta>
    </deltas>
</msg>
                        

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.

3.7. SIA for CA certificates

Certificate Authorities that use this delta protocol MUST have an instance of an SIA AccessDescription in addition to the ones defined in [RFC6487],

          AccessDescription ::= SEQUENCE {
            accessMethod OBJECT IDENTIFIER,
            accessLocation GeneralName }
            

This extension MUST use an accessMethod of id-ad-rrdpNotify,

            id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
            id-ad-rrdpNotify OBJECT IDENTIFIER ::= { id-ad TBD }
            

The accessLocation MUST be a URI [RFC3986], using the 'http' protocol, that will point to the update notification file for the publication server that publishes the products of this CA certificate.

4. Security Considerations

TBD

5. IANA Considerations

This document has no actions for IANA.

6. Acknowledgements

TBD

7. Normative References

Authors' Addresses