idnits 2.17.1 draft-ietf-sidr-delta-protocol-05.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 abstract seems to contain references ([RFC6480], [RFC6481], [RFC7730], [RFC2818]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC7730, but the abstract doesn't seem to directly say this. It does mention RFC7730 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC6480, updated by this document, for RFC5378 checks: 2007-02-28) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 16, 2017) is 2657 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) == Missing Reference: 'RSYNC' is mentioned on line 803, but not defined == Missing Reference: 'RFC3986' is mentioned on line 842, but not defined == Unused Reference: 'RFC7232' is defined on line 1064, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-sidr-publication-10 -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-AD-NUMBERS' ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Downref: Normative reference to an Informational RFC: RFC 5781 ** Downref: Normative reference to an Informational RFC: RFC 6480 ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7232 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) ** Obsolete normative reference: RFC 7730 (Obsoleted by RFC 8630) == Outdated reference: A later version (-03) exists of draft-ietf-sidrops-rpki-tree-validation-00 -- Obsolete informational reference (is this intentional?): RFC 6486 (Obsoleted by RFC 9286) Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 6 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 Updates: 6480,6481,7730 (if approved) RIPE NCC 5 Intended status: Standards Track B. Weber 6 Expires: July 20, 2017 Cobenian 7 R. Austein 8 Dragon Research Labs 9 January 16, 2017 11 RPKI Repository Delta Protocol 12 draft-ietf-sidr-delta-protocol-05 14 Abstract 16 In the Resource Public Key Infrastructure (RPKI), certificate 17 authorities publish certificates, including end entity certificates, 18 Certificate Revocation Lists (CRL), and RPKI signed objects to 19 repositories. Relying Parties (RP) retrieve the published 20 information from those repositories. This document specifies a 21 protocol which provides relying parties with a mechanism to query a 22 repository for incremental updates using the HTTP Over TLS (HTTPS) 23 [RFC2818] protocol, thus enabling the RP to keep its state in sync 24 with the repository using a secure transport channel. This document 25 updates [RFC6480], [RFC6481], and [RFC7730]. 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 July 20, 2017. 44 Copyright Notice 46 Copyright (c) 2017 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 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 62 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. RPKI Repository Delta Protocol Implementation . . . . . . . . 4 64 3.1. Informal Overview . . . . . . . . . . . . . . . . . . . . 4 65 3.2. Certificate Authority Use . . . . . . . . . . . . . . . . 5 66 3.3. Repository Server Use . . . . . . . . . . . . . . . . . . 5 67 3.3.1. Initialisation . . . . . . . . . . . . . . . . . . . 5 68 3.3.2. Publishing Updates . . . . . . . . . . . . . . . . . 6 69 3.4. Relying Party Use . . . . . . . . . . . . . . . . . . . . 7 70 3.4.1. Processing the Update Notification File . . . . . . . 7 71 3.4.2. Processing Delta Files . . . . . . . . . . . . . . . 8 72 3.4.3. Processing a Snapshot File . . . . . . . . . . . . . 8 73 3.4.4. Polling the Update Notification File . . . . . . . . 9 74 3.4.5. Considerations Regarding Operational Failures in RRDP 9 75 3.5. File Definitions . . . . . . . . . . . . . . . . . . . . 10 76 3.5.1. Update Notification File . . . . . . . . . . . . . . 10 77 3.5.2. Snapshot File . . . . . . . . . . . . . . . . . . . . 12 78 3.5.3. Delta File . . . . . . . . . . . . . . . . . . . . . 13 79 3.5.4. XML Schema . . . . . . . . . . . . . . . . . . . . . 15 80 4. Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 4.1. Updates to RFC6480 . . . . . . . . . . . . . . . . . . . 16 82 4.1.1. Update in Section 4.3, Access Protocols . . . . . . . 16 83 4.1.2. Update in Section 11.1, Normative References . . . . 17 84 4.1.3. Update in Section 11.2, Informative References . . . 17 85 4.2. Updates to RFC6481 . . . . . . . . . . . . . . . . . . . 17 86 4.2.1. Update in Section 3, Resource Certificate Publication 87 Repository Considerations . . . . . . . . . . . . . . 17 88 4.2.2. Update in Section 9.1, Normative References . . . . . 18 89 4.2.3. Update in Section 9.2, Informative References . . . . 18 90 4.3. Updates to RFC7730 . . . . . . . . . . . . . . . . . . . 18 91 4.3.1. Update in Section 2.1, Trust Anchor Locator Format . 18 92 4.3.2. Update in Section 2.2, TAL and Trust Anchor 93 Certificate Considerations . . . . . . . . . . . . . 18 94 4.3.3. Update in Section 5.1, Normative References . . . . . 19 95 5. Operational Considerations . . . . . . . . . . . . . . . . . 19 96 5.1. Compatibility with previous standards . . . . . . . . . . 19 97 5.2. Distribution considerations . . . . . . . . . . . . . . . 19 98 5.3. HTTPS considerations . . . . . . . . . . . . . . . . . . 20 99 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 100 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 101 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 102 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 103 9.1. Normative References . . . . . . . . . . . . . . . . . . 22 104 9.2. Informative References . . . . . . . . . . . . . . . . . 23 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 107 1. Requirements notation 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 2. Introduction 115 In the Resource Public Key Infrastructure (RPKI), Certificate 116 Authorities (CAs) publish certificates [RFC6487], RPKI signed objects 117 [RFC6488], manifests [RFC6486], and CRLs to repositories. CAs may 118 have an embedded mechanism to publish to these repositories, or they 119 may use a separate repository server and publication protocol. RPKI 120 repositories are currently accessible using the [rsync] protocol, 121 allowing Relying Parties (RPs) to synchronise a local copy of the 122 RPKI repository used for validation with the remote repositories 123 [RFC6481]. 125 This document specifies an alternative repository access protocol 126 based on notification, snapshot and delta files that a RP can 127 retrieve over the HTTPS protocol. This allows RPs to perform either 128 a full (re-)synchronisation of their local copy of the repository 129 using snapshot files, or use delta files to keep their local 130 repository updated after initial synchronisation. We call this the 131 RPKI Repository Delta Protocol, or RRDP in short. 133 This protocol is designed to be consistent (in terms of data 134 structures) with the publication protocol [I-D.ietf-sidr-publication] 135 and treats publication events of one or more repository objects as 136 discrete events that can be communicated to relying parties. This 137 approach helps to minimize the amount of data that traverses the 138 network and thus helps minimize the amount of time until repository 139 convergence occurs. This protocol also provides a standards based 140 way to obtain consistent, point in time views of a single repository, 141 eliminating a number of consistency related issues. Finally, this 142 approach allows these discrete events to be communicated as immutable 143 files, so that caching infrastructure can be used to reduce the load 144 on a repository server when a large number of relying parties are 145 querying it. 147 3. RPKI Repository Delta Protocol Implementation 149 3.1. Informal Overview 151 Certification Authorities (CA) in the RPKI use a repository server to 152 publish their RPKI products, such as manifests, CRLs, signed 153 certificates and RPKI signed objects. This repository server may be 154 remote, or embedded in the CA engine itself. Certificates in the 155 RPKI that use a repository server that supports this delta protocol 156 include a special Subject Information Access (SIA) pointer referring 157 to a notification file. 159 The notification file includes a globally unique session_id in the 160 form of a version 4 UUID ([RFC4122]), and serial number that can be 161 used by the Relying Party (RP) to determine if it and the repository 162 are synchronised. Furthermore it includes a link to the most recent 163 complete snapshot of current objects that are published by the 164 repository server, and a list of links to delta files, for each 165 revision starting at a point determined by the repository server, up 166 to the current revision of the repository. 168 A RP that learns about a notification file location for the first 169 time can download it, and then proceed to download the latest 170 snapshot file, and thus create a local copy of the repository that is 171 in sync with the repository server. The RP records the location of 172 this notification file, the session_id and current serial number. 174 RPs are encouraged to re-fetch this notification file at regular 175 intervals, but not more often than once per minute. After re- 176 fetching the notification file, the RP may find that there are one or 177 more delta files available that allow it to synchronise its local 178 repository with the current state of the repository server. If no 179 contiguous chain of deltas from RP's serial to the latest repository 180 serial is available, or if the session_id has changed, the RP 181 performs a full resynchronisation instead. 183 As soon as the RP fetches new content in this way it could start a 184 validation process. An example of a reason why a RP may not do this 185 immediately is because it has learned of more than one notification 186 location and it prefers to complete all its updates before 187 validating. 189 The repository server could use caching infrastructure to reduce its 190 load, particularly because snapshots and deltas for any given 191 session_id and serial number contain an immutable record of the state 192 of the repository server at a certain point in time. For this reason 193 these files can be cached indefinitely. Notification files are 194 polled by RPs to discover if updates exist, and for this reason 195 notification files may not be cached for longer than one minute. 197 3.2. Certificate Authority Use 199 Certificate Authorities that use this delta protocol MUST include an 200 instance of an SIA AccessDescription extension in resource 201 certificates they produce, in addition to the ones defined in 202 [RFC6487], 204 AccessDescription ::= SEQUENCE { 205 accessMethod OBJECT IDENTIFIER, 206 accessLocation GeneralName } 208 This extension MUST use an accessMethod of id-ad-rpkiNotify, see: 209 Section 7, 211 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 212 id-ad-rpkiNotify OBJECT IDENTIFIER ::= { id-ad 13 } 214 The accessLocation MUST be an HTTPS URI as defined in [RFC2818], that 215 will point to the update notification file for the repository server 216 that publishes the products of this CA certificate. 218 3.3. Repository Server Use 220 3.3.1. Initialisation 222 When the repository server initialises it performs the following 223 actions: 225 o The server MUST generate a new random version 4 UUID to be used as 226 the session_id 228 o The server MUST then generate a snapshot file for serial number 229 ONE for this new session that includes all currently known 230 published objects that the repository server is responsible for. 231 Note that this snapshot file may contain zero publish elements at 232 this point if no objects have been submitted for publication yet. 234 o This snapshot file MUST be made available at a URL that is unique 235 to this session_id and serial number, so that it can be cached 236 indefinitely. The format and caching concerns for snapshot files 237 are explained in more detail in Section 3.5.2. 239 o After the snapshot file has been published the repository server 240 MUST publish a new notification file that contains the new 241 session_id, has serial number ONE, has one reference to the 242 snapshot file that was just published, and that contains no delta 243 references. The format and caching concerns for update 244 notification files are explained in more detail in Section 3.5.1. 246 3.3.2. Publishing Updates 248 Whenever the repository server receives updates from a CA it MUST 249 generate new snapshot and delta files within one minute. If a 250 publication server services a large number of CAs it MAY choose to 251 combine updates from multiple CAs. If a publication server combines 252 updates in this way, it MUST ensure that publication never postponed 253 for longer than one minute for any of the CAs involved. 255 Updates are processed as follows: 257 o The new repository serial number MUST be one greater than the 258 current repository serial number. 260 o A new delta file MUST be generated for this new serial. This 261 delta file MUST include all new, replaced and withdrawn objects 262 for multiple CAs if applicable, as a single change set. 264 o This delta file MUST be made available at a URL that is unique to 265 the current session_id and serial number, so that it can be cached 266 indefinitely. 268 o The format and caching concerns for delta files are explained in 269 more detail in Section 3.5.3. 271 o The repository server MUST also generate a new snapshot file for 272 this new serial. This file MUST contain all "publish" elements 273 for all current objects. 275 o The snapshot file MUST be made available at a URL that is unique 276 to this session and new serial, so that it can be cached 277 indefinitely. 279 o The format and caching concerns for snapshot files are explained 280 in more detail in Section 3.5.2. 282 o Any older delta files that, when combined with all more recent 283 delta files, will result in total size of deltas exceeding the 284 size of the snapshot, MUST be excluded to avoid that RPs download 285 more data than necessary. 287 o A new notification file MUST now be created by the repository 288 server. This new notification file MUST include a reference to 289 the new snapshot file, and all delta files selected in the 290 previous steps. 292 o The format and caching concerns for update notification files are 293 explained in more detail in Section 3.5.1. 295 If the repository server is not capable of performing the above for 296 some reason, then it MUST perform a full re-initialisation, as 297 explained above in Section 3.3.1. 299 3.4. Relying Party Use 301 3.4.1. Processing the Update Notification File 303 When a Relying Party (RP) performs RPKI validation and learns about a 304 valid certificate with an SIA entry for the RRDP protocol, it SHOULD 305 use this protocol as follows. 307 The RP MUST download the update notification file, unless an update 308 notification file was already downloaded and processed from the same 309 location in this validation run, or because a polling strategy was 310 used (see Section 3.4.4). 312 It is RECOMMENDED that RP uses a "User-Agent" header explained in 313 section 5.5.3. of [RFC7231] to identify the name and version of the 314 RP software used. It is useful to track capabilities of Relying 315 Parties in the event of changes to the RPKI standards. 317 When the RP downloads an update notification file it MUST verify the 318 file format and validation steps described in section 319 Section 3.5.1.3. If this verification fails, the file MUST be 320 rejected and RRDP cannot be used. See Section 3.4.5 for 321 considerations. 323 The RP MUST verify whether the session_id in this update notification 324 file matches the last known session_id for this update notification 325 file location. If the session_id matches the last known session_id, 326 then an RP MAY download and process missing delta files as described 327 in section Section 3.4.2, provided that all delta files for serial 328 numbers between the last processed serial number and the current 329 serial number in the notification file can be processed this way. 331 If the session_id was not previously known, or if delta files could 332 not be used, then the RP MUST update its last known session_id to 333 this session_id and download and process snapshot file on the update 334 notification file as described in section Section 3.4.3. 336 3.4.2. Processing Delta Files 338 If an update notification file contains a contiguous chain of links 339 to delta files from the last processed serial number to the current 340 serial number, then RPs MUST attempt to download and process all 341 delta files in order of serial number as follows. 343 When the RP downloads a delta file it MUST verify the file format and 344 perform validation steps described in Section 3.5.3.3. If this 345 verification fails, the file MUST be rejected. 347 Furthermore the RP MUST verify that the hash of the contents of this 348 file matches the hash on the update notification file that referenced 349 it. In case of a mismatch of this hash, the file MUST be rejected. 351 If an RP retrieved a delta file that is valid according to the above 352 criteria, it performs the following actions: 354 The RP MUST verify that the session_id matches the session_id of 355 the notification file. If the session_id values do not match the 356 file MUST be rejected. 358 The RP MUST verify that the serial number of this delta file is 359 exactly one greater than the last processed serial number for this 360 session_id, and if not this file MUST be rejected. 362 The RP SHOULD add all publish elements to a local storage and 363 update its last processed serial number to the serial number of 364 this snapshot file. 366 The RP SHOULD NOT remove objects from its local storage solely 367 because it encounters a "withdraw" element, because this would 368 enable a publication server to withdraw any object without the 369 signing Certificate Authority consent. The RP could use 370 additional strategies to determine if an object is still relevant 371 for validation before removing it from its local storage. In 372 particular objects should not be removed if they are included in a 373 current validated manifest. 375 If any delta file is rejected RPs MUST process the current Snapshot 376 File instead, as described in Section 3.4.3. 378 3.4.3. Processing a Snapshot File 380 Snapshot Files MUST only be used if Delta Files are unavailable, or 381 were rejected. As is ensured, if the process described in 382 Section 3.4.1 is followed. 384 When the RP downloads a snapshot file it MUST verify the file format 385 and validation steps described in Section 3.5.2.3. If this 386 verification fails, the file MUST be rejected. 388 Furthermore the RP MUST verify that the hash of the contents of this 389 file matches the hash on the update notification file that referenced 390 it. In case of a mismatch of this hash, the file MUST be rejected. 392 If an RP retrieved a snapshot file that is valid according to the 393 above criteria, it performs the following actions: 395 The RP MUST verify that the session_id matches the session_id of 396 the notification file. If the session_id values do not match the 397 file MUST be rejected. 399 The RP MUST verify that the serial number of this snapshot file is 400 greater than the last processed serial number for this session_id. 401 If this fails the file MUST be rejected. 403 The RP SHOULD then add all publish elements to a local storage and 404 update its last processed serial number to the serial number of 405 this snapshot file. 407 If a Snapshot File is rejected that means that RRDP cannot be used. 408 See Section 3.4.5 for considerations. 410 3.4.4. Polling the Update Notification File 412 Once a Relying Party has learned about the location, session_id and 413 last processed serial number of repository that uses the RRDP 414 protocol, the RP MAY start polling the repository server for updates. 415 However the RP MUST NOT poll for updates more often than once every 1 416 minute, and in order to reduce data usage RPs MUST use the "If- 417 Modified-Since" header explained in section 3.3 of [RFC7232]in 418 requests. 420 If an RP finds that updates are available it SHOULD download and 421 process the file as described in Section 3.4.1, and initiate a new 422 RPKI object validation process. However, a detailed description of 423 the RPKI object validation process itself is out of scope of this 424 document. 426 3.4.5. Considerations Regarding Operational Failures in RRDP 428 If an RP experiences any issues with retrieving or processing any of 429 the files used in this protocol, it will be unable to retrieve new 430 RPKI data from the affected publication server. 432 Relying Parties could attempt to use alternative repository access 433 mechanisms, if they are available, according to the accessMethod 434 element value(s) specified in the SIA of the associated certificate 435 (see Section 4.8.8 of [RFC6487]). 437 Furthermore Relying Parties may wish to employ re-try strategies in 438 case of network issues. Relying Parties are also advised to keep old 439 objects in their local cache so that validation can be done using old 440 objects. 442 It is also recommendable that re-validation and retrieval is 443 performed pro-actively before manifests or CRLs go stale, or 444 certificates expire, to ensure that problems on the side of the RP 445 can be identified and resolved before they cause major concerns. 447 3.5. File Definitions 449 3.5.1. Update Notification File 451 3.5.1.1. Purpose 453 The update notification file is used by RPs to discover whether any 454 changes exist between the state of the repository and the RP's cache. 455 It describes the location of the files containing the snapshot and 456 incremental deltas which can be used by the RP to synchronise with 457 the repository. 459 3.5.1.2. Cache Concerns 461 A repository server MAY use caching infrastructure to cache the 462 notification file and reduce the load of HTTPS requests. However, 463 since this file is used by RPs to determine whether any updates are 464 available the repository server SHOULD ensure that this file is not 465 cached for longer than 1 minute. An exception to this rule is that 466 it is better to serve a stale notification file, than no notification 467 file. 469 How this is achieved exactly depends on the caching infrastructure 470 used. In general a repository server may find certain HTTP headers 471 to be useful, such as: Cache-Control: max-age=60. Another approach 472 can be to have the repository server push out new versions of the 473 notification file to the caching infrastructure when appropriate. 475 Relying Parties SHOULD NOT cache the notification file for longer 476 than 1 minute, regardless of the headers set by the repository server 477 or CDN. 479 3.5.1.3. File Format and Validation 481 Example notification file: 483 487 488 489 490 492 Note: URIs and hash values in this example are shortened because of 493 formatting. 495 The following validation rules MUST be observed when creating or 496 parsing notification files: 498 o A RP MUST reject any update notification file that is not well- 499 formed, or which does not conform to the RELAX NG schema outlined 500 in Section 3.5.4 of this document. 502 o The XML namespace MUST be http://www.ripe.net/rpki/rrdp 504 o The encoding MUST be US-ASCII 506 o The version attribute in the notification root element MUST be 1 508 o The session_id attribute MUST be a random version 4 UUID 509 ([RFC4122]), unique to this session 511 o The serial attribute MUST be an unbounded, unsigned positive 512 integer in decimal format indicating the current version of the 513 repository. 515 o The notification file MUST contain exactly one 'snapshot' element 516 for the current repository version. 518 o If delta elements are included they MUST form a contiguous 519 sequence of serial numbers starting at a revision determined by 520 the repository server, up to the serial number mentioned in the 521 notification element. Note that the elements may not be ordered. 523 o The hash attribute in snapshot and delta elements MUST be the 524 hexadecimal encoding of the SHA-256 hash of the referenced file. 525 The RP MUST verify this hash when the file is retrieved and reject 526 the file if the hash does not match. 528 3.5.2. Snapshot File 530 3.5.2.1. Purpose 532 A snapshot is intended to reflect the complete and current contents 533 of the repository for a specific session and version. Therefore it 534 MUST contain all objects from the repository current as of the time 535 of the publication. 537 3.5.2.2. Cache Concerns 539 A snapshot reflects the content of the repository at a specific point 540 in time, and for that reason can be considered immutable data. 541 Snapshot files MUST be published at a URL that is unique to the 542 specific session and serial. 544 Because these files never change, they MAY be cached indefinitely. 545 However, in order to prevent that these files use a lot of space in 546 caching infrastructure it is RECOMMENDED that a limited interval is 547 used in the order of hours or days. 549 To avoid race conditions where an RP downloads a notification file 550 moments before it's updated, Repository Servers SHOULD retain old 551 snapshot files for at least 5 minutes after a new notification file 552 is published. 554 3.5.2.3. File Format and Validation 556 Example snapshot file: 558 562 563 ZXhhbXBsZTE= 564 565 566 ZXhhbXBsZTI= 567 568 569 ZXhhbXBsZTM= 570 571 573 The following rules MUST be observed when creating or parsing 574 snapshot files: 576 o A RP MUST reject any snapshot file that is not well-formed, or 577 which does not conform to the RELAX NG schema outlined in 578 Section 3.5.4 of this document. 580 o The XML namespace MUST be http://www.ripe.net/rpki/rrdp. 582 o The encoding MUST be US-ASCII. 584 o The version attribute in the notification root element MUST be 1 586 o The session_id attribute MUST match the expected session_id in the 587 reference in the notification file. 589 o The serial attribute MUST match the expected serial in the 590 reference in the notification file. 592 o Note that the publish element is similar to the publish element 593 defined in the publication protocol [I-D.ietf-sidr-publication]. 594 However, the "tag" attribute is not used here because it is not 595 relevant to relying parties. The "hash" attribute is not used 596 here because this file represents a complete current state of the 597 repository, and therefore it is not relevant to know which 598 existing RPKI object (if any) is updated. 600 3.5.3. Delta File 602 3.5.3.1. Purpose 604 An incremental delta file contains all changes for exactly one serial 605 increment of the repository server. In other words a single delta 606 will typically include all the new objects, updated objects and 607 withdrawn objects that a Certification Authority sent to the 608 repository server. In its simplest form the update could concern 609 only a single object, but it is RECOMMENDED that CAs send all changes 610 for one of their key pairs (updated objects as well as a new manifest 611 and CRL) as one atomic update message. 613 3.5.3.2. Cache Concerns 615 Deltas reflect the difference between two consecutive versions of a 616 repository for a given session. For that reason deltas can be 617 considered immutable data. Delta files MUST be published at a URL 618 that is unique to the specific session and serial. 620 Because these files never change, they MAY be cached indefinitely. 621 However, in order to prevent these files from using a lot of space in 622 caching infrastructure it is RECOMMENDED that a limited interval is 623 used in the order of hours or days. 625 To avoid race conditions where an RP downloads a notification file 626 moments before it's updated, Repository Servers SHOULD retain old 627 delta files for at least 5 minutes after they are no longer included 628 in the latest notification file. 630 3.5.3.3. File Format and Validation 632 Example delta file: 634 638 640 ZXhhbXBsZTQ= 641 642 644 ZXhhbXBsZTU= 645 646 648 650 Note that a formal RELAX NG specification of this file format is 651 included later in this document. A RP MUST NOT process any delta 652 file that is incomplete or not well-formed. 654 The following validation rules MUST be observed when creating or 655 parsing delta files: 657 o A RP MUST reject any delta file that is not well-formed, or which 658 does not conform to the RELAX NG schema outlined in Section 3.5.4 659 of this document. 661 o The XML namespace MUST be http://www.ripe.net/rpki/rrdp. 663 o The encoding MUST be US-ASCII. 665 o The version attribute in the delta root element MUST be 1 667 o The session_id attribute MUST be a random version 4 UUID unique to 668 this session 670 o The session_id attribute MUST match the expected session_id in the 671 reference in the notification file. 673 o The serial attribute MUST match the expected serial in the 674 reference in the notification file. 676 o Note that the publish element is similar to the publish element 677 defined in the publication protocol [I-D.ietf-sidr-publication]. 678 However, the "tag" attribute is not used here because it is not 679 relevant to relying parties. 681 3.5.4. XML Schema 683 The following is a RELAX NG compact form schema describing version 1 684 of this protocol. 686 # 687 # RelaxNG schema for RPKI Repository Delta Protocol (RRDP). 688 # 690 default namespace = "http://www.ripe.net/rpki/rrdp" 692 version = xsd:positiveInteger { maxInclusive="1" } 693 serial = xsd:nonNegativeInteger 694 uri = xsd:anyURI 695 uuid = xsd:string { pattern = "[\-0-9a-fA-F]+" } 696 hash = xsd:string { pattern = "[0-9a-fA-F]+" } 697 base64 = xsd:base64Binary 699 # Notification file: lists current snapshots and deltas 701 start |= element notification { 702 attribute version { version }, 703 attribute session_id { uuid }, 704 attribute serial { serial }, 705 element snapshot { 706 attribute uri { uri }, 707 attribute hash { hash } 708 }, 709 element delta { 710 attribute serial { serial }, 711 attribute uri { uri }, 712 attribute hash { hash } 713 }* 714 } 716 # Snapshot segment: think DNS AXFR. 718 start |= element snapshot { 719 attribute version { version }, 720 attribute session_id { uuid }, 721 attribute serial { serial }, 722 element publish { 723 attribute uri { uri }, 724 base64 725 }* 726 } 728 # Delta segment: think DNS IXFR. 730 start |= element delta { 731 attribute version { version }, 732 attribute session_id { uuid }, 733 attribute serial { serial }, 734 delta_element+ 735 } 737 delta_element |= element publish { 738 attribute uri { uri }, 739 attribute hash { hash }?, 740 base64 741 } 743 delta_element |= element withdraw { 744 attribute uri { uri }, 745 attribute hash { hash } 746 } 748 # Local Variables: 749 # indent-tabs-mode: nil 750 # comment-start: "# " 751 # comment-start-skip: "#[ \t]*" 752 # End: 754 4. Updates 756 This section provides updates to several paragraphs in [RFC6480], 757 [RFC6481], and [RFC7730]. For clarity, the original text and the 758 replacement text are shown. 760 4.1. Updates to RFC6480 762 4.1.1. Update in Section 4.3, Access Protocols 764 OLD: 766 To ensure all relying parties are able to acquire all RPKI signed 767 objects, all publication points MUST be accessible via rsync (see 768 [RFC5781] and [RSYNC]), although other download protocols MAY also 769 be supported. A repository publication point may provide 770 update/change/delete functionality via (set of) access protocols 771 that it desires, provided that the supported protocols are clearly 772 communicated to all certification authorities publishing data at a 773 given publication point. 775 NEW: 777 To ensure all relying parties are able to acquire all RPKI signed 778 objects, all publication points MUST be accessible using retrieval 779 mechanism(s) consistent with the accessMethod element value(s). 780 Multiple retrieval mechanisms MAY be supported at the repository 781 operator's discretion. A repository publication point may provide 782 update/change/delete functionality via (set of) access protocols 783 that it desires, provided that the supported protocols are clearly 784 communicated to all certification authorities publishing data at a 785 given publication point. 787 4.1.2. Update in Section 11.1, Normative References 789 Remove the reference to RFC5781, "The rsync URI Scheme". 791 4.1.3. Update in Section 11.2, Informative References 793 Remove the reference to rsync, "rsync web pages". 795 4.2. Updates to RFC6481 797 4.2.1. Update in Section 3, Resource Certificate Publication Repository 798 Considerations 800 OLD: 802 The publication repository MUST be available using rsync [RFC5781] 803 [RSYNC]. Support of additional retrieval mechanisms is the choice 804 of the repository operator. The supported retrieval mechanisms 805 MUST be consistent with the accessMethod element value(s) 806 specified in the SIA of the associated CA or EE certificate. 808 NEW: 810 The publication repository MUST be available using retrieval 811 mechanism(s) consistent with the accessMethod element value(s) 812 specified in the SIA of the associated CA or EE certificate. 813 Support of multiple retrieval mechanisms is the choice of the 814 repository operator. 816 4.2.2. Update in Section 9.1, Normative References 818 Remove the reference to RFC5781, "The rsync URI Scheme". 820 4.2.3. Update in Section 9.2, Informative References 822 Remove the reference to rsync, "rsync web pages". 824 4.3. Updates to RFC7730 826 4.3.1. Update in Section 2.1, Trust Anchor Locator Format 828 OLD: 830 where the URI section is comprised of one of more of the ordered 831 sequence of: 833 1.1) an rsync URI [RFC5781], 835 1.2) a or line break. 837 NEW: 839 where the URI section is comprised of one of more of the ordered 840 sequence of: 842 1.1) a URI [RFC3986], 844 1.2) a or line break. 846 4.3.2. Update in Section 2.2, TAL and Trust Anchor Certificate 847 Considerations 849 OLD: 851 Each rsync URI in the TAL MUST reference a single object. It MUST 852 NOT reference a directory or any other form of collection of 853 objects. 855 ... 857 Where the TAL contains two or more rsync URIs, then the same self- 858 signed CA certificate MUST be found at each referenced location. 860 NEW: 862 Each URI in the TAL MUST reference a single object. It MUST NOT 863 reference a directory or any other form of collection of objects. 865 ... 867 Where the TAL contains two or more URIs, then the same self-signed 868 CA certificate MUST be found at each referenced location. 870 4.3.3. Update in Section 5.1, Normative References 872 Remove the reference to RFC5781, "The rsync URI Scheme". 874 Add a reference to RFC3986, "Uniform Resource Identifier (URI): 875 Generic Syntax". 877 5. Operational Considerations 879 5.1. Compatibility with previous standards 881 This protocol has been designed to replace rsync as a distribution 882 mechanism of an RPKI repository. However, it is also designed to co- 883 exist with existing implementations based on rsync, to enable smooth 884 transition from one distribution mechanism to another. 886 For every repository object listed in the snapshot and delta files 887 both the hash of the object's content and the rsync URI [RFC5781] of 888 its location in the repository are listed. This makes it possible to 889 distribute the same RPKI repository, represented by a set of files on 890 a filesystem, using both rsync and RRDP. It also enables Relying 891 Parties tools to query, combine, and consequently validate objects 892 from repositories of different types. (For an example of such 893 implementation see [I-D.ietf-sidrops-rpki-tree-validation].) 895 5.2. Distribution considerations 897 One of the design goals of RRDP was to minimise load on a repository 898 server while serving clients. To achieve this, neither the content, 899 nor the URLs of the snapshot and delta files are modified after they 900 have been published in the notification file. This allows their 901 effective distribution, either by a single HTTP server, or using a 902 Content Distribution Network (CDN). 904 The RECOMMENDED way for RPs to keep up with the repository updates is 905 to poll the Update Notification File for changes. The content of 906 that file is updated with every new serial version of a repository 907 (while its URL remains stable). To effectively implement 908 distribution of the notification file, an "If-Modified-Since" HTTP 909 request header is required to be present in all requests for 910 notification file (see Section 3.4.4.) Therefore it is RECOMMENDED 911 that RP tools implement a mechanism to keep track of a previous 912 successful fetch of a notification file. 914 Implementations of RRDP should also take care of not producing new 915 versions of the repository (and subsequently, new Notification, 916 Snapshot and Delta files) too often. Usually the maintenance of the 917 RPKI repository includes regular updates of manifest and CRL objects, 918 performed on a schedule. This often results in bursts of repository 919 updates during a short period of time. Since the RPs are required to 920 poll for the Update Notification File not more often than once per 921 minute (Section 3.4.4), it is not practical to generate new serial 922 versions of the repository much more often than 1 per minute. It is 923 allowed to combine multiple updates, possibly from different CAs, 924 into a new serial repository version (Section 3.3.2). This will 925 significantly shorten the size of the Update Notification File and 926 total amount of data distributed to all RPs. 928 5.3. HTTPS considerations 930 It is RECOMMENDED that Relying Parties and Publication Servers follow 931 the Best Current Practices outlined in [RFC7525] on the use of HTTP 932 over TLS (HTTPS) [RFC2818]. 934 Note that a Man-in-the-Middle (MITM) cannot produce validly signed 935 RPKI data, but they can perform withhold or replay attacks targeting 936 an RP, and keep the RP from learning about changes in the RPKI. 937 Because of this RPs SHOULD do TLS certificate and host name 938 validation when they fetch from an RRDP Publication Server. 940 RP tools SHOULD log any TLS certificate or host name validation 941 issues they find, so that an operator can investigate the cause. 942 However, such validation issues are often due to configuration 943 errors, or a lack of a common TLS trust anchor. In these cases it is 944 better if the RP retrieves the signed RPKI data regardless, and 945 performs validation on it. Therefore RP MUST continue to retrieve 946 the data in case of errors. The RP MAY choose to log encountered 947 issues only when fetching the notification update file, but not when 948 it subsequently fetches snapshot or delta files from the same host. 949 Furthermore the RP MAY provide a way for operators to accept 950 untrusted connections for a given host, after the cause has been 951 identified. 953 6. Security Considerations 955 RRDP deals exclusively with transfer of RPKI objects from a 956 repository server to a relying party. The trust relation between a 957 CA and its repository server is out of scope for this document. 958 However, it should be noted that from a relying party point of view 959 all RPKI objects (certificates, CRLs, and CMS-wrapped objects) are 960 already covered by object security mechanisms including signed 961 manifests. This allows validation of these objects even though the 962 repository server itself is not trusted. This document makes no 963 change to RPKI validation procedures per se. 965 The original RPKI transport protocol is rsync, which offers no 966 channel security mechanism. RRDP replaces the use of rsync by HTTPS; 967 while the channel security mechanism underlying RRDP (HTTPS) is not a 968 cure-all, it does make some forms of denial of service attack more 969 difficult for the attacker. HTTPS issues are discussed in more 970 detail in Section 5.3. 972 Supporting both RRDP and rsync necessarily increases the number of 973 opportunities for a malicious RPKI CA to perform denial of service 974 attacks on relying parties, by expanding the number of URIs which the 975 RP may need to contact in order to complete a validation run. 976 However, other than the relative cost of HTTPS versus rsync, adding 977 RRDP to the mix does not change this picture significantly: with 978 either RRDP or rsync a malicious CA can supply an effectively 979 infinite series of URIs for the RP to follow. The only real solution 980 to this is for the RP to apply some kind of bound to the amount of 981 work it is willing to do. Note also that the attacker in this 982 scenario must be an RPKI CA, since otherwise the normal RPKI object 983 security checks would reject the malicious URIs. 985 Processing costs for objects retrieved using RRDP may be somewhat 986 different from the same objects retrieved using rsync: because RRDP 987 treats an entire set of changes as a unit (one "delta"), it may not 988 be practical to start processing any of the objects in the delta 989 until the entire delta has been received. With rsync, by contrast, 990 incremental processing may be easy, but the overall cost of transfer 991 may be higher, as may be the number of corner cases in which the RP 992 retrieves some but not all of the updated objects. Overall, RRDP's 993 behavior is closer to a proper transactional system, which (probably) 994 leads to an overall reliability increase. 996 RRDP is designed to scale much better than rsync. In particular, 997 RRDP is designed to allow use of HTTPS caching infrastructure to 998 reduce load on primary publication servers and increase resilience 999 against denial of service attacks on the RPKI publication service. 1001 7. IANA Considerations 1003 IANA is requested to update the reference for id-ad-rpkiNotify to 1004 this document in the PKIX Access Descriptor registry 1005 [IANA-AD-NUMBERS]. 1007 8. Acknowledgements 1009 The authors would like to thank David Mandelberg for reviewing this 1010 document. 1012 9. References 1014 9.1. Normative References 1016 [I-D.ietf-sidr-publication] 1017 Weiler, S., Sonalker, A., and R. Austein, "A Publication 1018 Protocol for the Resource Public Key Infrastructure 1019 (RPKI)", draft-ietf-sidr-publication-10 (work in 1020 progress), January 2017. 1022 [IANA-AD-NUMBERS] 1023 "SMI Security for PKIX Access Descriptor", 1024 . 1027 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1028 Requirement Levels", BCP 14, RFC 2119, 1029 DOI 10.17487/RFC2119, March 1997, 1030 . 1032 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 1033 DOI 10.17487/RFC2818, May 2000, 1034 . 1036 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1037 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1038 DOI 10.17487/RFC4122, July 2005, 1039 . 1041 [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI 1042 Scheme", RFC 5781, DOI 10.17487/RFC5781, February 2010, 1043 . 1045 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 1046 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 1047 February 2012, . 1049 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 1050 Resource Certificate Repository Structure", RFC 6481, 1051 DOI 10.17487/RFC6481, February 2012, 1052 . 1054 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 1055 X.509 PKIX Resource Certificates", RFC 6487, 1056 DOI 10.17487/RFC6487, February 2012, 1057 . 1059 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1060 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1061 DOI 10.17487/RFC7231, June 2014, 1062 . 1064 [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1065 Protocol (HTTP/1.1): Conditional Requests", RFC 7232, 1066 DOI 10.17487/RFC7232, June 2014, 1067 . 1069 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1070 "Recommendations for Secure Use of Transport Layer 1071 Security (TLS) and Datagram Transport Layer Security 1072 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1073 2015, . 1075 [RFC7730] Huston, G., Weiler, S., Michaelson, G., and S. Kent, 1076 "Resource Public Key Infrastructure (RPKI) Trust Anchor 1077 Locator", RFC 7730, DOI 10.17487/RFC7730, January 2016, 1078 . 1080 9.2. Informative References 1082 [I-D.ietf-sidrops-rpki-tree-validation] 1083 Muravskiy, O. and T. Bruijnzeels, "RPKI Certificate Tree 1084 Validation by the RIPE NCC RPKI Validator", draft-ietf- 1085 sidrops-rpki-tree-validation-00 (work in progress), 1086 January 2017. 1088 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 1089 "Manifests for the Resource Public Key Infrastructure 1090 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, 1091 . 1093 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object 1094 Template for the Resource Public Key Infrastructure 1095 (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, 1096 . 1098 [rsync] "Rsync home page", . 1100 Authors' Addresses 1102 Tim Bruijnzeels 1103 RIPE NCC 1105 Email: tim@ripe.net 1107 Oleg Muravskiy 1108 RIPE NCC 1110 Email: oleg@ripe.net 1112 Bryan Weber 1113 Cobenian 1115 Email: bryan@cobenian.com 1117 Rob Austein 1118 Dragon Research Labs 1120 Email: sra@hactrn.net