One document matched: draft-ietf-sidr-delta-protocol-01.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
]>
<rfc category="std" ipr="trust200902" docName="draft-ietf-sidr-delta-protocol-01">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<front>
<title>RPKI Repository Delta Protocol</title>
<author initials='T.' surname="Bruijnzeels" fullname='Tim Bruijnzeels'>
<organization>RIPE NCC</organization>
<address>
<email>tim@ripe.net</email>
</address>
</author>
<author initials='O.' surname="Muravskiy" fullname='Oleg Muravskiy'>
<organization>RIPE NCC</organization>
<address>
<email>oleg@ripe.net</email>
</address>
</author>
<author initials='B.' surname="Weber" fullname='Bryan Weber'>
<organization>Cobenian</organization>
<address>
<email>bryan@cobenian.com</email>
</address>
</author>
<author initials='R.' surname="Austein" fullname='Rob Austein'>
<organization>Dragon Research Labs</organization>
<address>
<email>sra@hactrn.net</email>
</address>
</author>
<author initials='D.' surname="Mandelberg" fullname='David Mandelberg'>
<organization>BBN Technologies</organization>
<address>
<email>david@mandelberg.org</email>
</address>
</author>
<date />
<abstract>
<t>In the Resource Public Key Infrastructure (RPKI), certificate authorities publish certificates, including end
entity certificates, and CRLs to repositories on repository 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.</t>
</abstract>
</front>
<middle>
<section title="Requirements notation">
<t>
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 <xref target="RFC2119" />.</t>
</section>
<section title="Introduction">
<t>In the Resource Public Key Infrastructure (RPKI), Certificate Authorities (CAs) publish certificates <xref target="RFC6487" />,
RPKI signed objects <xref target="RFC6488" />, manifests <xref target="RFC6486" />, and CRLs to repositories.
CAs may have an embedded mechanism to publish to these repositories, or they may use a separate repository server
and publication protocol. RPKI repositories are currently
accessible using rsync, allowing Relying Parties (RPs) to synchronise a local copy of the RPKI repository
used for validation with the central repositories using the rsync protocol <xref target="RFC6481" />.</t>
<t>This document specifies an alternative repository access protocol based on notification, snapshot and delta
files that a RP can retrieve over HTTPS. This allows RPs to perform a full (re-)synchronisation of their
local copy of the repository using snapshot files. However, typically RPs will use delta files to keep their
local repository updated after initial synchronisation.</t>
<t>This protocol is designed to be consistent with the publication protocol <xref target="I-D.ietf-sidr-publication"/>
and treats publication events of one or more repository objects as discrete events that can be communicated to
relying parties. This approach helps 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.
Finally, this approach allows these discrete events to be communicated as immutable files, so that caching infrastructure
can be used to reduce the load on a repository server when a large a number of relying parties are querying it.</t>
</section>
<section title="RPKI Repository Delta Protocol Implementation">
<section title="Informal Overview">
<t>Certification Authorities (CA) in the RPKI use a repository server to publish their RPKI products, such as
manifests, CRLs, signed certificates and RPKI signed objects. This repository server may be remote, or embedded
in the CA engine itself. Certificates in the RPKI that use a repository server that supports this delta protocol
include a special Subject Information Access (SIA) pointer referring to a notification file.</t>
<t>The notification file includes a globally unique session_id in the form of a version 4 UUID, and serial number that can be
used by the Relying Party (RP) to determine if it and the repository are synchronised. Furthermore it includes a link to the
most recent complete snapshot of current objects that are published by the repository servers, and a list of links to delta
files, for each revision starting at a point determined by the repository server, up to the current revision of the repository.</t>
<t>A RP that learns about a notification file location for the first time can download it, and then proceed to download
the latest snapshot file, and thus create a local copy of the repository that is in sync with the repository
server. The RP should remember the location of this notification file, the session_id and current serial number.</t>
<t>RPs are encouraged to re-fetch this notification file at regular intervals, but not more often than once per minute.
After re-fetching the notification file, the RP may find that there are one or more delta files available that allow it to
synchronise its local repository with the current state of the repository server. If no contiguous chain of deltas from RP's
serial to the latest repository serial is available, or if the session_id has changed, the RP should perform a full
resynchronisation instead.</t>
<t>As soon as the RP fetches new content in this way it should start a validation process using its local
repository. An example of a reason why a RP may not do this immediately is because it has learned of more than one
notification location and it prefers to complete all its updates before validating.</t>
<t>The repository server may use caching infrastructure to reduce its load. It should be noted that snapshots
and deltas for any given session_id and serial number contain an immutable record of the state of the repository
server at a certain point in time. For this reason these files can be cached indefinitely. Notification files
are polled by RPs to discover if updates exist, and for this reason notification files may not be cached for
longer than one minute.</t>
</section>
<section title="Update Notification File">
<section title="Purpose">
<t>The update notification file is used by RPs to discover whether any changes exist between the state of the
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 synchronise with the repository.</t>
</section>
<section title="Cache Concerns" anchor="Notify-Cache">
<t>A repository server MAY use caching infrastructure to cache the notification file and reduce the load
of HTTPS requests. However, since this file is used by RPs to determine whether any updates are available
the repository server MUST ensure that this file is not cached for longer than 1 minute. An exception to
this rule is that it is better to serve a stale notification file, then no notification file.</t>
<t>How this is achieved exactly depends on the caching infrastructure used. In general a repository
server may find certain http headers to be useful, such as: Cache-Control: max-age=60. Another approach
can be to have the repository server push out new versions of the notification file to the caching
infrastructure when appropriate.</t>
<t>Relying Parties SHOULD not cache the notification file for longer than 1 minute, regardless of the
headers set by the repository server or CDN.</t>
</section>
<section title="File Format and Validation">
<t>Example notification file:</t>
<figure>
<artwork> <![CDATA[
<notification xmlns="http://www.ripe.net/rpki/rrdp"
version="1"
session_id="9df4b597-af9e-4dca-bdda-719cce2c4e28"
serial="3">
<snapshot uri="https://rpki.ripe.net/rrdp/9d--8/3/snapshot.xml"/>
<delta serial="3" uri="https://rpki.ripe.net/rrdp/9d--8/3/delta.xml"/>
<delta serial="2" uri="https://rpki.ripe.net/rrdp/9d--8/2/delta.xml"/>
</notification>
]]></artwork>
</figure>
<t>The following validation rules must be observed when creating or parsing notification files:
<list style="symbols">
<t>A RP MUST NOT process any update notification file that is not well formed, or which does not conform to the RELAX NG
schema outlined in <xref target="Relax-NG" /> of this document.</t>
<t>The XML namespace MUST be http://www.ripe.net/rpki/rrdp</t>
<t>The encoding MUST be us-ascii</t>
<t>The version attribute in the notification root element MUST be 1</t>
<t>The session_id attribute MUST be a random version 4 UUID unique to this session</t>
<t>The serial attribute must be an unbounded, unsigned positive integer indicating the current version of the repository.</t>
<t>The notification file MUST contain exactly one 'snapshot' element for the current repository version.</t>
<t>If delta elements are included they MUST form a contiguous sequence of serial numbers starting at a revision determined by the repository server, up
to the serial number mentioned in the notification element.</t>
</list>
</t>
</section>
<section title="Repository Server Initialisation" anchor="Initialise">
<t>When the repository server (re-) initialises it MUST generate a new random version 4 UUID to be used as the session_id.
Furthermore it MUST then generate a snapshot file for serial number ONE for this new session that includes all currently
known published objects that the repository server is responsible for. This snapshot file MUST be made available at a URL
that is unique to this session and version, so that it can be cached indefinitely. The format and caching concerns for
snapshot files are explained in more detail below in <xref target="Snapshot"/>. After the snapshot file has been published
the repository server MUST publish a new notification file that contains the new session_id, has serial number ONE, has
one reference to the snapshot file that was just published, and that contains no delta references.</t>
</section>
<section title="Publishing Updates">
<t>Whenever the repository server receives updates from a CA it SHOULD generate new snapshot and delta files and publish a
new notification file as follows:
<list style="symbols">
<t>The new repository serial MUST be one greater than the current repository serial.</t>
<t>A new delta file MUST be generated for this new serial. This delta file MUST include all new, replaced and
withdrawn objects, as a single change set.</t>
<t>This delta file MUST be made available at a URL that is unique to this session and version, so that it can be cached
indefinitely.</t>
<t>The repository server MUST also generate a new snaphost file for this new serial. This file MUST contain all publish
elements for all current objects.</t>
<t>The snapshot file MUST be made available at a URL that is unique to this session and new version, so that it can be cached
indefinitely.</t>
<t>A new notification file MUST be created by the repository server. This new notification file MUST include
a reference to the new snapshot file. The file SHOULD also include available delta files for this and previous updates.
However, the server MUST NOT include more delta files than, when combined, exceed the size of the current snapshot.</t>
</list>
</t>
<t>If the repository server is not capable of performing the above for some reason, then it MUST perform a full
re-initialisation, as explained above in <xref target="Initialise"/>.</t>
</section>
</section>
<section title="Snapshot File" anchor="Snapshot">
<section title="Purpose">
<t>A snapshot is intended to reflect the complete and current contents of the repository for a specific session and version.
Therefore it MUST contain all objects from the repository current as of the time of the publication.</t>
</section>
<section title="Cache Concerns" anchor="Snapshot-Cache">
<t>A snapshot reflects the content of the repository at a specific point in time, and for that reason
can be considered immutable data. Snapshot files MUST be published at a URL that is unique to the
specific session and serial.</t>
<t>Because these files never change, they MAY be cached indefinitely. However, in order to prevent that
these files use a lot of space in caching infrastructure it is RECOMMENDED that a limited interval
is used in the order of hours or days.</t>
<t>Repository servers MAY delete old snapshot files one hour after they are no longer included in the notification file.</t>
</section>
<section title="File Format and Validation">
<t>Example snapshot file:</t>
<figure>
<artwork> <![CDATA[
<snapshot xmlns="http://www.ripe.net/rpki/rrdp"
version="1"
session_id="9df4b597-af9e-4dca-bdda-719cce2c4e28"
serial="2">
<publish uri="rsync://rpki.ripe.net/Alice/Bob.cer">
ZXhhbXBsZTE=
</publish>
<publish uri="rsync://rpki.ripe.net/repo/Alice/Alice.mft">
ZXhhbXBsZTI=
</publish>
<publish uri="rsync://rpki.ripe.net/repo/Alice/Alice.crl">
ZXhhbXBsZTM=
</publish>
</snapshot>]]></artwork>
</figure>
<t>The following rules must be observed when creating or parsing snapshot files:
<list style="symbols">
<t>A RP MUST NOT process any snapshot file that is not well formed, or which does not conform to the RELAX NG
schema outlined in <xref target="Relax-NG" /> of this document.</t>
<t>The XML namespace MUST be http://www.ripe.net/rpki/rrdp.</t>
<t>The encoding MUST be us-ascii.</t>
<t>The version attribute in the notification root element MUST be 1</t>
<t>The session_id attribute MUST match the expected session_id in the reference in the notification file.</t>
<t>The serial attribute MUST match the expected serial in the reference in the notification file.</t>
<t>Note that the publish element is defined in the publication protocol <xref target="I-D.ietf-sidr-publication"/></t>
</list>
</t>
</section>
</section>
<section title="Delta File" anchor="Delta">
<section title="Purpose">
<t>An incremental delta file contains all changes for exactly one serial increment of the repository server.
In other words a single delta will typically include all the new objects, updated objects and withdrawn objects
that a Certification Authority sent to the repository server. In its simplest form the update could concern
only a single object, but it is recommended that CAs send all changes for one of their key pairs: i.e. updated
objects as well as a new manifest and CRL as one atomic update message.
</t>
</section>
<section title="Cache Concerns" anchor="Delta-Cache">
<t>Deltas reflect a the difference between two consecutive versions of a repository for a given session. For
that reason deltas can be considered immutable data. Delta files MUST be published at a URL that is unique
to the specific session and serial.</t>
<t>Because these files never change, they MAY be cached indefinitely. However, in order to prevent these files
from using a lot of space in caching infrastructure it is RECOMMENDED that a limited interval is used in the
order of hours or days.</t>
<t>Repository servers MAY delete old delta files one hour after they are no longer included in the notification file.</t>
</section>
<section title="File Format and Validation">
<t>Example delta file:</t>
<figure>
<artwork> <![CDATA[
<delta xmlns="http://www.ripe.net/rpki/rrdp"
version="1"
session_id="9df4b597-af9e-4dca-bdda-719cce2c4e28"
serial="3">
<publish uri="rsync://rpki.ripe.net/repo/Alice/Alice.mft"
hash="50d8...545c">
ZXhhbXBsZTQ=
</publish>
<publish uri="rsync://rpki.ripe.net/repo/Alice/Alice.crl"
hash="5fb1...6a56">
ZXhhbXBsZTU=
</publish>
<withdraw uri="rsync://rpki.ripe.net/repo/Alice/Bob.cer"
hash="caeb...15c1"/>
</delta>]]></artwork>
</figure>
<t>Note that a formal RELAX NG specification of this file format is included later in this document. A RP MUST
NOT process any delta file that is incomplete or not well formed.</t>
<t>The following validation rules must be observed when creating or parsing delta files:
<list style="symbols">
<t>A RP MUST NOT process any delta file that is not well formed, or which does not conform to the RELAX NG
schema outlined in <xref target="Relax-NG" /> of this document.</t>
<t>The XML namespace MUST be http://www.ripe.net/rpki/rrdp.</t>
<t>The encoding MUST be us-ascii.</t>
<t>The version attribute in the delta root element MUST be 1</t>
<t>The session_id attribute MUST be a random version 4 UUID unique to this session</t>
<t>The session_id attribute MUST match the expected session_id in the reference in the notification file.</t>
<t>The serial attribute MUST match the expected serial in the reference in the notification file.</t>
<t>Note that the publish and withdraw elements are defined in the publication protocol <xref target="I-D.ietf-sidr-publication"/></t>
</list>
</t>
</section>
</section>
<section title="SIA for CA certificates">
<t>
Certificate Authorities that use this delta protocol MUST have an instance of an SIA AccessDescription in
addition to the ones defined in <xref target="RFC6487" />,
</t>
<t>
<figure>
<artwork><![CDATA[
AccessDescription ::= SEQUENCE {
accessMethod OBJECT IDENTIFIER,
accessLocation GeneralName }
]]></artwork>
</figure>
</t>
<t>
This extension MUST use an accessMethod of id-ad-rpkiNotify, see: <xref target="IANA-AD-NUMBERS" />,
</t>
<t>
<figure>
<artwork><![CDATA[
id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
id-ad-rpkiNotify OBJECT IDENTIFIER ::= { id-ad 13 }
]]></artwork>
</figure>
</t>
<t>
The accessLocation MUST be a URI <xref target="RFC3986" />, using the 'https' scheme, that will point
to the update notification file for the repository server that publishes the products of this CA certificate.</t>
<t>Relying Parties that do not support this delta protocol MUST NOT reject a CA certificate merely because it
has an SIA extension containing this new kind of AccessDescription.</t>
</section>
</section>
<section title="Relying Party Use">
<section title="Full Synchronisation">
<t>When a Relying Party first encounters a notification file URI as an SIA of a certificate that it has
validated it SHOULD retrieve the notification file and download the latest snapshot to get in sync
with the current version of the repository server.</t>
</section>
<section title="Processing Deltas">
<t>It is RECOMMENDED that the RP notes the URI, session_id and serial number when it first learns about a
notification file. The RP MAY then poll the file to discover updates, but SHOULD NOT poll more frequently
than once per minute.</t>
<t>If the RP finds that the session_id has changed, or if it cannot find a contiguous chain of links to delta
files from its current serial to repository server's current serial, then it MUST perform a full
synchronisation instead of continuing to process deltas.</t>
<t>If the RP finds a contiguous chain of links to delta files from its current serial to the repository
server's current serial, and the session_id has not changed, it should download all missing delta files.
If any delta file cannot be downloaded, or if no such chain of deltas is available, or the session_id has
changed, then the RP MUST perform a full synchronisation instead.</t>
<t>New objects found in delta files can be added to the RPs local copy of the repository. However, it is
RECOMMENDED that the RP treats object updates and withdraws with some skepticism. A compromised repository server
may not have access to the certification authorities' keys, but it can pretend valid objects have been withdrawn.
Therefore it may be preferred to use a strategy where local copies of objects are only discarded when the
RP is sure that they are no longer relevant, e.g. the CA has explicitly removed the objects in a recent valid
manifest and revoked them in a recent valid CRL (unless they have expired).</t>
</section>
</section>
<section title="XML Schema" anchor="Relax-NG">
<t>The following is a RELAX NG compact form schema describing version 1 of this protocol.</t>
<figure>
<artwork><![CDATA[
#
# RelaxNG schema for RPKI Repository Delta Protocol (RRDP).
#
default namespace = "http://www.ripe.net/rpki/rrdp"
version = xsd:positiveInteger { maxInclusive="1" }
serial = xsd:nonNegativeInteger
uri = xsd:anyURI
uuid = xsd:string { pattern = "[\-0-9a-fA-F]+" }
hash = xsd:string { pattern = "[0-9a-fA-F]+" }
base64 = xsd:base64Binary
# Notification file: lists current snapshots and deltas
start |= element notification {
attribute version { version },
attribute session_id { uuid },
attribute serial { serial },
element snapshot {
attribute uri { uri },
attribute hash { hash }
},
element delta {
attribute serial { serial },
attribute uri { uri },
attribute hash { hash }
}*
}
# Snapshot segment: think DNS AXFR.
start |= element snapshot {
attribute version { version },
attribute session_id { uuid },
attribute serial { serial },
element publish {
attribute uri { uri },
base64
}*
}
# Delta segment: think DNS IXFR.
start |= element delta {
attribute version { version },
attribute session_id { uuid },
attribute serial { serial },
delta_element+
}
delta_element |= element publish {
attribute uri { uri },
attribute hash { hash }?,
base64
}
delta_element |= element withdraw {
attribute uri { uri },
attribute hash { hash }
}
# Local Variables:
# indent-tabs-mode: nil
# comment-start: "# "
# comment-start-skip: "#[ \t]*"
# End:
]]></artwork>
</figure>
</section>
<section title="Security Considerations">
<t>TBD</t>
</section>
<section title="IANA Considerations">
<t>This document has no actions for IANA.</t>
</section>
<section title="Acknowledgements">
<t>TBD</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119.xml"?>
<?rfc include="reference.RFC.3986.xml"?>
<?rfc include="reference.RFC.6481.xml"?>
<?rfc include="reference.RFC.6486.xml"?>
<?rfc include="reference.RFC.6488.xml"?>
<?rfc include="reference.RFC.6487.xml"?>
<?rfc include="reference.I-D.ietf-sidr-publication"?>
<reference anchor="IANA-AD-NUMBERS" target="http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.48">
<front>
<title>SMI Security for PKIX Access Descriptor</title>
<author/>
<date/>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 03:33:32 |