idnits 2.17.1 draft-ietf-sidr-delta-protocol-06.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 == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. (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 (February 10, 2017) is 2624 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 818, but not defined == Missing Reference: 'RFC3986' is mentioned on line 857, but not defined == 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 7234 (Obsoleted by RFC 9111) ** 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: 9 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: August 14, 2017 Cobenian 7 R. Austein 8 Dragon Research Labs 9 February 10, 2017 11 RPKI Repository Delta Protocol 12 draft-ietf-sidr-delta-protocol-06 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], to remove the dependency 26 on [rsync] as the only mandatory RPKI repository distribution 27 mechanism. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on August 14, 2017. 46 Copyright Notice 48 Copyright (c) 2017 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 64 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. RPKI Repository Delta Protocol Implementation . . . . . . . . 4 66 3.1. Informal Overview . . . . . . . . . . . . . . . . . . . . 4 67 3.2. Certificate Authority Use . . . . . . . . . . . . . . . . 5 68 3.3. Repository Server Use . . . . . . . . . . . . . . . . . . 5 69 3.3.1. Initialisation . . . . . . . . . . . . . . . . . . . 5 70 3.3.2. Publishing Updates . . . . . . . . . . . . . . . . . 6 71 3.4. Relying Party Use . . . . . . . . . . . . . . . . . . . . 7 72 3.4.1. Processing the Update Notification File . . . . . . . 7 73 3.4.2. Processing Delta Files . . . . . . . . . . . . . . . 8 74 3.4.3. Processing a Snapshot File . . . . . . . . . . . . . 9 75 3.4.4. Polling the Update Notification File . . . . . . . . 9 76 3.4.5. Considerations Regarding Operational Failures in RRDP 10 77 3.5. File Definitions . . . . . . . . . . . . . . . . . . . . 10 78 3.5.1. Update Notification File . . . . . . . . . . . . . . 10 79 3.5.2. Snapshot File . . . . . . . . . . . . . . . . . . . . 12 80 3.5.3. Delta File . . . . . . . . . . . . . . . . . . . . . 13 81 3.5.4. XML Schema . . . . . . . . . . . . . . . . . . . . . 15 82 4. Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 83 4.1. Updates to RFC6480 . . . . . . . . . . . . . . . . . . . 17 84 4.1.1. Update in Section 4.3, Access Protocols . . . . . . . 17 85 4.1.2. Update in Section 11.1, Normative References . . . . 17 86 4.1.3. Update in Section 11.2, Informative References . . . 17 87 4.2. Updates to RFC6481 . . . . . . . . . . . . . . . . . . . 18 88 4.2.1. Update in Section 3, Resource Certificate Publication 89 Repository Considerations . . . . . . . . . . . . . . 18 90 4.2.2. Update in Section 9.1, Normative References . . . . . 18 91 4.2.3. Update in Section 9.2, Informative References . . . . 18 92 4.3. Updates to RFC7730 . . . . . . . . . . . . . . . . . . . 18 93 4.3.1. Update in Section 2.1, Trust Anchor Locator Format . 18 94 4.3.2. Update in Section 2.2, TAL and Trust Anchor 95 Certificate Considerations . . . . . . . . . . . . . 19 96 4.3.3. Update in Section 5.1, Normative References . . . . . 19 97 5. Operational Considerations . . . . . . . . . . . . . . . . . 19 98 5.1. Compatibility with previous standards . . . . . . . . . . 19 99 5.2. Distribution considerations . . . . . . . . . . . . . . . 20 100 5.3. HTTPS considerations . . . . . . . . . . . . . . . . . . 20 101 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 102 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 103 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 104 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 105 9.1. Normative References . . . . . . . . . . . . . . . . . . 22 106 9.2. Informative References . . . . . . . . . . . . . . . . . 24 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 109 1. Requirements notation 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 2. Introduction 117 In the Resource Public Key Infrastructure (RPKI), Certificate 118 Authorities (CAs) publish certificates [RFC6487], RPKI signed objects 119 [RFC6488], manifests [RFC6486], and CRLs to repositories. CAs may 120 have an embedded mechanism to publish to these repositories, or they 121 may use a separate repository server and publication protocol. RPKI 122 repositories are currently accessible using the [rsync] protocol, 123 allowing Relying Parties (RPs) to synchronise a local copy of the 124 RPKI repository used for validation with the remote repositories 125 [RFC6481]. 127 This document specifies an alternative repository access protocol 128 based on notification, snapshot and delta files that a RP can 129 retrieve over the HTTPS protocol. This allows RPs to perform either 130 a full (re-)synchronisation of their local copy of the repository 131 using snapshot files, or use delta files to keep their local 132 repository updated after initial synchronisation. We call this the 133 RPKI Repository Delta Protocol, or RRDP in short. 135 This protocol is designed to be consistent (in terms of data 136 structures) with the publication protocol [I-D.ietf-sidr-publication] 137 and treats publication events of one or more repository objects as 138 discrete events that can be communicated to relying parties. This 139 approach helps to minimize the amount of data that traverses the 140 network and thus helps minimize the amount of time until repository 141 convergence occurs. This protocol also provides a standards based 142 way to obtain consistent, point in time views of a single repository, 143 eliminating a number of consistency related issues. Finally, this 144 approach allows these discrete events to be communicated as immutable 145 files, so that caching infrastructure can be used to reduce the load 146 on a repository server when a large number of relying parties are 147 querying it. 149 In order to facilitate transition to this new protocol, this document 150 updates the texts of [RFC6480], [RFC6481], and [RFC7730], removing 151 the dependency on [rsync] as the only mandatory RPKI repository 152 distribution mechanism, and allowing use of a non-rsync URI in a 153 Trust Anchor Locator file. 155 3. RPKI Repository Delta Protocol Implementation 157 3.1. Informal Overview 159 Certification Authorities (CA) in the RPKI use a repository server to 160 publish their RPKI products, such as manifests, CRLs, signed 161 certificates and RPKI signed objects. This repository server may be 162 remote, or embedded in the CA engine itself. Certificates in the 163 RPKI that use a repository server that supports this delta protocol 164 include a special Subject Information Access (SIA) pointer referring 165 to a notification file. 167 The notification file includes a globally unique session_id in the 168 form of a version 4 UUID ([RFC4122]), and serial number that can be 169 used by the Relying Party (RP) to determine if it and the repository 170 are synchronised. Furthermore it includes a link to the most recent 171 complete snapshot of current objects that are published by the 172 repository server, and a list of links to delta files, for each 173 revision starting at a point determined by the repository server, up 174 to the current revision of the repository. 176 A RP that learns about a notification file location for the first 177 time can download it, and then proceed to download the latest 178 snapshot file, and thus create a local copy of the repository that is 179 in sync with the repository server. The RP records the location of 180 this notification file, the session_id and current serial number. 182 RPs are encouraged to re-fetch this notification file at regular 183 intervals, but not more often than once per minute. After re- 184 fetching the notification file, the RP may find that there are one or 185 more delta files available that allow it to synchronise its local 186 repository with the current state of the repository server. If no 187 contiguous chain of deltas from RP's serial to the latest repository 188 serial is available, or if the session_id has changed, the RP 189 performs a full resynchronisation instead. 191 As soon as the RP fetches new content in this way it could start a 192 validation process. An example of a reason why a RP may not do this 193 immediately is because it has learned of more than one notification 194 location and it prefers to complete all its updates before 195 validating. 197 The repository server could use caching infrastructure to reduce its 198 load, particularly because snapshots and deltas for any given 199 session_id and serial number contain an immutable record of the state 200 of the repository server at a certain point in time. For this reason 201 these files can be cached indefinitely. Notification files are 202 polled by RPs to discover if updates exist, and for this reason 203 notification files may not be cached for longer than one minute. 205 3.2. Certificate Authority Use 207 Certificate Authorities that use this delta protocol MUST include an 208 instance of an SIA AccessDescription extension in resource 209 certificates they produce, in addition to the ones defined in 210 [RFC6487], 212 AccessDescription ::= SEQUENCE { 213 accessMethod OBJECT IDENTIFIER, 214 accessLocation GeneralName } 216 This extension MUST use an accessMethod of id-ad-rpkiNotify, see 217 Section 7: 219 id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 220 dod(6) internet(1) security(5) mechanisms(5) pkix(7) } 222 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 224 id-ad-rpkiNotify OBJECT IDENTIFIER ::= { id-ad 13 } 226 The accessLocation MUST be an HTTPS URI as defined in [RFC2818], that 227 will point to the update notification file for the repository server 228 that publishes the products of this CA certificate. 230 3.3. Repository Server Use 232 3.3.1. Initialisation 234 When the repository server initialises it performs the following 235 actions: 237 o The server MUST generate a new random version 4 UUID to be used as 238 the session_id 240 o The server MUST then generate a snapshot file for serial number 241 ONE for this new session that includes all currently known 242 published objects that the repository server is responsible for. 243 Note that this snapshot file may contain zero publish elements at 244 this point if no objects have been submitted for publication yet. 246 o This snapshot file MUST be made available at a URL that is unique 247 to this session_id and serial number, so that it can be cached 248 indefinitely. The format and caching concerns for snapshot files 249 are explained in more detail in Section 3.5.2. 251 o After the snapshot file has been published the repository server 252 MUST publish a new notification file that contains the new 253 session_id, has serial number ONE, has one reference to the 254 snapshot file that was just published, and that contains no delta 255 references. The format and caching concerns for update 256 notification files are explained in more detail in Section 3.5.1. 258 3.3.2. Publishing Updates 260 Whenever the repository server receives updates from a CA it MUST 261 generate new snapshot and delta files within one minute. If a 262 publication server services a large number of CAs it MAY choose to 263 combine updates from multiple CAs. If a publication server combines 264 updates in this way, it MUST ensure that publication never postponed 265 for longer than one minute for any of the CAs involved. 267 Updates are processed as follows: 269 o The new repository serial number MUST be one greater than the 270 current repository serial number. 272 o A new delta file MUST be generated for this new serial. This 273 delta file MUST include all new, replaced and withdrawn objects 274 for multiple CAs if applicable, as a single change set. 276 o This delta file MUST be made available at a URL that is unique to 277 the current session_id and serial number, so that it can be cached 278 indefinitely. 280 o The format and caching concerns for delta files are explained in 281 more detail in Section 3.5.3. 283 o The repository server MUST also generate a new snapshot file for 284 this new serial. This file MUST contain all "publish" elements 285 for all current objects. 287 o The snapshot file MUST be made available at a URL that is unique 288 to this session and new serial, so that it can be cached 289 indefinitely. 291 o The format and caching concerns for snapshot files are explained 292 in more detail in Section 3.5.2. 294 o Any older delta files that, when combined with all more recent 295 delta files, will result in total size of deltas exceeding the 296 size of the snapshot, MUST be excluded to avoid that RPs download 297 more data than necessary. 299 o A new notification file MUST now be created by the repository 300 server. This new notification file MUST include a reference to 301 the new snapshot file, and all delta files selected in the 302 previous steps. 304 o The format and caching concerns for update notification files are 305 explained in more detail in Section 3.5.1. 307 If the repository server is not capable of performing the above for 308 some reason, then it MUST perform a full re-initialisation, as 309 explained above in Section 3.3.1. 311 3.4. Relying Party Use 313 3.4.1. Processing the Update Notification File 315 When a Relying Party (RP) performs RPKI validation and learns about a 316 valid certificate with an SIA entry for the RRDP protocol, it SHOULD 317 use this protocol as follows. 319 The RP MUST download the update notification file, unless an update 320 notification file was already downloaded and processed from the same 321 location in this validation run, or because a polling strategy was 322 used (see Section 3.4.4). 324 It is RECOMMENDED that RP uses a "User-Agent" header explained in 325 section 5.5.3. of [RFC7231] to identify the name and version of the 326 RP software used. It is useful to track capabilities of Relying 327 Parties in the event of changes to the RPKI standards. 329 When the RP downloads an update notification file it MUST verify the 330 file format and validation steps described in section 331 Section 3.5.1.3. If this verification fails, the file MUST be 332 rejected and RRDP cannot be used. See Section 3.4.5 for 333 considerations. 335 The RP MUST verify whether the session_id in this update notification 336 file matches the last known session_id for this update notification 337 file location. If the session_id matches the last known session_id, 338 then an RP MAY download and process missing delta files as described 339 in section Section 3.4.2, provided that all delta files for serial 340 numbers between the last processed serial number and the current 341 serial number in the notification file can be processed this way. 343 If the session_id was not previously known, or if delta files could 344 not be used, then the RP MUST update its last known session_id to 345 this session_id and download and process snapshot file on the update 346 notification file as described in section Section 3.4.3. 348 3.4.2. Processing Delta Files 350 If an update notification file contains a contiguous chain of links 351 to delta files from the last processed serial number to the current 352 serial number, then RPs MUST attempt to download and process all 353 delta files in order of serial number as follows. 355 When the RP downloads a delta file it MUST verify the file format and 356 perform validation steps described in Section 3.5.3.3. If this 357 verification fails, the file MUST be rejected. 359 Furthermore the RP MUST verify that the hash of the contents of this 360 file matches the hash on the update notification file that referenced 361 it. In case of a mismatch of this hash, the file MUST be rejected. 363 If an RP retrieved a delta file that is valid according to the above 364 criteria, it performs the following actions: 366 The RP MUST verify that the session_id matches the session_id of 367 the notification file. If the session_id values do not match the 368 file MUST be rejected. 370 The RP MUST verify that the serial number of this delta file is 371 exactly one greater than the last processed serial number for this 372 session_id, and if not this file MUST be rejected. 374 The RP SHOULD add all publish elements to a local storage and 375 update its last processed serial number to the serial number of 376 this delta file. 378 The RP SHOULD NOT remove objects from its local storage solely 379 because it encounters a "withdraw" element, because this would 380 enable a publication server to withdraw any object without the 381 signing Certificate Authority consent. The RP could use 382 additional strategies to determine if an object is still relevant 383 for validation before removing it from its local storage. In 384 particular objects should not be removed if they are included in a 385 current validated manifest. 387 If any delta file is rejected RPs MUST process the current Snapshot 388 File instead, as described in Section 3.4.3. 390 3.4.3. Processing a Snapshot File 392 Snapshot Files MUST only be used if Delta Files are unavailable, or 393 were rejected. As is ensured, if the process described in 394 Section 3.4.1 is followed. 396 When the RP downloads a snapshot file it MUST verify the file format 397 and validation steps described in Section 3.5.2.3. If this 398 verification fails, the file MUST be rejected. 400 Furthermore the RP MUST verify that the hash of the contents of this 401 file matches the hash on the update notification file that referenced 402 it. In case of a mismatch of this hash, the file MUST be rejected. 404 If an RP retrieved a snapshot file that is valid according to the 405 above criteria, it performs the following actions: 407 The RP MUST verify that the session_id matches the session_id of 408 the notification file. If the session_id values do not match the 409 file MUST be rejected. 411 The RP MUST verify that the serial number of this snapshot file is 412 greater than the last processed serial number for this session_id. 413 If this fails the file MUST be rejected. 415 The RP SHOULD then add all publish elements to a local storage and 416 update its last processed serial number to the serial number of 417 this snapshot file. 419 If a Snapshot File is rejected that means that RRDP cannot be used. 420 See Section 3.4.5 for considerations. 422 3.4.4. Polling the Update Notification File 424 Once a Relying Party has learned about the location, session_id and 425 last processed serial number of repository that uses the RRDP 426 protocol, the RP MAY start polling the repository server for updates. 427 However the RP MUST NOT poll for updates more often than once every 1 428 minute, and in order to reduce data usage RPs MUST use the "If- 429 Modified-Since" header explained in section 3.3 of [RFC7232] in 430 requests. 432 If an RP finds that updates are available it SHOULD download and 433 process the file as described in Section 3.4.1, and initiate a new 434 RPKI object validation process. However, a detailed description of 435 the RPKI object validation process itself is out of scope of this 436 document. 438 3.4.5. Considerations Regarding Operational Failures in RRDP 440 If an RP experiences any issues with retrieving or processing any of 441 the files used in this protocol, it will be unable to retrieve new 442 RPKI data from the affected publication server. 444 Relying Parties could attempt to use alternative repository access 445 mechanisms, if they are available, according to the accessMethod 446 element value(s) specified in the SIA of the associated certificate 447 (see Section 4.8.8 of [RFC6487]). 449 Furthermore Relying Parties may wish to employ re-try strategies 450 while fetching RRDP files. Relying Parties are also advised to keep 451 old objects in their local cache so that validation can be done using 452 old objects. 454 It is also recommendable that re-validation and retrieval is 455 performed pro-actively before manifests or CRLs go stale, or 456 certificates expire, to ensure that problems on the side of the RP 457 can be identified and resolved before they cause major concerns. 459 3.5. File Definitions 461 3.5.1. Update Notification File 463 3.5.1.1. Purpose 465 The update notification file is used by RPs to discover whether any 466 changes exist between the state of the repository and the RP's cache. 467 It describes the location of the files containing the snapshot and 468 incremental deltas which can be used by the RP to synchronise with 469 the repository. 471 3.5.1.2. Cache Concerns 473 A repository server MAY use caching infrastructure to cache the 474 notification file and reduce the load of HTTPS requests. However, 475 since this file is used by RPs to determine whether any updates are 476 available the repository server SHOULD ensure that this file is not 477 cached for longer than 1 minute. An exception to this rule is that 478 it is better to serve a stale notification file, than no notification 479 file. 481 How this is achieved exactly depends on the caching infrastructure 482 used. In general a repository server may find certain HTTP headers 483 to be useful, such as: "Cache-Control: max-age=60" (see Section 5.2 484 of [RFC7234]). Another approach can be to have the repository server 485 push out new versions of the notification file to the caching 486 infrastructure when appropriate. 488 In case of a high load on a repository server or its distribution 489 network, the Cache-Control HTTP header, or a similar mechanism, MAY 490 be used to suggest an optimal (for the repository server) poll 491 interval for Relying Parties. However, setting it to an interval 492 longer than 1 hour is NOT RECOMMENDED. Relying parties SHOULD align 493 the suggested interval with their operational practices and the 494 expected update frequency of RPKI repository data, and MAY discard 495 suggested value. 497 3.5.1.3. File Format and Validation 499 Example notification file: 501 505 506 507 508 510 Note: URIs and hash values in this example are shortened because of 511 formatting. 513 The following validation rules MUST be observed when creating or 514 parsing notification files: 516 o A RP MUST reject any update notification file that is not well- 517 formed, or which does not conform to the RELAX NG schema outlined 518 in Section 3.5.4 of this document. 520 o The XML namespace MUST be http://www.ripe.net/rpki/rrdp 522 o The encoding MUST be US-ASCII 524 o The version attribute in the notification root element MUST be 1 526 o The session_id attribute MUST be a random version 4 UUID 527 ([RFC4122]), unique to this session 529 o The serial attribute MUST be an unbounded, unsigned positive 530 integer in decimal format indicating the current version of the 531 repository. 533 o The notification file MUST contain exactly one 'snapshot' element 534 for the current repository version. 536 o If delta elements are included they MUST form a contiguous 537 sequence of serial numbers starting at a revision determined by 538 the repository server, up to the serial number mentioned in the 539 notification element. Note that the elements may not be ordered. 541 o The hash attribute in snapshot and delta elements MUST be the 542 hexadecimal encoding of the SHA-256 hash of the referenced file. 543 The RP MUST verify this hash when the file is retrieved and reject 544 the file if the hash does not match. 546 3.5.2. Snapshot File 548 3.5.2.1. Purpose 550 A snapshot is intended to reflect the complete and current contents 551 of the repository for a specific session and version. Therefore it 552 MUST contain all objects from the repository current as of the time 553 of the publication. 555 3.5.2.2. Cache Concerns 557 A snapshot reflects the content of the repository at a specific point 558 in time, and for that reason can be considered immutable data. 559 Snapshot files MUST be published at a URL that is unique to the 560 specific session and serial. 562 Because these files never change, they MAY be cached indefinitely. 563 However, in order to prevent that these files use a lot of space in 564 caching infrastructure it is RECOMMENDED that a limited interval is 565 used in the order of hours or days. 567 To avoid race conditions where an RP downloads a notification file 568 moments before it's updated, Repository Servers SHOULD retain old 569 snapshot files for at least 5 minutes after a new notification file 570 is published. 572 3.5.2.3. File Format and Validation 574 Example snapshot file: 576 580 581 ZXhhbXBsZTE= 582 583 584 ZXhhbXBsZTI= 585 586 587 ZXhhbXBsZTM= 588 589 591 The following rules MUST be observed when creating or parsing 592 snapshot files: 594 o A RP MUST reject any snapshot file that is not well-formed, or 595 which does not conform to the RELAX NG schema outlined in 596 Section 3.5.4 of this document. 598 o The XML namespace MUST be http://www.ripe.net/rpki/rrdp. 600 o The encoding MUST be US-ASCII. 602 o The version attribute in the notification root element MUST be 1 604 o The session_id attribute MUST match the expected session_id in the 605 reference in the notification file. 607 o The serial attribute MUST match the expected serial in the 608 reference in the notification file. 610 o Note that the publish element is similar to the publish element 611 defined in the publication protocol [I-D.ietf-sidr-publication]. 612 However, the "tag" attribute is not used here because it is not 613 relevant to relying parties. The "hash" attribute is not used 614 here because this file represents a complete current state of the 615 repository, and therefore it is not relevant to know which 616 existing RPKI object (if any) is updated. 618 3.5.3. Delta File 619 3.5.3.1. Purpose 621 An incremental delta file contains all changes for exactly one serial 622 increment of the repository server. In other words a single delta 623 will typically include all the new objects, updated objects and 624 withdrawn objects that a Certification Authority sent to the 625 repository server. In its simplest form the update could concern 626 only a single object, but it is RECOMMENDED that CAs send all changes 627 for one of their key pairs (updated objects as well as a new manifest 628 and CRL) as one atomic update message. 630 3.5.3.2. Cache Concerns 632 Deltas reflect the difference between two consecutive versions of a 633 repository for a given session. For that reason deltas can be 634 considered immutable data. Delta files MUST be published at a URL 635 that is unique to the specific session and serial. 637 Because these files never change, they MAY be cached indefinitely. 638 However, in order to prevent these files from using a lot of space in 639 caching infrastructure it is RECOMMENDED that a limited interval is 640 used in the order of hours or days. 642 To avoid race conditions where an RP downloads a notification file 643 moments before it's updated, Repository Servers SHOULD retain old 644 delta files for at least 5 minutes after they are no longer included 645 in the latest notification file. 647 3.5.3.3. File Format and Validation 649 Example delta file: 651 655 657 ZXhhbXBsZTQ= 658 659 661 ZXhhbXBsZTU= 662 663 665 667 Note that a formal RELAX NG specification of this file format is 668 included later in this document. A RP MUST NOT process any delta 669 file that is incomplete or not well-formed. 671 The following validation rules MUST be observed when creating or 672 parsing delta files: 674 o A RP MUST reject any delta file that is not well-formed, or which 675 does not conform to the RELAX NG schema outlined in Section 3.5.4 676 of this document. 678 o The XML namespace MUST be http://www.ripe.net/rpki/rrdp. 680 o The encoding MUST be US-ASCII. 682 o The version attribute in the delta root element MUST be 1 684 o The session_id attribute MUST be a random version 4 UUID unique to 685 this session 687 o The session_id attribute MUST match the expected session_id in the 688 reference in the notification file. 690 o The serial attribute MUST match the expected serial in the 691 reference in the notification file. 693 o Note that the publish element is similar to the publish element 694 defined in the publication protocol [I-D.ietf-sidr-publication]. 695 However, the "tag" attribute is not used here because it is not 696 relevant to relying parties. 698 3.5.4. XML Schema 700 The following is a RELAX NG compact form schema describing version 1 701 of this protocol. 703 # 704 # RelaxNG schema for RPKI Repository Delta Protocol (RRDP). 705 # 707 default namespace = "http://www.ripe.net/rpki/rrdp" 709 version = xsd:positiveInteger { maxInclusive="1" } 710 serial = xsd:positiveInteger 711 uri = xsd:anyURI 712 uuid = xsd:string { pattern = "[\-0-9a-fA-F]+" } 713 hash = xsd:string { pattern = "[0-9a-fA-F]+" } 714 base64 = xsd:base64Binary 715 # Notification file: lists current snapshots and deltas 717 start |= element notification { 718 attribute version { version }, 719 attribute session_id { uuid }, 720 attribute serial { serial }, 721 element snapshot { 722 attribute uri { uri }, 723 attribute hash { hash } 724 }, 725 element delta { 726 attribute serial { serial }, 727 attribute uri { uri }, 728 attribute hash { hash } 729 }* 730 } 732 # Snapshot segment: think DNS AXFR. 734 start |= element snapshot { 735 attribute version { version }, 736 attribute session_id { uuid }, 737 attribute serial { serial }, 738 element publish { 739 attribute uri { uri }, 740 base64 741 }* 742 } 744 # Delta segment: think DNS IXFR. 746 start |= element delta { 747 attribute version { version }, 748 attribute session_id { uuid }, 749 attribute serial { serial }, 750 delta_element+ 751 } 753 delta_element |= element publish { 754 attribute uri { uri }, 755 attribute hash { hash }?, 756 base64 757 } 759 delta_element |= element withdraw { 760 attribute uri { uri }, 761 attribute hash { hash } 762 } 763 # Local Variables: 764 # indent-tabs-mode: nil 765 # comment-start: "# " 766 # comment-start-skip: "#[ \t]*" 767 # End: 769 4. Updates 771 This section provides updates to several paragraphs in [RFC6480], 772 [RFC6481], and [RFC7730]. For clarity, the original text and the 773 replacement text are shown. 775 4.1. Updates to RFC6480 777 4.1.1. Update in Section 4.3, Access Protocols 779 OLD: 781 To ensure all relying parties are able to acquire all RPKI signed 782 objects, all publication points MUST be accessible via rsync (see 783 [RFC5781] and [RSYNC]), although other download protocols MAY also 784 be supported. A repository publication point may provide 785 update/change/delete functionality via (set of) access protocols 786 that it desires, provided that the supported protocols are clearly 787 communicated to all certification authorities publishing data at a 788 given publication point. 790 NEW: 792 To ensure all relying parties are able to acquire all RPKI signed 793 objects, all publication points MUST be accessible using retrieval 794 mechanism(s) consistent with the accessMethod element value(s). 795 Multiple retrieval mechanisms MAY be supported at the repository 796 operator's discretion. A repository publication point may provide 797 update/change/delete functionality via (set of) access protocols 798 that it desires, provided that the supported protocols are clearly 799 communicated to all certification authorities publishing data at a 800 given publication point. 802 4.1.2. Update in Section 11.1, Normative References 804 Remove the reference to RFC5781, "The rsync URI Scheme". 806 4.1.3. Update in Section 11.2, Informative References 808 Remove the reference to rsync, "rsync web pages". 810 4.2. Updates to RFC6481 812 4.2.1. Update in Section 3, Resource Certificate Publication Repository 813 Considerations 815 OLD: 817 The publication repository MUST be available using rsync [RFC5781] 818 [RSYNC]. Support of additional retrieval mechanisms is the choice 819 of the repository operator. The supported retrieval mechanisms 820 MUST be consistent with the accessMethod element value(s) 821 specified in the SIA of the associated CA or EE certificate. 823 NEW: 825 The publication repository MUST be available using retrieval 826 mechanism(s) consistent with the accessMethod element value(s) 827 specified in the SIA of the associated CA or EE certificate. 828 Support of multiple retrieval mechanisms is the choice of the 829 repository operator. 831 4.2.2. Update in Section 9.1, Normative References 833 Remove the reference to RFC5781, "The rsync URI Scheme". 835 4.2.3. Update in Section 9.2, Informative References 837 Remove the reference to rsync, "rsync web pages". 839 4.3. Updates to RFC7730 841 4.3.1. Update in Section 2.1, Trust Anchor Locator Format 843 OLD: 845 where the URI section is comprised of one of more of the ordered 846 sequence of: 848 1.1) an rsync URI [RFC5781], 850 1.2) a or line break. 852 NEW: 854 where the URI section is comprised of one of more of the ordered 855 sequence of: 857 1.1) a URI [RFC3986], 858 1.2) a or line break. 860 4.3.2. Update in Section 2.2, TAL and Trust Anchor Certificate 861 Considerations 863 OLD: 865 Each rsync URI in the TAL MUST reference a single object. It MUST 866 NOT reference a directory or any other form of collection of 867 objects. 869 ... 871 Where the TAL contains two or more rsync URIs, then the same self- 872 signed CA certificate MUST be found at each referenced location. 874 NEW: 876 Each URI in the TAL MUST reference a single object. It MUST NOT 877 reference a directory or any other form of collection of objects. 879 ... 881 Where the TAL contains two or more URIs, then the same self-signed 882 CA certificate MUST be found at each referenced location. 884 4.3.3. Update in Section 5.1, Normative References 886 Remove the reference to RFC5781, "The rsync URI Scheme". 888 Add a reference to RFC3986, "Uniform Resource Identifier (URI): 889 Generic Syntax". 891 5. Operational Considerations 893 5.1. Compatibility with previous standards 895 This protocol has been designed to replace rsync as a distribution 896 mechanism of an RPKI repository. However, it is also designed to co- 897 exist with existing implementations based on rsync, to enable smooth 898 transition from one distribution mechanism to another. 900 For every repository object listed in the snapshot and delta files 901 both the hash of the object's content and the rsync URI [RFC5781] of 902 its location in the repository are listed. This makes it possible to 903 distribute the same RPKI repository, represented by a set of files on 904 a filesystem, using both rsync and RRDP. It also enables Relying 905 Parties tools to query, combine, and consequently validate objects 906 from repositories of different types. (For an example of such 907 implementation see [I-D.ietf-sidrops-rpki-tree-validation].) 909 5.2. Distribution considerations 911 One of the design goals of RRDP was to minimise load on a repository 912 server while serving clients. To achieve this, neither the content, 913 nor the URLs of the snapshot and delta files are modified after they 914 have been published in the notification file. This allows their 915 effective distribution, either by a single HTTP server, or using a 916 Content Distribution Network (CDN). 918 The RECOMMENDED way for RPs to keep up with the repository updates is 919 to poll the Update Notification File for changes. The content of 920 that file is updated with every new serial version of a repository 921 (while its URL remains stable). To effectively implement 922 distribution of the notification file, an "If-Modified-Since" HTTP 923 request header is required to be present in all requests for 924 notification file (see Section 3.4.4.) Therefore it is RECOMMENDED 925 that RP tools implement a mechanism to keep track of a previous 926 successful fetch of a notification file. 928 Implementations of RRDP should also take care of not producing new 929 versions of the repository (and subsequently, new Notification, 930 Snapshot and Delta files) too often. Usually the maintenance of the 931 RPKI repository includes regular updates of manifest and CRL objects, 932 performed on a schedule. This often results in bursts of repository 933 updates during a short period of time. Since the RPs are required to 934 poll for the Update Notification File not more often than once per 935 minute (Section 3.4.4), it is not practical to generate new serial 936 versions of the repository much more often than 1 per minute. It is 937 allowed to combine multiple updates, possibly from different CAs, 938 into a new serial repository version (Section 3.3.2). This will 939 significantly shorten the size of the Update Notification File and 940 total amount of data distributed to all RPs. 942 5.3. HTTPS considerations 944 It is RECOMMENDED that Relying Parties and Publication Servers follow 945 the Best Current Practices outlined in [RFC7525] on the use of HTTP 946 over TLS (HTTPS) [RFC2818]. 948 Note that a Man-in-the-Middle (MITM) cannot produce validly signed 949 RPKI data, but they can perform withhold or replay attacks targeting 950 an RP, and keep the RP from learning about changes in the RPKI. 951 Because of this RPs SHOULD do TLS certificate and host name 952 validation when they fetch from an RRDP Publication Server. 954 RP tools SHOULD log any TLS certificate or host name validation 955 issues they find, so that an operator can investigate the cause. 956 However, such validation issues are often due to configuration 957 errors, or a lack of a common TLS trust anchor. In these cases it is 958 better if the RP retrieves the signed RPKI data regardless, and 959 performs validation on it. Therefore RP MUST continue to retrieve 960 the data in case of errors. The RP MAY choose to log encountered 961 issues only when fetching the notification update file, but not when 962 it subsequently fetches snapshot or delta files from the same host. 963 Furthermore the RP MAY provide a way for operators to accept 964 untrusted connections for a given host, after the cause has been 965 identified. 967 6. Security Considerations 969 RRDP deals exclusively with transfer of RPKI objects from a 970 repository server to a relying party. The trust relation between a 971 CA and its repository server is out of scope for this document. 972 However, it should be noted that from a relying party point of view 973 all RPKI objects (certificates, CRLs, and CMS-wrapped objects) are 974 already covered by object security mechanisms including signed 975 manifests. This allows validation of these objects even though the 976 repository server itself is not trusted. This document makes no 977 change to RPKI validation procedures per se. 979 The original RPKI transport protocol is rsync, which offers no 980 channel security mechanism. RRDP replaces the use of rsync by HTTPS; 981 while the channel security mechanism underlying RRDP (HTTPS) is not a 982 cure-all, it does make some forms of denial of service attack more 983 difficult for the attacker. HTTPS issues are discussed in more 984 detail in Section 5.3. 986 Supporting both RRDP and rsync necessarily increases the number of 987 opportunities for a malicious RPKI CA to perform denial of service 988 attacks on relying parties, by expanding the number of URIs which the 989 RP may need to contact in order to complete a validation run. 990 However, other than the relative cost of HTTPS versus rsync, adding 991 RRDP to the mix does not change this picture significantly: with 992 either RRDP or rsync a malicious CA can supply an effectively 993 infinite series of URIs for the RP to follow. The only real solution 994 to this is for the RP to apply some kind of bound to the amount of 995 work it is willing to do. Note also that the attacker in this 996 scenario must be an RPKI CA, since otherwise the normal RPKI object 997 security checks would reject the malicious URIs. 999 Processing costs for objects retrieved using RRDP may be somewhat 1000 different from the same objects retrieved using rsync: because RRDP 1001 treats an entire set of changes as a unit (one "delta"), it may not 1002 be practical to start processing any of the objects in the delta 1003 until the entire delta has been received. With rsync, by contrast, 1004 incremental processing may be easy, but the overall cost of transfer 1005 may be higher, as may be the number of corner cases in which the RP 1006 retrieves some but not all of the updated objects. Overall, RRDP's 1007 behavior is closer to a proper transactional system, which (probably) 1008 leads to an overall reliability increase. 1010 RRDP is designed to scale much better than rsync. In particular, 1011 RRDP is designed to allow use of HTTPS caching infrastructure to 1012 reduce load on primary publication servers and increase resilience 1013 against denial of service attacks on the RPKI publication service. 1015 7. IANA Considerations 1017 IANA is requested to update the reference for id-ad-rpkiNotify to 1018 this document in the PKIX Access Descriptor registry 1019 [IANA-AD-NUMBERS]. 1021 8. Acknowledgements 1023 The authors would like to thank David Mandelberg for reviewing this 1024 document. 1026 9. References 1028 9.1. Normative References 1030 [I-D.ietf-sidr-publication] 1031 Weiler, S., Sonalker, A., and R. Austein, "A Publication 1032 Protocol for the Resource Public Key Infrastructure 1033 (RPKI)", draft-ietf-sidr-publication-10 (work in 1034 progress), January 2017. 1036 [IANA-AD-NUMBERS] 1037 "SMI Security for PKIX Access Descriptor", 1038 . 1041 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1042 Requirement Levels", BCP 14, RFC 2119, 1043 DOI 10.17487/RFC2119, March 1997, 1044 . 1046 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 1047 DOI 10.17487/RFC2818, May 2000, 1048 . 1050 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1051 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1052 DOI 10.17487/RFC4122, July 2005, 1053 . 1055 [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI 1056 Scheme", RFC 5781, DOI 10.17487/RFC5781, February 2010, 1057 . 1059 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 1060 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 1061 February 2012, . 1063 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 1064 Resource Certificate Repository Structure", RFC 6481, 1065 DOI 10.17487/RFC6481, February 2012, 1066 . 1068 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 1069 X.509 PKIX Resource Certificates", RFC 6487, 1070 DOI 10.17487/RFC6487, February 2012, 1071 . 1073 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1074 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1075 DOI 10.17487/RFC7231, June 2014, 1076 . 1078 [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1079 Protocol (HTTP/1.1): Conditional Requests", RFC 7232, 1080 DOI 10.17487/RFC7232, June 2014, 1081 . 1083 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 1084 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 1085 RFC 7234, DOI 10.17487/RFC7234, June 2014, 1086 . 1088 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1089 "Recommendations for Secure Use of Transport Layer 1090 Security (TLS) and Datagram Transport Layer Security 1091 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1092 2015, . 1094 [RFC7730] Huston, G., Weiler, S., Michaelson, G., and S. Kent, 1095 "Resource Public Key Infrastructure (RPKI) Trust Anchor 1096 Locator", RFC 7730, DOI 10.17487/RFC7730, January 2016, 1097 . 1099 9.2. Informative References 1101 [I-D.ietf-sidrops-rpki-tree-validation] 1102 Muravskiy, O. and T. Bruijnzeels, "RPKI Certificate Tree 1103 Validation by the RIPE NCC RPKI Validator", draft-ietf- 1104 sidrops-rpki-tree-validation-00 (work in progress), 1105 January 2017. 1107 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 1108 "Manifests for the Resource Public Key Infrastructure 1109 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, 1110 . 1112 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object 1113 Template for the Resource Public Key Infrastructure 1114 (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, 1115 . 1117 [rsync] "Rsync home page", . 1119 Authors' Addresses 1121 Tim Bruijnzeels 1122 RIPE NCC 1124 Email: tim@ripe.net 1126 Oleg Muravskiy 1127 RIPE NCC 1129 Email: oleg@ripe.net 1131 Bryan Weber 1132 Cobenian 1134 Email: bryan@cobenian.com 1136 Rob Austein 1137 Dragon Research Labs 1139 Email: sra@hactrn.net