One document matched: draft-tbruijnzeels-sidr-delta-protocol-03.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-tbruijnzeels-sidr-delta-protocol-03">
<?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 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.</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), certification 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 publication server
and communication 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 an RP can retrieve over http(s). 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 immutable 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 for caching infrastructure to be used to serve this immutable data, and thus helps
to reduce the load on a publication 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 publication server to publish their RPKI products, such as
manifests, CRLs, signed certificates and RPKI signed objects. This publication server may be remote, or embedded
in the CA engine itself. Certificates in the RPKI that use a publication 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 publication servers, and a list of links to delta
files, for each revision starting at a point determined by the publication server, up to the current revision of the repository.</t>
<t>This notification file is intended to be small so that is can easily be fetched over HTTP(S). The publication server may use HTTP
caching infrastructure to reduce its load. The publication server should should avoid using a long caching interval,
since the length of this interval determines when RPs will receive updated notification files, and thereby new products
produced by Certification Authorities using this publication server. It is recommended that of no longer than five minutes
is used for caching this file. If the caching infrastructure supports it another useful approach would
be to expire the cache for the notification file URI as soon as a new notification file is known to be published.</t>
<t>An RP that first learns about a notification file location 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 publication
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 should not try to fetch the same file more
frequently 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 with the current state.</t>
<t>If no contiguous chain of updates is available, or if the session_id has changed, the latest snapshot should
be used instead. In this case the RP should then add the objects found in the latest snapshot to its local repository.</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 an 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 publication server may use http 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 publication
server at a certain point in time. For this reason these files can be cached indefinitely. To support this the
publication server must use a globally unique URL for the location of each of these snapshot and delta files. It
is recommended that old versions of snapshot and delta files remain available for download for some time after
they have last appeared on a notification file to provide some resiliency in case relying parties are slow to
process.</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
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.</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 http(s) requests to a central repository server. However, since this file is used by RPs to determine
whether any updates are available it is strongly RECOMMENDED to use a short interval for caching, to avoid
unnecessary delays. A maximum of delay of 5 minutes after a new notification file has been published seems
like a reasonable compromise. This delay should not cause major problems for RPs and routing since a similar
human time scale is expected to be involved in updating the contents of the RPKI on the one hand, i.e. creating
and publishing new ROAs or router certificates, and updating actual BGP announcements in routers on the other.
That said, real world measurements are needed on this subject, so this recommended maximum time may be subject
to change in future.</t>
<t>There are various ways to ensure that the notification file is only cached for a certain time in
caching infrastructure and different solutions, such as commercial Content Delivery Networks (CDNs),
may provide different ways of achieving this. For example some CDNs have custom support to cache a
file such as this notification file indefinetely, but allow a central server to notify the CDN through
some protocol that an update is available and trigger the CDN to then refresh this file. In general a
publication server may find certain HTTP headers to be useful, such as: Cache-Control: max-age=300 </t>
<t>Finally it shoulf be noted that snapshot and delta files are intended to be cache-able for a much longer
longer time. In support of this the URIs for each snapshot and delta file for a given session_id and serial
number MUST be unique and the contents of those files MUST NOT change.</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="2">
<snapshot uri="HTTP://rpki.ripe.net/rpki-ca/rrdp/EEEA7F7AD96D85BBD1F7274FA7DA0025984A2AF3D5A0538F77BEC732ECB1B068.xml" hash="EEEA7F7AD96D85BBD1F7274FA7DA0025984A2AF3D5A0538F77BEC732ECB1B068"/>
<delta serial="2" uri="HTTP://rpki.ripe.net/rpki-ca/rrdp/198BD94315E9372D7F15688A5A61C7BA40D318210CDC799B6D3F9F24831CF21B.xml" hash="198BD94315E9372D7F15688A5A61C7BA40D318210CDC799B6D3F9F24831CF21B"/>
<delta serial="1" uri="HTTP://rpki.ripe.net/rpki-ca/rrdp/8DE946FDA8C6A6E431DFE3622E2A3E36B8F477B81FAFCC5E7552CC3350C609CC.xml" hash="8DE946FDA8C6A6E431DFE3622E2A3E36B8F477B81FAFCC5E7552CC3350C609CC"/>
</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 starting at a revision determined by the publication server, up
to the current version of the repository.</t>
<t>The hash attribute in snapshot and delta elements must be the hexadecimal encoding of the SHA-256 hash of the referenced file. The
RP SHOULD verify this hash when the file is retrieved and reject it if it does not match.</t>
</list>
</t>
</section>
<section title="Publication Server Initialisation" anchor="Initialise">
<t>When the publication 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 publication 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 publication server MUST publish a new notification file that contains the new session_id, has serial number ONE, has
one reference to the snaphot file that was just published, and that contains no delta references.</t>
</section>
<section title="Publishing Updates">
<t>Whenever the publication server receives updates from a CA it SHOULD generate an update as follows.</t>
<t>The new repository serial MUST be one greater than the current repository serial. A new delta file MUST be generated for
this new serial, that contains all the updates, i.e. new, replaced and withdrawn objects, as a single change set. 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. The
format and caching concerns for delta files are explained in more detail below in <xref target="Delta"/>.</t>
<t>The publication server MUST also generate a new snaphost file for this new serial, that contains all current objects for
this new serial. In other words it should include all publish elements found in this update, and it should exclude all
previous publish elements for objects that have been withdrawn or updated. As above this new file MUST be made available
at a URL that is unique to this session_id and new version before proceeding.</t>
<t>Finally an updated notification file MUST be created by the publication server. This new notification file MUST include
a reference to the new snaphot 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>
<t>The publication server MAY also choose to include fewer delta files if it is found that the efficiency gain in keeping
notification files small outweighs the overhead of forcing a small number of relying parties to process full snapshot files.
At the time of this writing it is not completely clear what would constitute reasonable parameters to determine this balance.
Real world measurements are needed to help this discussion. Possible approaches are:
<list style="symbols">
<t>The publication server may learn the retrieval distribution of old delta files by RPs over time, and
decide to exclude deltas from the point where less than e.g. 0.1% of RPs would retrieve them.</t>
<t>The server may decide to support deltas only for a limited time, e.g. 6 hours. So that RPs can recover
easily from restart or reasonably short outage scenarios, and are only forced to do a full re-sync
in case of prolonged outages.</t>
</list>
</t>
<t>If the publication 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. There 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 repository server MAY use caching infrastructure to cache snapshot files and reduce the load
of http(s) requests to a central repository server. To support this it is important that snaphot
files for a specific session_id and serial have a unique URL. The files themselves reflect the
content of the repository at a specific point in time, and for that reason they never change.
Aside from space concerns this means that these files MAY therefore be cached indefinitely.</t>
<t>To support RPs that are slow to process old, possibly cached, notification files, the publication
server SHOULD ensure that old snapshot files remain available for some time after have last appeared
on a notification file. It is RECOMMENDED that these files are kept for at least two times as
long as the notification file cache period, i.e. 10 minutes. However, space permitting, the publication
server is welcome to keep these files available for longer.</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="5932">
<publish uri="rsync://bandito.ripe.net/repo/671570f06499fbd2d6ab76c4f22566fe49d5de60.cer">
MIIFNDCCBBygAwIBAgIBAjANBgkqhkiG9w0BAQsFADANMQswCQYDVQQDEwJUQTAeFw0xNDExMTMw
MzU4MjlaFw0xNTExMTMwMzU4MjlaMDMxMTAvBgNVBAMTKDY3MTU3MGYwNjQ5OWZiZDJkNmFiNzZj
NGYyMjU2NmZlNDlkNWRlNjAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDOlUYxDPwu
hqVSG5VXcg96qTYt9aKOH8qV2lAU/jnY1rRl2W5Uoa8RrAIseou8ltLKonMcVulHyoyY+J9GqrzN
45vRSgBaOuvLn6nTuoD0LQsD/m8c/wEmFjQllirxQykLGJLXn1eKdUs/OXGgrAUPzgvkciJdsg69
6X44deHcbCU0ZQZSLxZBZEqjfgyoYgww9n/hK5Sfkb44LsBK1lESdBSRrTpFizrCxl22ptsH0eW4
ek80CV5YgCg4F4u9xlzS2DvB+1X3Nl1vvTZ6TJlpVjIVcvE+sKQ50ntUwWG1+lOJc+twRehhiCAb
yHhfaxID4B+7h5Rcpkh1Q1AUMG9JAgMBAAGjggJ3MIICczAdBgNVHQ4EFgQUZxVw8GSZ+9LWq3bE
8iVm/knV3mAwHwYDVR0jBBgwFoAUd4IboVLl+9bEbD6VrCsnqRClFNUwDwYDVR0TAQH/BAUwAwEB
/zAOBgNVHQ8BAf8EBAMCAQYwRQYIKwYBBQUHAQEEOTA3MDUGCCsGAQUFBzAChilodHRwOi8vYmFu
ZGl0by5yaXBlLm5ldC9ycGtpLWNhL3RhL3RhLmNlcjCCATAGCCsGAQUFBwELBIIBIjCCAR4wVwYI
KwYBBQUHMAWGS3JzeW5jOi8vYmFuZGl0by5yaXBlLm5ldC9yZXBvLzNhODdhNGIxLTZlMjItNGE2
My1hZDBmLTA2ZjgzYWQzY2ExNi9kZWZhdWx0LzCBgwYIKwYBBQUHMAqGd3JzeW5jOi8vYmFuZGl0
by5yaXBlLm5ldC9yZXBvLzNhODdhNGIxLTZlMjItNGE2My1hZDBmLTA2ZjgzYWQzY2ExNi9kZWZh
dWx0LzY3MTU3MGYwNjQ5OWZiZDJkNmFiNzZjNGYyMjU2NmZlNDlkNWRlNjAubWZ0MD0GCCsGAQUF
BzANhjFodHRwOi8vYmFuZGl0by5yaXBlLm5ldC9ycGtpLWNhL25vdGlmeS9ub3RpZnkueG1sMFsG
A1UdHwRUMFIwUKBOoEyGSnJzeW5jOi8vYmFuZGl0by5yaXBlLm5ldC9yZXBvLzc3ODIxYmExNTJl
NWZiZDZjNDZjM2U5NWFjMmIyN2E5MTBhNTE0ZDUuY3JsMBgGA1UdIAEB/wQOMAwwCgYIKwYBBQUH
DgIwHgYIKwYBBQUHAQcBAf8EDzANMAsEAgABMAUDAwDAqDANBgkqhkiG9w0BAQsFAAOCAQEAkAnl
E+Fm1r3cmW8EEwhq4Wo37j7qC8ciU/E/zJqptROd8M8+2PDjCF8K7plf/SqYNUWjCk8zQv7Siala
DP3JNI7oWkJ5K9zSU/qPGD8UbrfK5EF4g+++OAsxsOf/qeMVdZ6FlPIUV0wYj2s9w1zz/r16HFV6
QO785ajB50foqo/oQ74BSRbrlYkWrM8U45rdSiAMlyr0lHgv0OCqNK6AVR6y9Sp6bBUi7RotZ5FN
x0TgBRTA6xp4pjG5FimX1SanMaW1hgYqdc4X5aZ9gPiyqvBcOtFq91WnNTsm5Ox0cPNDCkMPLAwW
pHOiFA0PlD0vBPrvTR1hsgfKGd318Qzq+w==
</publish>
<publish uri="rsync://bandito.ripe.net/repo/77821ba152e5fbd6c46c3e95ac2b27a910a514d5.mft">
MIAGCSqGSIb3DQEHAqCAMIACAQMxDzANBglghkgBZQMEAgEFADCABgsqhkiG9w0BCRABGqCAJIAE
gd0wgdoCAguWGA8yMDE0MTIwMzE4MDgzMloYDzIwMTQxMjA0MTgwODMyWgYJYIZIAWUDBAIBMIGm
MFEWLDY3MTU3MGYwNjQ5OWZiZDJkNmFiNzZjNGYyMjU2NmZlNDlkNWRlNjAuY2VyAyEAh0nT6uSg
nJQhGAnKgjxb9TDeGu9AEd8QK+GHXYop0U8wURYsNzc4MjFiYTE1MmU1ZmJkNmM0NmMzZTk1YWMy
YjI3YTkxMGE1MTRkNS5jcmwDIQAZ658FmRCmFfxCpTfE8hZN00MnUEdohOiISZflCPbrUwAAAAAA
AKCAMIIEcjCCA1qgAwIBAgICC5gwDQYJKoZIhvcNAQELBQAwDTELMAkGA1UEAxMCVEEwHhcNMTQx
MjAzMTgwODMyWhcNMTQxMjEwMTgwODMyWjAzMTEwLwYDVQQDEyhlY2Y0NjhkMDY1MTMyNzFmNTkz
MjZhNjQ2MGZmOTFhYTNiNGU2Njk4MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkiYz
EpnsqHIPNEl/LvJmfZfOYzRlhv0Ewqg/RLi6XsE5dhWi0YAiFLbz0v/PfAjmJJFO6STsXkmc5Cpp
PoAl2+Ffx9Zujzy95hCNMqNgPSsqA92eAStLJALlvWrlYgTQEBV/hIjetDOEY/fL49gajyuKghOh
+zgeEUCVhdIArEj/4j5E1vI7flwJjLP8SI36IWlKoz6cd88Gm8bLQRURAfe2lKW0quJk0RHOnPZk
babWuiiByoU24DCSy1+TBY4mEK6bi1R0iONqeYfaSUrxvWcDh8V6gNikiB+tfwRxrIOO1RTnKnlI
hIe2OC5mkP2gMY5ZUyynJZnS3Or+CY3IcQIDAQABo4IBtDCCAbAwHQYDVR0OBBYEFOz0aNBlEycf
WTJqZGD/kao7TmaYMB8GA1UdIwQYMBaAFHeCG6FS5fvWxGw+lawrJ6kQpRTVMA4GA1UdDwEB/wQE
AwIHgDBFBggrBgEFBQcBAQQ5MDcwNQYIKwYBBQUHMAKGKWh0dHA6Ly9iYW5kaXRvLnJpcGUubmV0
L3Jwa2ktY2EvdGEvdGEuY2VyMGYGCCsGAQUFBwELBFowWDBWBggrBgEFBQcwC4ZKcnN5bmM6Ly9i
YW5kaXRvLnJpcGUubmV0L3JlcG8vNzc4MjFiYTE1MmU1ZmJkNmM0NmMzZTk1YWMyYjI3YTkxMGE1
MTRkNS5tZnQwWwYDVR0fBFQwUjBQoE6gTIZKcnN5bmM6Ly9iYW5kaXRvLnJpcGUubmV0L3JlcG8v
Nzc4MjFiYTE1MmU1ZmJkNmM0NmMzZTk1YWMyYjI3YTkxMGE1MTRkNS5jcmwwGAYDVR0gAQH/BA4w
DDAKBggrBgEFBQcOAjAhBggrBgEFBQcBBwEB/wQSMBAwBgQCAAEFADAGBAIAAgUAMBUGCCsGAQUF
BwEIAQH/BAYwBKACBQAwDQYJKoZIhvcNAQELBQADggEBAAjCpzNzjj7QGhmIG3Elt49cHUJe865w
y2Uq3ZKW2aZgA5It29D07XlsHO8tM0EWVXTxsBbpdkiEnzQ4G8Zx/ZI09vLSJ8ZjzSh42QeMaNt6
6zslilaw9rQcm/5jwxN18BRniwU/oavfRbn36AhfCmpegII/4DTZWjI63wucRrYHTHZm6ZajnHKU
DT1viomKZoZZDAUB4oQ7pN/Mw+t1K9F50VKz+9i3tnVhyt5wVaoEn/4sGRAL680A8Su0MKiyc69t
3DYqnvSgYtFNiBbHhNYooBpraylh5r7WngBxfm+VJYkSaPxU8T6sSz/Capt+1S2UWJGTcFaZl251
bm8nmXcAADGCAawwggGoAgEDgBTs9GjQZRMnH1kyamRg/5GqO05mmDANBglghkgBZQMEAgEFAKBr
MBoGCSqGSIb3DQEJAzENBgsqhkiG9w0BCRABGjAcBgkqhkiG9w0BCQUxDxcNMTQxMjAzMTgwODMy
WjAvBgkqhkiG9w0BCQQxIgQgOUbuFjfSw4aMeIgLlDmT5xI7D05/mH6zVETECtMzWb0wDQYJKoZI
hvcNAQEBBQAEggEAbhfERg8rgzy0GAIPDKj5kNk+owpm7WnRDiUo+6Y30zfKKjFhh1L+N0Ei7b6q
r934eqEoac23wycF/A1e3+d4PoLzvFrm1n9rIia4BaD8GiUle6FEHd5njS7jOt5Kuej64yDFCHtv
ipt8tGFik4MpvEmP5EOhZ1cU/sErvlpdEsxQCaLsb6JUbIvoIHnWGXHE54QXkBvlucUSxypRoqW3
SnAX0vo0F1YNrSDe05So3pjjSmNHOuFFnxZMja+lIMMWTFylbKQJNpLIrb9a/uarfiL9BrGODWqE
dzQh+k3QkTAUojq+YADL+ixO0eg2zpPm+eEU1F2+bGP2M5rbaUfqngAAAAAAAA==
</publish>
<publish uri="rsync://bandito.ripe.net/repo/77821ba152e5fbd6c46c3e95ac2b27a910a514d5.crl">
MIIBnzCBiAIBATANBgkqhkiG9w0BAQsFADANMQswCQYDVQQDEwJUQRcNMTQxMjAzMTgwODMyWhcN
MTQxMjA0MTgwODMyWjAVMBMCAguXFw0xNDEyMDMxODA4MzJaoDAwLjAfBgNVHSMEGDAWgBR3ghuh
UuX71sRsPpWsKyepEKUU1TALBgNVHRQEBAICC5YwDQYJKoZIhvcNAQELBQADggEBAFQHr/2ids7e
hmfnX+PmyePSN2EM1fBMLwMud6dqyBF42iNa8N0H/jxMAkgm7SS98TUupZg1aIwqxLwGakFS6VeD
+zCnCGEeMUlXTpZaICDxMxJuJLBOVbqP2amPxWJ22g0+gTXM9KPAoWlNyAiMaNUP+nawjyfMzQ4c
WJjIi1kRHnIhiu9cZwEh9Ns/sC3adPJ8NV6LPpMkQDQvIynxV/fbTf/EwwwRfLy1szGLZSdml4G0
gHohkWaosr4R2A7sZOc/PZGtstqpBRTD8RwVJx0pseC6Zp/01WH/FjzNpXahFPgR1QXy3qBGEHRh
xA08g0+QiGSz+QX5PPQ2dBkTRIY=
</publish>
</snapshot>]]></artwork>
</figure>
<t>The following validation 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>The hexadecimal encoding of the SHA-256 hash of this snapshot file MUST match the hash attribute in the reference in the notification file.</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 publication 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 publication 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>A repository server MAY use caching infrastructure to cache delta files and reduce the load
of http(s) requests to a central repository server. To support this it is important that delta
files for a specific session_id and serial have a unique URL. The files themselves reflect the
content of the repository at a specific point in time, and for that reason they never change.
Aside from space concerns this means that these files MAY therefore be cached indefinitely.</t>
<t>To support RPs that are slow to process old, possibly cached, notification files, the publication
server SHOULD ensure that old delta files remain available for some time after have last appeared
on a notification file. It is RECOMMENDED that these files are kept for at least two times as
long as the notification file cache period, i.e. 10 minutes. However, space permitting, the publication
server is welcome to keep these files available for longer.</t>
</section>
<section title="File Format and Validation">
<t>Example snapshot file:</t>
<figure>
<artwork> <![CDATA[
<delta xmlns="HTTP://www.ripe.net/rpki/rrdp" version="1" session_id="9df4b597-af9e-4dca-bdda-719cce2c4e28" serial="5932">
<publish uri="rsync://bandito.ripe.net/repo/3a87a4b1-6e22-4a63-ad0f-06f83ad3ca16/default/671570f06499fbd2d6ab76c4f22566fe49d5de60.mft" hash="226AB8CD3C887A6EBDDDF317F2FAFC9CF3EFC5D43A86347AC0FEFFE4DC0F607E">
MIAGCSqGSIb3DQEHAqCAMIACAQMxDzANBglghkgBZQMEAgEFADCABgsqhkiG9w0BCRABGqCAJIAE
gYkwgYYCAguWGA8yMDE0MTIwMzE4MDg0MFoYDzIwMTQxMjA0MTgwODQwWgYJYIZIAWUDBAIBMFMw
URYsNjcxNTcwZjA2NDk5ZmJkMmQ2YWI3NmM0ZjIyNTY2ZmU0OWQ1ZGU2MC5jcmwDIQD1h9mcwKzN
70He/gIMVxszGJlIXLh/TGzkaNTXxLixmwAAAAAAAKCAMIIFGjCCBAKgAwIBAgICC5YwDQYJKoZI
hvcNAQELBQAwMzExMC8GA1UEAxMoNjcxNTcwZjA2NDk5ZmJkMmQ2YWI3NmM0ZjIyNTY2ZmU0OWQ1
ZGU2MDAeFw0xNDEyMDMxODA4NDBaFw0xNDEyMTAxODA4NDBaMDMxMTAvBgNVBAMTKDMzMTI1YzA4
NmEwOWEyOTJkYzQxMWI1MzkwODA2ZDA4NTMxM2E1MTQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQCak1G7912fuezSWPpPqER3aZaP4HShGiIiRWeJLOYKpklAeSO8kRa9R+yDCa9CMi1B
lewW/C5Coomb9teVZRg31YkpZlXqqNGg8GVesNMJX3ryuizQ+WRUcgwJoakqWH7wPu5zdfFj4Cpk
BpgJF+6TBYwXTjAmxfFP0hm0QLWCLxEd1gBGEdBmOogHqfOZHU95GLjllzsPRmR13kyh7BbYMie+
ENJAqqKBlQvW86xPEDMJKUc0uQDnTPCZQBqFwE1xrgUAuSCfJMUguAE8clsshOFe8ROF9t6NIBxK
oxA+PTYCpcthCBtdCFyWn/SLp1pb3gIA6xP9ESGlRHNumPL3AgMBAAGjggI2MIICMjAdBgNVHQ4E
FgQUMxJcCGoJopLcQRtTkIBtCFMTpRQwHwYDVR0jBBgwFoAUZxVw8GSZ+9LWq3bE8iVm/knV3mAw
DgYDVR0PAQH/BAQDAgeAMGcGCCsGAQUFBwEBBFswWTBXBggrBgEFBQcwAoZLcnN5bmM6Ly9iYW5k
aXRvLnJpcGUubmV0L3JlcG8vM2E4N2E0YjEtNmUyMi00YTYzLWFkMGYtMDZmODNhZDNjYTE2L2Rl
ZmF1bHQvMIGWBggrBgEFBQcBCwSBiTCBhjCBgwYIKwYBBQUHMAuGd3JzeW5jOi8vYmFuZGl0by5y
aXBlLm5ldC9yZXBvLzNhODdhNGIxLTZlMjItNGE2My1hZDBmLTA2ZjgzYWQzY2ExNi9kZWZhdWx0
LzY3MTU3MGYwNjQ5OWZiZDJkNmFiNzZjNGYyMjU2NmZlNDlkNWRlNjAubWZ0MIGJBgNVHR8EgYEw
fzB9oHugeYZ3cnN5bmM6Ly9iYW5kaXRvLnJpcGUubmV0L3JlcG8vM2E4N2E0YjEtNmUyMi00YTYz
LWFkMGYtMDZmODNhZDNjYTE2L2RlZmF1bHQvNjcxNTcwZjA2NDk5ZmJkMmQ2YWI3NmM0ZjIyNTY2
ZmU0OWQ1ZGU2MC5jcmwwGAYDVR0gAQH/BA4wDDAKBggrBgEFBQcOAjAhBggrBgEFBQcBBwEB/wQS
MBAwBgQCAAEFADAGBAIAAgUAMBUGCCsGAQUFBwEIAQH/BAYwBKACBQAwDQYJKoZIhvcNAQELBQAD
ggEBAEO1dSFDN4wZqtZ0fWo5G0YVN+mtk6tKhHPFwX7ydTofnHZkE2pO7C93XcgPcP4zLUBPt5kS
aH+0vcBxs9Vg//58cHRUEHhls9O/XcS8RXCVkNiga+9NB5s4oi0+i/gDU3eOUqE/jqSJAJAS+Ehi
tvNh0LuLrW92NrOfbYDk29how3uxK4JucIAQ05i63l7EAeQp3WeI8nVzB9Rfrkv+PSV+57mSXXtJ
/jWu3kyjvsxRjeUL3Im2Z1F48zfVF6pVaDT7ib4YbKOyAQTMpi4W6NZwgQskda9B8/0qV/d+2JrC
m3Ozm0t2laoH8xKP/OC33bBXLCxUvkVqvB/Y+TUXfAEAADGCAawwggGoAgEDgBQzElwIagmiktxB
G1OQgG0IUxOlFDANBglghkgBZQMEAgEFAKBrMBoGCSqGSIb3DQEJAzENBgsqhkiG9w0BCRABGjAc
BgkqhkiG9w0BCQUxDxcNMTQxMjAzMTgwODQwWjAvBgkqhkiG9w0BCQQxIgQgdNPMbp9lJJHNMmIz
00ff73VkVFYWo2Uf6/b4zIzFZucwDQYJKoZIhvcNAQEBBQAEggEAXHNHm+DUD1s9IQMewvKsoNGi
fXL2jG3yfuGys5x1aJji3bIKGiU+weHmnP9aoH9UFRLk6pW1wFOS0+6M87UD8cU17w9F10e0258S
9p7xHMgbrYqXrX9OucMqiN4M+ThDzyDXnfNAOgw5XNJu9KRndS9vyXS6lcvD7JTOhkyqKsrqHXlM
0pX+rYFtrF2RNjB54veooSkcKGojXReLttZbvVKWKwkVg2RJy4tt7MOGU0Q6qa/J5S7O6xvwPjkY
yCFvrHm+CgeXoR/3Hg/Rk/NdsK4K1u5dXhRh3KYv4P/hnGSD83aFE9t/DTicvl6SjaXFCtLtJlTX
BqSW7wgZ6OoLxwAAAAAAAA==
</publish>
<publish uri="rsync://bandito.ripe.net/repo/3a87a4b1-6e22-4a63-ad0f-06f83ad3ca16/default/671570f06499fbd2d6ab76c4f22566fe49d5de60.crl" hash="2B551A6C10CCA04C174B0CEB3B64652A5534D1385BEAA40A55A68CB06055E6BB">
MIIBxTCBrgIBATANBgkqhkiG9w0BAQsFADAzMTEwLwYDVQQDEyg2NzE1NzBmMDY0OTlmYmQyZDZh
Yjc2YzRmMjI1NjZmZTQ5ZDVkZTYwFw0xNDEyMDMxODA4NDBaFw0xNDEyMDQxODA4NDBaMBUwEwIC
C5UXDTE0MTIwMzE4MDg0MFqgMDAuMB8GA1UdIwQYMBaAFGcVcPBkmfvS1qt2xPIlZv5J1d5gMAsG
A1UdFAQEAgILljANBgkqhkiG9w0BAQsFAAOCAQEAIbL+8connmKLeypzs/P6FOHv8elmLp6dFlId
SDpZT7p6y9xLZkvuow39XOs6NB1AOA+92uao9hEV1XuEBGP98nsx0frL8HJtKcEn0q5LGqA4YeBG
n28+Ldvlh4DetiKvFpsKW/VYqjRumHcgTdWpESY/f9hH3xW6JCggH5cFGFF/dCsCdGT1v+m53zf4
Dlz8KhRDEaok3UMycX9XUWMB5HSwf05Qrha2LIFf66uk6AQQEmV9ZiBq3IdbkdNd90TIVDMvnSW/
p9Xygdx8azaE2+hsOc9J7+E2kBuu4isLhvfZmChtFpxIUrljQRD4iUil8/xmB6MAIptoF1EslpAI
aw==
</publish>
<withdraw uri="rsync://bandito.ripe.net/repo/3a87a4b1-6e22-4a63-ad0f-06f83ad3ca16/default/example.roa" hash="2B551A6C10CCA04C174B0CEB3B64652A5534D1385BEAA40A55A68CB06055E6BB"/>
</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 update notification file that is incomplete or not well formed.</t>
<t>The following validation rules must be observed when creating or parsing snapshot 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 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 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>The hexadecimal encoding of the SHA-256 hash of this snapshot file MUST match the hash attribute in the reference in the notification file.</t>
<t>A publish element MUST include a hash attribute, if the object is intended to replace another object in the RPKI, and
its value MUST be the hexadecimal encoding of the SHA-256 hash of the replaced object. If the published object does not replace
another object the hash attribute MUST NOT be included. Note that this is an extension to the publication protocol
that is not, yet, reflected in <xref target="I-D.ietf-sidr-publication"/>.</t>
<t>Similarly a withdraw element MUST contain a hash attribute with the hexadecimal encoding of the SHA-256 hash of the
withdrawn object. Including the hashes in this manner allows relying parties to identify specific objects by their
hash rather than the URI where they are found.</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 'HTTP' or 'HTTPS' protocol, that will point
to the update notification file for the publication server that publishes the products of this CA certificate.</t>
<t>Relying Parties that do not support this delta protocol MUST 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 publication server.</t>
<t>The RP SHOULD reject the snapshot file and raise an operator alert, if its hash does not match the
hash listed in the notification file. However, if the RP does not have any prior state it may choose
to process this snapshot file anyway. It should be noted that the RPKI objects are protected by object
security, so problems or attacks on the publication server or transport can result in witholding or
replaying old objects, but it cannot force the RP to accept invalid objects. Using the remaining or
old objects for validation is probably better than rejecting everything, since the latter could be
used as a denial of service vector on relying parties.</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. How frequently the RP does this
is largely up to local policy. The polling frequency determines in part what propogation time that a RP
is willing to accept between the moment that a change is published in the RPKI, and the moment that
those changes are processed and validated. As discussed in <xref target="Notify-Cache"/> there does not
seem to be a need to have a propogation time that is below five minutes. Since the publication server
infrastructure MAY cache the notification file for up to five minutes a slightly more frequent polling
strategy may be useful, however the RP SHOULD NOT poll more frequently than once per minute. More frequent
polling would only result in marginal gains in propagation, while causing unnecessary load on the caching
infrastructure.</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 publication 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 publication
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 its hash does not match the hash listed on the notification file,
or if no such chain of deltas is availabe, 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 publication 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 revoked them, removed the objects from a
valid manifest that it issued, or 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 14:32:37 |