idnits 2.17.1 draft-tbruijnzeels-sidr-delta-protocol-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 116 instances of too long lines in the document, the longest one being 140 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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. -- The document date (December 22, 2014) is 3406 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-12) exists of draft-ietf-sidr-publication-05 -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-AD-NUMBERS' ** Obsolete normative reference: RFC 6486 (Obsoleted by RFC 9286) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Bruijnzeels 3 Internet-Draft O. Muravskiy 4 Intended status: Standards Track RIPE NCC 5 Expires: June 23, 2015 B. Weber 6 Cobenian 7 R. Austein 8 Dragon Research Labs 9 D. Mandelberg 10 BBN Technologies 11 December 22, 2014 13 RPKI Repository Delta Protocol 14 draft-tbruijnzeels-sidr-delta-protocol-03 16 Abstract 18 In the Resource Public Key Infrastructure (RPKI), certificate 19 authorities publish certificates, including end entity certificates, 20 and CRLs to repositories on publication servers. Relying Parties 21 (RP) retrieve the published information from the repository and MAY 22 store it in a cache. This document specifies a delta protocol which 23 provides relying parties with a mechanism to query a repository for 24 changes, thus enabling the RP to keep its state in sync with the 25 repository. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on June 23, 2015. 44 Copyright Notice 46 Copyright (c) 2014 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Simplified BSD License text 55 as described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Simplified BSD License. 58 Table of Contents 60 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 61 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 62 3. RPKI Repository Delta Protocol Implementation . . . . . . . . 3 63 3.1. Informal Overview . . . . . . . . . . . . . . . . . . . . 3 64 3.2. Update Notification File . . . . . . . . . . . . . . . . . 5 65 3.2.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.2.2. Cache Concerns . . . . . . . . . . . . . . . . . . . . 5 67 3.2.3. File Format and Validation . . . . . . . . . . . . . . 5 68 3.2.4. Publication Server Initialisation . . . . . . . . . . 6 69 3.2.5. Publishing Updates . . . . . . . . . . . . . . . . . . 6 70 3.3. Snapshot File . . . . . . . . . . . . . . . . . . . . . . 7 71 3.3.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 7 72 3.3.2. Cache Concerns . . . . . . . . . . . . . . . . . . . . 7 73 3.3.3. File Format and Validation . . . . . . . . . . . . . . 8 74 3.4. Delta File . . . . . . . . . . . . . . . . . . . . . . . . 10 75 3.4.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 10 76 3.4.2. Cache Concerns . . . . . . . . . . . . . . . . . . . . 11 77 3.4.3. File Format and Validation . . . . . . . . . . . . . . 11 78 3.5. SIA for CA certificates . . . . . . . . . . . . . . . . . 13 79 4. Relying Party Use . . . . . . . . . . . . . . . . . . . . . . 14 80 4.1. Full Synchronisation . . . . . . . . . . . . . . . . . . . 14 81 4.2. Processing Deltas . . . . . . . . . . . . . . . . . . . . 14 82 5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 85 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 89 1. Requirements notation 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [RFC2119]. 95 2. Introduction 96 In the Resource Public Key Infrastructure (RPKI), certification 97 authorities (CAs) publish certificates [RFC6487], RPKI signed 98 objects [RFC6488] , manifests [RFC6486] and CRLs to repositories. 99 CAs may have an embedded mechanism to publish to these repositories, 100 or they may use a separate publication server and communication 101 protocol. RPKI repositories are currently accessible using rsync, 102 allowing Relying Parties (RPs) to synchronise a local copy of the 103 RPKI repository used for validation with the central repositories 104 using the rsync protocol [RFC6481]. 106 This document specifies an alternative repository access protocol 107 based on notification, snapshot and delta files that an RP can 108 retrieve over http(s). This allows RPs to perform a full 109 (re-)synchronisation of their local copy of the repository using 110 snapshot files. However, typically RPs will use delta files to keep 111 their local repository updated after initial synchronisation. 113 This protocol is designed to be consistent with the publication 114 protocol [I-D.ietf-sidr-publication] and treats publication events of 115 one or more repository objects as immutable events that can be 116 communicated to relying parties. This approach helps to minimize the 117 amount of data that traverses the network and thus helps minimize the 118 amount of time until repository convergence occurs. This protocol 119 also provides a standards based way to obtain consistent, point in 120 time views of a single repository eliminating a number of consistency 121 related issues. Finally, this approach allows for caching 122 infrastructure to be used to serve this immutable data, and thus 123 helps to reduce the load on a publication server when a large a 124 number of relying parties are querying it. 126 3. RPKI Repository Delta Protocol Implementation 128 3.1. Informal Overview 130 Certification Authorities (CA) in the RPKI use a publication server 131 to publish their RPKI products, such as manifests, CRLs, signed 132 certificates and RPKI signed objects. This publication server may be 133 remote, or embedded in the CA engine itself. Certificates in the 134 RPKI that use a publication server that supports this delta protocol 135 include a special Subject Information Access (SIA) pointer referring 136 to a notification file. 138 The notification file includes a globally unique session_id in the 139 form of a version 4 UUID, and serial number that can be used by the 140 Relying Party (RP) to determine if it and the repository are 141 synchronised. Furthermore it includes a link to the most recent 142 complete snapshot of current objects that are published by the 143 publication servers, and a list of links to delta files, for each 144 revision starting at a point determined by the publication server, up 145 to the current revision of the repository. 147 This notification file is intended to be small so that is can easily 148 be fetched over HTTP(S). The publication server may use HTTP caching 149 infrastructure to reduce its load. The publication server should 150 should avoid using a long caching interval, since the length of this 151 interval determines when RPs will receive updated notification files, 152 and thereby new products produced by Certification Authorities using 153 this publication server. It is recommended that of no longer than 154 five minutes is used for caching this file. If the caching 155 infrastructure supports it another useful approach would be to expire 156 the cache for the notification file URI as soon as a new notification 157 file is known to be published. 159 An RP that first learns about a notification file location can 160 download it, and then proceed to download the latest snapshot file, 161 and thus create a local copy of the repository that is in sync with 162 the publication server. The RP should remember the location of this 163 notification file, the session_id and current serial number. 165 RPs are encouraged to re-fetch this notification file at regular 166 intervals, but should not try to fetch the same file more frequently 167 than once per minute. After re-fetching the notification file, the 168 RP may find that there are one or more delta files available that 169 allow it to synchronise with the current state. 171 If no contiguous chain of updates is available, or if the session_id 172 has changed, the latest snapshot should be used instead. In this 173 case the RP should then add the objects found in the latest snapshot 174 to its local repository. 176 As soon as the RP fetches new content in this way it should start a 177 validation process using its local repository. An example of a 178 reason why an RP may not do this immediately is because it has 179 learned of more than one notification location and it prefers to 180 complete all its updates before validating. 182 The publication server may use http caching infrastructure to reduce 183 its load. It should be noted that snapshots and deltas for any given 184 session_id and serial number contain an immutable record of the state 185 of the publication server at a certain point in time. For this 186 reason these files can be cached indefinitely. To support this the 187 publication server must use a globally unique URL for the location of 188 each of these snapshot and delta files. It is recommended that old 189 versions of snapshot and delta files remain available for download 190 for some time after they have last appeared on a notification file to 191 provide some resiliency in case relying parties are slow to process. 193 3.2. Update Notification File 195 3.2.1. Purpose 197 The update notification file is used by RPs to discover whether any 198 changes exist between the state of the publication server's 199 repository and the RP's cache. It describes the location of the 200 files containing the snapshot and incremental deltas which can be 201 used by the RP to synchronize with the repository. 203 3.2.2. Cache Concerns 205 A repository server MAY use caching infrastructure to cache the 206 notification file and reduce the load of http(s) requests to a 207 central repository server. However, since this file is used by RPs 208 to determine whether any updates are available it is strongly 209 RECOMMENDED to use a short interval for caching, to avoid unnecessary 210 delays. A maximum of delay of 5 minutes after a new notification 211 file has been published seems like a reasonable compromise. This 212 delay should not cause major problems for RPs and routing since a 213 similar human time scale is expected to be involved in updating the 214 contents of the RPKI on the one hand, i.e. creating and publishing 215 new ROAs or router certificates, and updating actual BGP 216 announcements in routers on the other. That said, real world 217 measurements are needed on this subject, so this recommended maximum 218 time may be subject to change in future. 220 There are various ways to ensure that the notification file is only 221 cached for a certain time in caching infrastructure and different 222 solutions, such as commercial Content Delivery Networks (CDNs), may 223 provide different ways of achieving this. For example some CDNs have 224 custom support to cache a file such as this notification file 225 indefinetely, but allow a central server to notify the CDN through 226 some protocol that an update is available and trigger the CDN to then 227 refresh this file. In general a publication server may find certain 228 HTTP headers to be useful, such as: Cache-Control: max-age=300 230 Finally it shoulf be noted that snapshot and delta files are intended 231 to be cache-able for a much longer longer time. In support of this 232 the URIs for each snapshot and delta file for a given session_id and 233 serial number MUST be unique and the contents of those files MUST NOT 234 change. 236 3.2.3. File Format and Validation 238 Example notification file: 240 241 242 243 244 246 The following validation rules must be observed when creating or 247 parsing notification files: 249 o A RP MUST NOT process any update notification file that is not 250 well formed, or which does not conform to the RELAX NG schema 251 outlined in Section 5 of this document. 252 o The XML namespace MUST be HTTP://www.ripe.net/rpki/rrdp 253 o The encoding MUST be us-ascii 254 o The version attribute in the notification root element MUST be 1 255 o The session_id attribute MUST be a random version 4 UUID unique to 256 this session 257 o The serial attribute must be an unbounded, unsigned positive 258 integer indicating the current version of the repository. 259 o The notification file MUST contain exactly one 'snapshot' element 260 for the current repository version. 261 o If delta elements are included they MUST form a contiguous 262 sequence starting at a revision determined by the publication 263 server, up to the current version of the repository. 264 o The hash attribute in snapshot and delta elements must be the 265 hexadecimal encoding of the SHA-256 hash of the referenced file. 266 The RP SHOULD verify this hash when the file is retrieved and 267 reject it if it does not match. 269 3.2.4. Publication Server Initialisation 271 When the publication server (re-) initialises it MUST generate a new 272 random version 4 UUID to be used as the session_id. Furthermore it 273 MUST then generate a snapshot file for serial number ONE for this new 274 session that includes all currently known published objects that the 275 publication server is responsible for. This snapshot file MUST be 276 made available at a URL that is unique to this session and version, 277 so that it can be cached indefinitely. The format and caching 278 concerns for snapshot files are explained in more detail below in 279 Section 3.3. After the snapshot file has been published the 280 publication server MUST publish a new notification file that contains 281 the new session_id, has serial number ONE, has one reference to the 282 snaphot file that was just published, and that contains no delta 283 references. 285 3.2.5. Publishing Updates 287 Whenever the publication server receives updates from a CA it SHOULD 288 generate an update as follows. 290 The new repository serial MUST be one greater than the current 291 repository serial. A new delta file MUST be generated for this new 292 serial, that contains all the updates, i.e. new, replaced and 293 withdrawn objects, as a single change set. This delta file MUST be 294 made available at a URL that is unique to this session and version, 295 so that it can be cached indefinitely. The format and caching 296 concerns for delta files are explained in more detail below in 297 Section 3.4. 299 The publication server MUST also generate a new snaphost file for 300 this new serial, that contains all current objects for this new 301 serial. In other words it should include all publish elements found 302 in this update, and it should exclude all previous publish elements 303 for objects that have been withdrawn or updated. As above this new 304 file MUST be made available at a URL that is unique to this 305 session_id and new version before proceeding. 307 Finally an updated notification file MUST be created by the 308 publication server. This new notification file MUST include a 309 reference to the new snaphot file. The file SHOULD also include 310 available delta files for this and previous updates. However, the 311 server MUST not include more delta files than, when combined, exceed 312 the size of the current snapshot. 314 The publication server MAY also choose to include fewer delta files 315 if it is found that the efficiency gain in keeping notification files 316 small outweighs the overhead of forcing a small number of relying 317 parties to process full snapshot files. At the time of this writing 318 it is not completely clear what would constitute reasonable 319 parameters to determine this balance. Real world measurements are 320 needed to help this discussion. Possible approaches are: 322 o The publication server may learn the retrieval distribution of old 323 delta files by RPs over time, and decide to exclude deltas from 324 the point where less than e.g. 0.1% of RPs would retrieve them. 325 o The server may decide to support deltas only for a limited time, 326 e.g. 6 hours. So that RPs can recover easily from restart or 327 reasonably short outage scenarios, and are only forced to do a 328 full re-sync in case of prolonged outages. 330 If the publication server is not capable of performing the above for 331 some reason, then it MUST perform a full re-initialisation, as 332 explained above in Section 3.2.4. 334 3.3. Snapshot File 336 3.3.1. Purpose 338 A snapshot is intended to reflect the complete and current contents 339 of the repository. There it MUST contain all objects from the 340 repository current as of the time of the publication. 342 3.3.2. Cache Concerns 343 A repository server MAY use caching infrastructure to cache snapshot 344 files and reduce the load of http(s) requests to a central repository 345 server. To support this it is important that snaphot files for a 346 specific session_id and serial have a unique URL. The files 347 themselves reflect the content of the repository at a specific point 348 in time, and for that reason they never change. Aside from space 349 concerns this means that these files MAY therefore be cached 350 indefinitely. 352 To support RPs that are slow to process old, possibly cached, 353 notification files, the publication server SHOULD ensure that old 354 snapshot files remain available for some time after have last 355 appeared on a notification file. It is RECOMMENDED that these files 356 are kept for at least two times as long as the notification file 357 cache period, i.e. 10 minutes. However, space permitting, the 358 publication server is welcome to keep these files available for 359 longer. 361 3.3.3. File Format and Validation 363 Example snapshot file: 365 366 367 MIIFNDCCBBygAwIBAgIBAjANBgkqhkiG9w0BAQsFADANMQswCQYDVQQDEwJUQTAeFw0xNDExMTMw 368 MzU4MjlaFw0xNTExMTMwMzU4MjlaMDMxMTAvBgNVBAMTKDY3MTU3MGYwNjQ5OWZiZDJkNmFiNzZj 369 NGYyMjU2NmZlNDlkNWRlNjAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDOlUYxDPwu 370 hqVSG5VXcg96qTYt9aKOH8qV2lAU/jnY1rRl2W5Uoa8RrAIseou8ltLKonMcVulHyoyY+J9GqrzN 371 45vRSgBaOuvLn6nTuoD0LQsD/m8c/wEmFjQllirxQykLGJLXn1eKdUs/OXGgrAUPzgvkciJdsg69 372 6X44deHcbCU0ZQZSLxZBZEqjfgyoYgww9n/hK5Sfkb44LsBK1lESdBSRrTpFizrCxl22ptsH0eW4 373 ek80CV5YgCg4F4u9xlzS2DvB+1X3Nl1vvTZ6TJlpVjIVcvE+sKQ50ntUwWG1+lOJc+twRehhiCAb 374 yHhfaxID4B+7h5Rcpkh1Q1AUMG9JAgMBAAGjggJ3MIICczAdBgNVHQ4EFgQUZxVw8GSZ+9LWq3bE 375 8iVm/knV3mAwHwYDVR0jBBgwFoAUd4IboVLl+9bEbD6VrCsnqRClFNUwDwYDVR0TAQH/BAUwAwEB 376 /zAOBgNVHQ8BAf8EBAMCAQYwRQYIKwYBBQUHAQEEOTA3MDUGCCsGAQUFBzAChilodHRwOi8vYmFu 377 ZGl0by5yaXBlLm5ldC9ycGtpLWNhL3RhL3RhLmNlcjCCATAGCCsGAQUFBwELBIIBIjCCAR4wVwYI 378 KwYBBQUHMAWGS3JzeW5jOi8vYmFuZGl0by5yaXBlLm5ldC9yZXBvLzNhODdhNGIxLTZlMjItNGE2 379 My1hZDBmLTA2ZjgzYWQzY2ExNi9kZWZhdWx0LzCBgwYIKwYBBQUHMAqGd3JzeW5jOi8vYmFuZGl0 380 by5yaXBlLm5ldC9yZXBvLzNhODdhNGIxLTZlMjItNGE2My1hZDBmLTA2ZjgzYWQzY2ExNi9kZWZh 381 dWx0LzY3MTU3MGYwNjQ5OWZiZDJkNmFiNzZjNGYyMjU2NmZlNDlkNWRlNjAubWZ0MD0GCCsGAQUF 382 BzANhjFodHRwOi8vYmFuZGl0by5yaXBlLm5ldC9ycGtpLWNhL25vdGlmeS9ub3RpZnkueG1sMFsG 383 A1UdHwRUMFIwUKBOoEyGSnJzeW5jOi8vYmFuZGl0by5yaXBlLm5ldC9yZXBvLzc3ODIxYmExNTJl 384 NWZiZDZjNDZjM2U5NWFjMmIyN2E5MTBhNTE0ZDUuY3JsMBgGA1UdIAEB/wQOMAwwCgYIKwYBBQUH 385 DgIwHgYIKwYBBQUHAQcBAf8EDzANMAsEAgABMAUDAwDAqDANBgkqhkiG9w0BAQsFAAOCAQEAkAnl 386 E+Fm1r3cmW8EEwhq4Wo37j7qC8ciU/E/zJqptROd8M8+2PDjCF8K7plf/SqYNUWjCk8zQv7Siala 387 DP3JNI7oWkJ5K9zSU/qPGD8UbrfK5EF4g+++OAsxsOf/qeMVdZ6FlPIUV0wYj2s9w1zz/r16HFV6 388 QO785ajB50foqo/oQ74BSRbrlYkWrM8U45rdSiAMlyr0lHgv0OCqNK6AVR6y9Sp6bBUi7RotZ5FN 389 x0TgBRTA6xp4pjG5FimX1SanMaW1hgYqdc4X5aZ9gPiyqvBcOtFq91WnNTsm5Ox0cPNDCkMPLAwW 390 pHOiFA0PlD0vBPrvTR1hsgfKGd318Qzq+w== 391 392 393 MIAGCSqGSIb3DQEHAqCAMIACAQMxDzANBglghkgBZQMEAgEFADCABgsqhkiG9w0BCRABGqCAJIAE 394 gd0wgdoCAguWGA8yMDE0MTIwMzE4MDgzMloYDzIwMTQxMjA0MTgwODMyWgYJYIZIAWUDBAIBMIGm 395 MFEWLDY3MTU3MGYwNjQ5OWZiZDJkNmFiNzZjNGYyMjU2NmZlNDlkNWRlNjAuY2VyAyEAh0nT6uSg 396 nJQhGAnKgjxb9TDeGu9AEd8QK+GHXYop0U8wURYsNzc4MjFiYTE1MmU1ZmJkNmM0NmMzZTk1YWMy 397 YjI3YTkxMGE1MTRkNS5jcmwDIQAZ658FmRCmFfxCpTfE8hZN00MnUEdohOiISZflCPbrUwAAAAAA 398 AKCAMIIEcjCCA1qgAwIBAgICC5gwDQYJKoZIhvcNAQELBQAwDTELMAkGA1UEAxMCVEEwHhcNMTQx 399 MjAzMTgwODMyWhcNMTQxMjEwMTgwODMyWjAzMTEwLwYDVQQDEyhlY2Y0NjhkMDY1MTMyNzFmNTkz 400 MjZhNjQ2MGZmOTFhYTNiNGU2Njk4MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkiYz 401 EpnsqHIPNEl/LvJmfZfOYzRlhv0Ewqg/RLi6XsE5dhWi0YAiFLbz0v/PfAjmJJFO6STsXkmc5Cpp 402 PoAl2+Ffx9Zujzy95hCNMqNgPSsqA92eAStLJALlvWrlYgTQEBV/hIjetDOEY/fL49gajyuKghOh 403 +zgeEUCVhdIArEj/4j5E1vI7flwJjLP8SI36IWlKoz6cd88Gm8bLQRURAfe2lKW0quJk0RHOnPZk 404 babWuiiByoU24DCSy1+TBY4mEK6bi1R0iONqeYfaSUrxvWcDh8V6gNikiB+tfwRxrIOO1RTnKnlI 405 hIe2OC5mkP2gMY5ZUyynJZnS3Or+CY3IcQIDAQABo4IBtDCCAbAwHQYDVR0OBBYEFOz0aNBlEycf 406 WTJqZGD/kao7TmaYMB8GA1UdIwQYMBaAFHeCG6FS5fvWxGw+lawrJ6kQpRTVMA4GA1UdDwEB/wQE 407 AwIHgDBFBggrBgEFBQcBAQQ5MDcwNQYIKwYBBQUHMAKGKWh0dHA6Ly9iYW5kaXRvLnJpcGUubmV0 408 L3Jwa2ktY2EvdGEvdGEuY2VyMGYGCCsGAQUFBwELBFowWDBWBggrBgEFBQcwC4ZKcnN5bmM6Ly9i 409 YW5kaXRvLnJpcGUubmV0L3JlcG8vNzc4MjFiYTE1MmU1ZmJkNmM0NmMzZTk1YWMyYjI3YTkxMGE1 410 MTRkNS5tZnQwWwYDVR0fBFQwUjBQoE6gTIZKcnN5bmM6Ly9iYW5kaXRvLnJpcGUubmV0L3JlcG8v 411 Nzc4MjFiYTE1MmU1ZmJkNmM0NmMzZTk1YWMyYjI3YTkxMGE1MTRkNS5jcmwwGAYDVR0gAQH/BA4w 412 DDAKBggrBgEFBQcOAjAhBggrBgEFBQcBBwEB/wQSMBAwBgQCAAEFADAGBAIAAgUAMBUGCCsGAQUF 413 BwEIAQH/BAYwBKACBQAwDQYJKoZIhvcNAQELBQADggEBAAjCpzNzjj7QGhmIG3Elt49cHUJe865w 414 y2Uq3ZKW2aZgA5It29D07XlsHO8tM0EWVXTxsBbpdkiEnzQ4G8Zx/ZI09vLSJ8ZjzSh42QeMaNt6 415 6zslilaw9rQcm/5jwxN18BRniwU/oavfRbn36AhfCmpegII/4DTZWjI63wucRrYHTHZm6ZajnHKU 416 DT1viomKZoZZDAUB4oQ7pN/Mw+t1K9F50VKz+9i3tnVhyt5wVaoEn/4sGRAL680A8Su0MKiyc69t 417 3DYqnvSgYtFNiBbHhNYooBpraylh5r7WngBxfm+VJYkSaPxU8T6sSz/Capt+1S2UWJGTcFaZl251 418 bm8nmXcAADGCAawwggGoAgEDgBTs9GjQZRMnH1kyamRg/5GqO05mmDANBglghkgBZQMEAgEFAKBr 419 MBoGCSqGSIb3DQEJAzENBgsqhkiG9w0BCRABGjAcBgkqhkiG9w0BCQUxDxcNMTQxMjAzMTgwODMy 420 WjAvBgkqhkiG9w0BCQQxIgQgOUbuFjfSw4aMeIgLlDmT5xI7D05/mH6zVETECtMzWb0wDQYJKoZI 421 hvcNAQEBBQAEggEAbhfERg8rgzy0GAIPDKj5kNk+owpm7WnRDiUo+6Y30zfKKjFhh1L+N0Ei7b6q 422 r934eqEoac23wycF/A1e3+d4PoLzvFrm1n9rIia4BaD8GiUle6FEHd5njS7jOt5Kuej64yDFCHtv 423 ipt8tGFik4MpvEmP5EOhZ1cU/sErvlpdEsxQCaLsb6JUbIvoIHnWGXHE54QXkBvlucUSxypRoqW3 424 SnAX0vo0F1YNrSDe05So3pjjSmNHOuFFnxZMja+lIMMWTFylbKQJNpLIrb9a/uarfiL9BrGODWqE 425 dzQh+k3QkTAUojq+YADL+ixO0eg2zpPm+eEU1F2+bGP2M5rbaUfqngAAAAAAAA== 426 427 428 MIIBnzCBiAIBATANBgkqhkiG9w0BAQsFADANMQswCQYDVQQDEwJUQRcNMTQxMjAzMTgwODMyWhcN 429 MTQxMjA0MTgwODMyWjAVMBMCAguXFw0xNDEyMDMxODA4MzJaoDAwLjAfBgNVHSMEGDAWgBR3ghuh 430 UuX71sRsPpWsKyepEKUU1TALBgNVHRQEBAICC5YwDQYJKoZIhvcNAQELBQADggEBAFQHr/2ids7e 431 hmfnX+PmyePSN2EM1fBMLwMud6dqyBF42iNa8N0H/jxMAkgm7SS98TUupZg1aIwqxLwGakFS6VeD 432 +zCnCGEeMUlXTpZaICDxMxJuJLBOVbqP2amPxWJ22g0+gTXM9KPAoWlNyAiMaNUP+nawjyfMzQ4c 433 WJjIi1kRHnIhiu9cZwEh9Ns/sC3adPJ8NV6LPpMkQDQvIynxV/fbTf/EwwwRfLy1szGLZSdml4G0 434 gHohkWaosr4R2A7sZOc/PZGtstqpBRTD8RwVJx0pseC6Zp/01WH/FjzNpXahFPgR1QXy3qBGEHRh 435 xA08g0+QiGSz+QX5PPQ2dBkTRIY= 436 437 439 The following validation rules must be observed when creating or 440 parsing snapshot files: 442 o A RP MUST NOT process any snapshot file that is not well formed, 443 or which does not conform to the RELAX NG schema outlined in 444 Section 5 of this document. 445 o The XML namespace MUST be HTTP://www.ripe.net/rpki/rrdp. 446 o The encoding MUST be us-ascii. 447 o The version attribute in the notification root element MUST be 1 448 o The session_id attribute MUST match the expected session_id in the 449 reference in the notification file. 450 o The serial attribute MUST match the expected serial in the 451 reference in the notification file. 452 o The hexadecimal encoding of the SHA-256 hash of this snapshot file 453 MUST match the hash attribute in the reference in the notification 454 file. 456 3.4. Delta File 458 3.4.1. Purpose 459 An incremental delta file contains all changes for exactly one serial 460 increment of the publication server. In other words a single delta 461 will typically include all the new objects, updated objects and 462 withdrawn objects that a Certification Authority sent to the 463 publication server. In its simplest form the update could concern 464 only a single object, but it is recommended that CAs send all changes 465 for one of their key pairs: i.e. updated objects as well as a new 466 manifest and CRL as one atomic update message. 468 3.4.2. Cache Concerns 470 A repository server MAY use caching infrastructure to cache delta 471 files and reduce the load of http(s) requests to a central repository 472 server. To support this it is important that delta files for a 473 specific session_id and serial have a unique URL. The files 474 themselves reflect the content of the repository at a specific point 475 in time, and for that reason they never change. Aside from space 476 concerns this means that these files MAY therefore be cached 477 indefinitely. 479 To support RPs that are slow to process old, possibly cached, 480 notification files, the publication server SHOULD ensure that old 481 delta files remain available for some time after have last appeared 482 on a notification file. It is RECOMMENDED that these files are kept 483 for at least two times as long as the notification file cache period, 484 i.e. 10 minutes. However, space permitting, the publication server 485 is welcome to keep these files available for longer. 487 3.4.3. File Format and Validation 489 Example snapshot file: 491 492 493 MIAGCSqGSIb3DQEHAqCAMIACAQMxDzANBglghkgBZQMEAgEFADCABgsqhkiG9w0BCRABGqCAJIAE 494 gYkwgYYCAguWGA8yMDE0MTIwMzE4MDg0MFoYDzIwMTQxMjA0MTgwODQwWgYJYIZIAWUDBAIBMFMw 495 URYsNjcxNTcwZjA2NDk5ZmJkMmQ2YWI3NmM0ZjIyNTY2ZmU0OWQ1ZGU2MC5jcmwDIQD1h9mcwKzN 496 70He/gIMVxszGJlIXLh/TGzkaNTXxLixmwAAAAAAAKCAMIIFGjCCBAKgAwIBAgICC5YwDQYJKoZI 497 hvcNAQELBQAwMzExMC8GA1UEAxMoNjcxNTcwZjA2NDk5ZmJkMmQ2YWI3NmM0ZjIyNTY2ZmU0OWQ1 498 ZGU2MDAeFw0xNDEyMDMxODA4NDBaFw0xNDEyMTAxODA4NDBaMDMxMTAvBgNVBAMTKDMzMTI1YzA4 499 NmEwOWEyOTJkYzQxMWI1MzkwODA2ZDA4NTMxM2E1MTQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw 500 ggEKAoIBAQCak1G7912fuezSWPpPqER3aZaP4HShGiIiRWeJLOYKpklAeSO8kRa9R+yDCa9CMi1B 501 lewW/C5Coomb9teVZRg31YkpZlXqqNGg8GVesNMJX3ryuizQ+WRUcgwJoakqWH7wPu5zdfFj4Cpk 502 BpgJF+6TBYwXTjAmxfFP0hm0QLWCLxEd1gBGEdBmOogHqfOZHU95GLjllzsPRmR13kyh7BbYMie+ 503 ENJAqqKBlQvW86xPEDMJKUc0uQDnTPCZQBqFwE1xrgUAuSCfJMUguAE8clsshOFe8ROF9t6NIBxK 504 oxA+PTYCpcthCBtdCFyWn/SLp1pb3gIA6xP9ESGlRHNumPL3AgMBAAGjggI2MIICMjAdBgNVHQ4E 505 FgQUMxJcCGoJopLcQRtTkIBtCFMTpRQwHwYDVR0jBBgwFoAUZxVw8GSZ+9LWq3bE8iVm/knV3mAw 506 DgYDVR0PAQH/BAQDAgeAMGcGCCsGAQUFBwEBBFswWTBXBggrBgEFBQcwAoZLcnN5bmM6Ly9iYW5k 507 aXRvLnJpcGUubmV0L3JlcG8vM2E4N2E0YjEtNmUyMi00YTYzLWFkMGYtMDZmODNhZDNjYTE2L2Rl 508 ZmF1bHQvMIGWBggrBgEFBQcBCwSBiTCBhjCBgwYIKwYBBQUHMAuGd3JzeW5jOi8vYmFuZGl0by5y 509 aXBlLm5ldC9yZXBvLzNhODdhNGIxLTZlMjItNGE2My1hZDBmLTA2ZjgzYWQzY2ExNi9kZWZhdWx0 510 LzY3MTU3MGYwNjQ5OWZiZDJkNmFiNzZjNGYyMjU2NmZlNDlkNWRlNjAubWZ0MIGJBgNVHR8EgYEw 511 fzB9oHugeYZ3cnN5bmM6Ly9iYW5kaXRvLnJpcGUubmV0L3JlcG8vM2E4N2E0YjEtNmUyMi00YTYz 512 LWFkMGYtMDZmODNhZDNjYTE2L2RlZmF1bHQvNjcxNTcwZjA2NDk5ZmJkMmQ2YWI3NmM0ZjIyNTY2 513 ZmU0OWQ1ZGU2MC5jcmwwGAYDVR0gAQH/BA4wDDAKBggrBgEFBQcOAjAhBggrBgEFBQcBBwEB/wQS 514 MBAwBgQCAAEFADAGBAIAAgUAMBUGCCsGAQUFBwEIAQH/BAYwBKACBQAwDQYJKoZIhvcNAQELBQAD 515 ggEBAEO1dSFDN4wZqtZ0fWo5G0YVN+mtk6tKhHPFwX7ydTofnHZkE2pO7C93XcgPcP4zLUBPt5kS 516 aH+0vcBxs9Vg//58cHRUEHhls9O/XcS8RXCVkNiga+9NB5s4oi0+i/gDU3eOUqE/jqSJAJAS+Ehi 517 tvNh0LuLrW92NrOfbYDk29how3uxK4JucIAQ05i63l7EAeQp3WeI8nVzB9Rfrkv+PSV+57mSXXtJ 518 /jWu3kyjvsxRjeUL3Im2Z1F48zfVF6pVaDT7ib4YbKOyAQTMpi4W6NZwgQskda9B8/0qV/d+2JrC 519 m3Ozm0t2laoH8xKP/OC33bBXLCxUvkVqvB/Y+TUXfAEAADGCAawwggGoAgEDgBQzElwIagmiktxB 520 G1OQgG0IUxOlFDANBglghkgBZQMEAgEFAKBrMBoGCSqGSIb3DQEJAzENBgsqhkiG9w0BCRABGjAc 521 BgkqhkiG9w0BCQUxDxcNMTQxMjAzMTgwODQwWjAvBgkqhkiG9w0BCQQxIgQgdNPMbp9lJJHNMmIz 522 00ff73VkVFYWo2Uf6/b4zIzFZucwDQYJKoZIhvcNAQEBBQAEggEAXHNHm+DUD1s9IQMewvKsoNGi 523 fXL2jG3yfuGys5x1aJji3bIKGiU+weHmnP9aoH9UFRLk6pW1wFOS0+6M87UD8cU17w9F10e0258S 524 9p7xHMgbrYqXrX9OucMqiN4M+ThDzyDXnfNAOgw5XNJu9KRndS9vyXS6lcvD7JTOhkyqKsrqHXlM 525 0pX+rYFtrF2RNjB54veooSkcKGojXReLttZbvVKWKwkVg2RJy4tt7MOGU0Q6qa/J5S7O6xvwPjkY 526 yCFvrHm+CgeXoR/3Hg/Rk/NdsK4K1u5dXhRh3KYv4P/hnGSD83aFE9t/DTicvl6SjaXFCtLtJlTX 527 BqSW7wgZ6OoLxwAAAAAAAA== 528 529 530 MIIBxTCBrgIBATANBgkqhkiG9w0BAQsFADAzMTEwLwYDVQQDEyg2NzE1NzBmMDY0OTlmYmQyZDZh 531 Yjc2YzRmMjI1NjZmZTQ5ZDVkZTYwFw0xNDEyMDMxODA4NDBaFw0xNDEyMDQxODA4NDBaMBUwEwIC 532 C5UXDTE0MTIwMzE4MDg0MFqgMDAuMB8GA1UdIwQYMBaAFGcVcPBkmfvS1qt2xPIlZv5J1d5gMAsG 533 A1UdFAQEAgILljANBgkqhkiG9w0BAQsFAAOCAQEAIbL+8connmKLeypzs/P6FOHv8elmLp6dFlId 534 SDpZT7p6y9xLZkvuow39XOs6NB1AOA+92uao9hEV1XuEBGP98nsx0frL8HJtKcEn0q5LGqA4YeBG 535 n28+Ldvlh4DetiKvFpsKW/VYqjRumHcgTdWpESY/f9hH3xW6JCggH5cFGFF/dCsCdGT1v+m53zf4 536 Dlz8KhRDEaok3UMycX9XUWMB5HSwf05Qrha2LIFf66uk6AQQEmV9ZiBq3IdbkdNd90TIVDMvnSW/ 537 p9Xygdx8azaE2+hsOc9J7+E2kBuu4isLhvfZmChtFpxIUrljQRD4iUil8/xmB6MAIptoF1EslpAI 538 aw== 539 540 541 542 Note that a formal RELAX NG specification of this file format is 543 included later in this document. A RP MUST NOT process any update 544 notification file that is incomplete or not well formed. 546 The following validation rules must be observed when creating or 547 parsing snapshot files: 549 o A RP MUST NOT process any delta file that is not well formed, or 550 which does not conform to the RELAX NG schema outlined in Section 551 5 of this document. 552 o The XML namespace MUST be HTTP://www.ripe.net/rpki/rrdp. 553 o The encoding MUST be us-ascii. 554 o The version attribute in the notification root element MUST be 1 555 o The session_id attribute MUST be a random version 4 UUID unique to 556 this session 557 o The session_id attribute MUST match the expected session_id in the 558 reference in the notification file. 559 o The serial attribute MUST match the expected serial in the 560 reference in the notification file. 561 o The hexadecimal encoding of the SHA-256 hash of this snapshot file 562 MUST match the hash attribute in the reference in the notification 563 file. 564 o A publish element MUST include a hash attribute, if the object is 565 intended to replace another object in the RPKI, and its value MUST 566 be the hexadecimal encoding of the SHA-256 hash of the replaced 567 object. If the published object does not replace another object 568 the hash attribute MUST NOT be included. Note that this is an 569 extension to the publication protocol that is not, yet, reflected 570 in [I-D.ietf-sidr-publication]. 571 o Similarly a withdraw element MUST contain a hash attribute with 572 the hexadecimal encoding of the SHA-256 hash of the withdrawn 573 object. Including the hashes in this manner allows relying 574 parties to identify specific objects by their hash rather than the 575 URI where they are found. 577 3.5. SIA for CA certificates 579 Certificate Authorities that use this delta protocol MUST have an 580 instance of an SIA AccessDescription in addition to the ones defined 581 in [RFC6487], 583 AccessDescription ::= SEQUENCE { 584 accessMethod OBJECT IDENTIFIER, 585 accessLocation GeneralName } 587 This extension MUST use an accessMethod of id-ad-rpkiNotify, see: 588 [IANA-AD-NUMBERS], 590 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 591 id-ad-rpkiNotify OBJECT IDENTIFIER ::= { id-ad 13 } 593 The accessLocation MUST be a URI [RFC3986], using the 'HTTP' or 594 'HTTPS' protocol, that will point to the update notification file for 595 the publication server that publishes the products of this CA 596 certificate. 598 Relying Parties that do not support this delta protocol MUST MUST NOT 599 reject a CA certificate merely because it has an SIA extension 600 containing this new kind of AccessDescription. 602 4. Relying Party Use 604 4.1. Full Synchronisation 606 When a Relying Party first encounters a notification file URI as an 607 SIA of a certificate that it has validated it SHOULD retrieve the 608 notification file and download the latest snapshot to get in sync 609 with the current version of the publication server. 611 The RP SHOULD reject the snapshot file and raise an operator alert, 612 if its hash does not match the hash listed in the notification file. 613 However, if the RP does not have any prior state it may choose to 614 process this snapshot file anyway. It should be noted that the RPKI 615 objects are protected by object security, so problems or attacks on 616 the publication server or transport can result in witholding or 617 replaying old objects, but it cannot force the RP to accept invalid 618 objects. Using the remaining or old objects for validation is 619 probably better than rejecting everything, since the latter could be 620 used as a denial of service vector on relying parties. 622 4.2. Processing Deltas 624 It is RECOMMENDED that the RP notes the URI, session_id and serial 625 number when it first learns about a notification file. The RP MAY 626 then poll the file to discover updates. How frequently the RP does 627 this is largely up to local policy. The polling frequency determines 628 in part what propogation time that a RP is willing to accept between 629 the moment that a change is published in the RPKI, and the moment 630 that those changes are processed and validated. As discussed in 631 Section 3.2.2 there does not seem to be a need to have a propogation 632 time that is below five minutes. Since the publication server 633 infrastructure MAY cache the notification file for up to five minutes 634 a slightly more frequent polling strategy may be useful, however the 635 RP SHOULD NOT poll more frequently than once per minute. More 636 frequent polling would only result in marginal gains in propagation, 637 while causing unnecessary load on the caching infrastructure. 639 If the RP finds that the session_id has changed, or if it cannot find 640 a contiguous chain of links to delta files from its current serial to 641 publication server's current serial, then it MUST perform a full 642 synchronisation instead of continuing to process deltas. 644 If the RP finds a contiguous chain of links to delta files from its 645 current serial to the publication server's current serial, and the 646 session_id has not changed, it should download all missing delta 647 files. If any delta file cannot be downloaded, or its hash does not 648 match the hash listed on the notification file, or if no such chain 649 of deltas is availabe, or the session_id has changed, then the RP 650 MUST perform a full synchronisation instead. 652 New objects found in delta files can be added to the RPs local copy 653 of the repository. However, it is RECOMMENDED that the RP treats 654 object updates and withdraws with some skepticism. A compromised 655 publication server may not have access to the certification 656 authorities' keys, but it can pretend valid objects have been 657 withdrawn. Therefore it may be preferred to use a strategy where 658 local copies of objects are only discarded when the RP is sure that 659 they are no longer relevant, e.g. the CA has explicitly revoked 660 them, removed the objects from a valid manifest that it issued, or 661 they have expired. 663 5. XML Schema 665 The following is a RELAX NG compact form schema describing version 1 666 of this protocol. 668 # 669 # RelaxNG schema for RPKI Repository Delta Protocol (RRDP). 670 # 672 default namespace = "HTTP://www.ripe.net/rpki/rrdp" 674 version = xsd:positiveInteger { maxInclusive="1" } 675 serial = xsd:nonNegativeInteger 676 uri = xsd:anyURI 677 uuid = xsd:string { pattern = "[\-0-9a-fA-F]+" } 678 hash = xsd:string { pattern = "[0-9a-fA-F]+" } 679 base64 = xsd:base64Binary 681 # Notification file: lists current snapshots and deltas 683 start |= element notification { 684 attribute version { version }, 685 attribute session_id { uuid }, 686 attribute serial { serial }, 687 element snapshot { 688 attribute uri { uri }, 689 attribute hash { hash } 690 }, 691 element delta { 692 attribute serial { serial }, 693 attribute uri { uri }, 694 attribute hash { hash } 695 }* 696 } 698 # Snapshot segment: think DNS AXFR. 700 start |= element snapshot { 701 attribute version { version }, 702 attribute session_id { uuid }, 703 attribute serial { serial }, 704 element publish { 705 attribute uri { uri }, 706 base64 707 }* 708 } 710 # Delta segment: think DNS IXFR. 712 start |= element delta { 713 attribute version { version }, 714 attribute session_id { uuid }, 715 attribute serial { serial }, 716 delta_element+ 717 } 719 delta_element |= element publish { 720 attribute uri { uri }, 721 attribute hash { hash }?, 722 base64 723 } 725 delta_element |= element withdraw { 726 attribute uri { uri }, 727 attribute hash { hash } 728 } 730 # Local Variables: 731 # indent-tabs-mode: nil 732 # comment-start: "# " 733 # comment-start-skip: "#[ \t]*" 734 # End: 736 6. Security Considerations 738 TBD 740 7. IANA Considerations 742 This document has no actions for IANA. 744 8. Acknowledgements 746 TBD 748 9. References 750 [I-D.ietf-sidr-publication] 751 Weiler, S., Sonalker, A. and R. Austein, "A Publication 752 Protocol for the Resource Public Key Infrastructure 753 (RPKI)", Internet-Draft draft-ietf-sidr-publication-05, 754 February 2014. 756 [IANA-AD-NUMBERS] 757 "SMI Security for PKIX Access Descriptor", , . 761 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 762 Requirement Levels", BCP 14, RFC 2119, March 1997. 764 [RFC3986] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 765 Resource Identifier (URI): Generic Syntax", STD 66, RFC 766 3986, January 2005. 768 [RFC6481] Huston, G., Loomans, R. and G. Michaelson, "A Profile for 769 Resource Certificate Repository Structure", RFC 6481, 770 February 2012. 772 [RFC6486] Austein, R., Huston, G., Kent, S. and M. Lepinski, 773 "Manifests for the Resource Public Key Infrastructure 774 (RPKI)", RFC 6486, February 2012. 776 [RFC6487] Huston, G., Michaelson, G. and R. Loomans, "A Profile for 777 X.509 PKIX Resource Certificates", RFC 6487, February 778 2012. 780 [RFC6488] Lepinski, M., Chi, A. and S. Kent, "Signed Object Template 781 for the Resource Public Key Infrastructure (RPKI)", RFC 782 6488, February 2012. 784 Authors' Addresses 786 Tim Bruijnzeels 787 RIPE NCC 789 Email: tim@ripe.net 791 Oleg Muravskiy 792 RIPE NCC 794 Email: oleg@ripe.net 796 Bryan Weber 797 Cobenian 799 Email: bryan@cobenian.com 801 Rob Austein 802 Dragon Research Labs 804 Email: sra@hactrn.net 806 David Mandelberg 807 BBN Technologies 809 Email: david@mandelberg.org