Network Working Group                                     T. Bruijnzeels
Internet-Draft                                              O. Muravskiy
Intended status: Standards Track                                RIPE NCC
Expires: March 07, 2015                                         B. Weber
                                                                Cobenian
                                                      September 05, 2014

                     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 07, 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




Bruijnzeels, Muravskiy & Expires March 07, 2015                 [Page 1]


Internet-Draft       RPKI Repository Delta Protocol       September 2014

   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.2.1.  SNAPSHOT ELEMENT . . . . . . . . . . . . . . . . .  5
         3.4.2.2.  SNAPSHOT SEGMENT ELEMENT . . . . . . . . . . . . .  6
         3.4.2.3.  DELTAS ELEMENT . . . . . . . . . . . . . . . . . .  6
         3.4.2.4.  DELTA SEGMENT ELEMENT  . . . . . . . . . . . . . .  6
       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.2.1.  PUBLISH ELEMENT  . . . . . . . . . . . . . . . . . 10
       3.5.3.  Sample SNAPSHOT SEGMENT file . . . . . . . . . . . . . 10
       3.5.4.  Applying changes from snapshot segments  . . . . . . . 11
     3.6.  Incremental Delta Format . . . . . . . . . . . . . . . . . 11
       3.6.1.  Root Element . . . . . . . . . . . . . . . . . . . . . 11
       3.6.2.  Contents . . . . . . . . . . . . . . . . . . . . . . . 12
         3.6.2.1.  DELTA ELEMENT  . . . . . . . . . . . . . . . . . . 12
           3.6.2.1.1.  WITHDRAW ELEMENT . . . . . . . . . . . . . . . 12
           3.6.2.1.2.  PUBLISH ELEMENT  . . . . . . . . . . . . . . . 13
       3.6.3.  Sample DELTAS file . . . . . . . . . . . . . . . . . . 13
       3.6.4.  Applying changes from delta segments . . . . . . . . . 14
     3.7.  SIA for CA certificates  . . . . . . . . . . . . . . . . . 14
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
   7.  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







Bruijnzeels, Muravskiy & Expires March 07, 2015                 [Page 2]


Internet-Draft       RPKI Repository Delta Protocol       September 2014


   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






Bruijnzeels, Muravskiy & Expires March 07, 2015                 [Page 3]


Internet-Draft       RPKI Repository Delta Protocol       September 2014

   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.





Bruijnzeels, Muravskiy & Expires March 07, 2015                 [Page 4]


Internet-Draft       RPKI Repository Delta Protocol       September 2014

   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.

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.



Bruijnzeels, Muravskiy & Expires March 07, 2015                 [Page 5]


Internet-Draft       RPKI Repository Delta Protocol       September 2014


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


Bruijnzeels, Muravskiy & Expires March 07, 2015                 [Page 6]


Internet-Draft       RPKI Repository Delta Protocol       September 2014


   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

























Bruijnzeels, Muravskiy & Expires March 07, 2015                 [Page 7]


Internet-Draft       RPKI Repository Delta Protocol       September 2014


   <?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"

Bruijnzeels, Muravskiy & Expires March 07, 2015                 [Page 8]


Internet-Draft       RPKI Repository Delta Protocol       September 2014

   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:

   +-----------+--------------------------------------------+----------+
   | Attribute | Description                                | Value    |
   +-----------+--------------------------------------------+----------+
   |    type   | The type of this RRDP message.             | snapshot |
   |  version  | The RRDP protocol version of this message. | 1        |
   +-----------+--------------------------------------------+----------+


Bruijnzeels, Muravskiy & Expires March 07, 2015                 [Page 9]


Internet-Draft       RPKI Repository Delta Protocol       September 2014


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









Bruijnzeels, Muravskiy & Expires March 07, 2015                [Page 10]


Internet-Draft       RPKI Repository Delta Protocol       September 2014


   <?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:






Bruijnzeels, Muravskiy & Expires March 07, 2015                [Page 11]


Internet-Draft       RPKI Repository Delta Protocol       September 2014


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






Bruijnzeels, Muravskiy & Expires March 07, 2015                [Page 12]


Internet-Draft       RPKI Repository Delta Protocol       September 2014


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

3.6.3.  Sample DELTAS file





















Bruijnzeels, Muravskiy & Expires March 07, 2015                [Page 13]


Internet-Draft       RPKI Repository Delta Protocol       September 2014


   <?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],



Bruijnzeels, Muravskiy & Expires March 07, 2015                [Page 14]


Internet-Draft       RPKI Repository Delta Protocol       September 2014


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

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3986]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66, RFC
              3986, January 2005.

   [RFC6487]  Huston, G., Michaelson, G. and R. Loomans, "A Profile for
              X.509 PKIX Resource Certificates", RFC 6487, February
              2012.

Authors' Addresses

   Tim Bruijnzeels
   RIPE NCC

   Email: tim@ripe.net


   Oleg Muravskiy
   RIPE NCC

   Email: oleg@ripe.net



Bruijnzeels, Muravskiy & Expires March 07, 2015                [Page 15]


Internet-Draft       RPKI Repository Delta Protocol       September 2014


   Bryan Weber
   Cobenian

   Email: bryan@cobenian.com

















































Bruijnzeels, Muravskiy & Expires March 07, 2015                [Page 16]