idnits 2.17.1 draft-ietf-sidr-delta-protocol-07.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 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 lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (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 2629 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 816, but not defined == Outdated reference: A later version (-12) exists of draft-ietf-sidr-publication-10 ** 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: 8 errors (**), 0 flaws (~~), 5 warnings (==), 5 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-07 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 protocol, thus enabling the RP to keep its state in sync with the 24 repository using a secure transport channel. This document updates 25 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 August 14, 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 . . . . . . . . . . . . . 9 73 3.4.4. Polling the Update Notification File . . . . . . . . 9 74 3.4.5. Considerations Regarding Operational Failures in RRDP 10 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 4.1. Updates to RFC6480 . . . . . . . . . . . . . . . . . . . 17 82 4.1.1. Update in Section 4.3, Access Protocols . . . . . . . 17 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 . . . . . . . . . . . . . . . . . . . 18 86 4.2.1. Update in Section 3, Resource Certificate Publication 87 Repository Considerations . . . . . . . . . . . . . . 18 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 . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . 20 98 5.3. HTTPS considerations . . . . . . . . . . . . . . . . . . 20 99 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 100 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 101 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 102 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 103 9.1. Normative References . . . . . . . . . . . . . . . . . . 22 104 9.2. Informative References . . . . . . . . . . . . . . . . . 24 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 107 1. Requirements notation 109 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", 110 "RECOMMENDED", "NOT RECOMMENDED", and "MAY" in this document are to 111 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 In order to facilitate transition to this new protocol, this document 148 updates the texts of [RFC6480], [RFC6481], and [RFC7730], removing 149 the dependency on [rsync] as the only mandatory RPKI repository 150 distribution mechanism, and allowing use of a non-rsync URI in a 151 Trust Anchor Locator file. 153 3. RPKI Repository Delta Protocol Implementation 155 3.1. Informal Overview 157 Certification Authorities (CA) in the RPKI use a repository server to 158 publish their RPKI products, such as manifests, CRLs, signed 159 certificates and RPKI signed objects. This repository server may be 160 remote, or embedded in the CA engine itself. Certificates in the 161 RPKI that use a repository server that supports this delta protocol 162 include a special Subject Information Access (SIA) pointer referring 163 to a notification file. 165 The notification file includes a globally unique session_id in the 166 form of a version 4 UUID ([RFC4122]), and serial number that can be 167 used by the Relying Party (RP) to determine if it and the repository 168 are synchronised. Furthermore it includes a link to the most recent 169 complete snapshot of current objects that are published by the 170 repository server, and a list of links to delta files, for each 171 revision starting at a point determined by the repository server, up 172 to the current revision of the repository. 174 A RP that learns about a notification file location for the first 175 time can download it, and then proceed to download the latest 176 snapshot file, and thus create a local copy of the repository that is 177 in sync with the repository server. The RP records the location of 178 this notification file, the session_id and current serial number. 180 RPs are encouraged to re-fetch this notification file at regular 181 intervals, but not more often than once per minute. After re- 182 fetching the notification file, the RP may find that there are one or 183 more delta files available that allow it to synchronise its local 184 repository with the current state of the repository server. If no 185 contiguous chain of deltas from RP's serial to the latest repository 186 serial is available, or if the session_id has changed, the RP 187 performs a full resynchronisation instead. 189 As soon as the RP fetches new content in this way it could start a 190 validation process. An example of a reason why a RP may not do this 191 immediately is because it has learned of more than one notification 192 location and it prefers to complete all its updates before 193 validating. 195 The repository server could use caching infrastructure to reduce its 196 load, particularly because snapshots and deltas for any given 197 session_id and serial number contain an immutable record of the state 198 of the repository server at a certain point in time. For this reason 199 these files can be cached indefinitely. Notification files are 200 polled by RPs to discover if updates exist, and for this reason 201 notification files may not be cached for longer than one minute. 203 3.2. Certificate Authority Use 205 Certificate Authorities that use this delta protocol MUST include an 206 instance of an SIA AccessDescription extension in resource 207 certificates they produce, in addition to the ones defined in 208 [RFC6487], 210 AccessDescription ::= SEQUENCE { 211 accessMethod OBJECT IDENTIFIER, 212 accessLocation GeneralName } 214 This extension MUST use an accessMethod of id-ad-rpkiNotify, see 215 Section 7: 217 id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 218 dod(6) internet(1) security(5) mechanisms(5) pkix(7) } 220 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 222 id-ad-rpkiNotify OBJECT IDENTIFIER ::= { id-ad 13 } 224 The accessLocation MUST be an HTTPS URI as defined in [RFC2818], that 225 will point to the update notification file for the repository server 226 that publishes the products of this CA certificate. 228 3.3. Repository Server Use 230 3.3.1. Initialisation 232 When the repository server initialises it performs the following 233 actions: 235 o The server MUST generate a new random version 4 UUID to be used as 236 the session_id 238 o The server MUST then generate a snapshot file for serial number 239 ONE for this new session that includes all currently known 240 published objects that the repository server is responsible for. 241 Note that this snapshot file may contain zero publish elements at 242 this point if no objects have been submitted for publication yet. 244 o This snapshot file MUST be made available at a URL that is unique 245 to this session_id and serial number, so that it can be cached 246 indefinitely. The format and caching concerns for snapshot files 247 are explained in more detail in Section 3.5.2. 249 o After the snapshot file has been published the repository server 250 MUST publish a new notification file that contains the new 251 session_id, has serial number ONE, has one reference to the 252 snapshot file that was just published, and that contains no delta 253 references. The format and caching concerns for update 254 notification files are explained in more detail in Section 3.5.1. 256 3.3.2. Publishing Updates 258 Whenever the repository server receives updates from a CA it MUST 259 generate new snapshot and delta files within one minute. If a 260 publication server services a large number of CAs it MAY choose to 261 combine updates from multiple CAs. If a publication server combines 262 updates in this way, it MUST ensure that publication never postponed 263 for longer than one minute for any of the CAs involved. 265 Updates are processed as follows: 267 o The new repository serial number MUST be one greater than the 268 current repository serial number. 270 o A new delta file MUST be generated for this new serial. This 271 delta file MUST include all new, replaced and withdrawn objects 272 for multiple CAs if applicable, as a single change set. 274 o This delta file MUST be made available at a URL that is unique to 275 the current session_id and serial number, so that it can be cached 276 indefinitely. 278 o The format and caching concerns for delta files are explained in 279 more detail in Section 3.5.3. 281 o The repository server MUST also generate a new snapshot file for 282 this new serial. This file MUST contain all "publish" elements 283 for all current objects. 285 o The snapshot file MUST be made available at a URL that is unique 286 to this session and new serial, so that it can be cached 287 indefinitely. 289 o The format and caching concerns for snapshot files are explained 290 in more detail in Section 3.5.2. 292 o Any older delta files that, when combined with all more recent 293 delta files, will result in total size of deltas exceeding the 294 size of the snapshot, MUST be excluded to avoid that RPs download 295 more data than necessary. 297 o A new notification file MUST now be created by the repository 298 server. This new notification file MUST include a reference to 299 the new snapshot file, and all delta files selected in the 300 previous steps. 302 o The format and caching concerns for update notification files are 303 explained in more detail in Section 3.5.1. 305 If the repository server is not capable of performing the above for 306 some reason, then it MUST perform a full re-initialisation, as 307 explained above in Section 3.3.1. 309 3.4. Relying Party Use 311 3.4.1. Processing the Update Notification File 313 When a Relying Party (RP) performs RPKI validation and learns about a 314 valid certificate with an SIA entry for the RRDP protocol, it SHOULD 315 use this protocol as follows. 317 The RP MUST download the update notification file, unless an update 318 notification file was already downloaded and processed from the same 319 location in this validation run, or because a polling strategy was 320 used (see Section 3.4.4). 322 It is RECOMMENDED that RP uses a "User-Agent" header explained in 323 section 5.5.3. of [RFC7231] to identify the name and version of the 324 RP software used. It is useful to track capabilities of Relying 325 Parties in the event of changes to the RPKI standards. 327 When the RP downloads an update notification file it MUST verify the 328 file format and validation steps described in section 329 Section 3.5.1.3. If this verification fails, the file MUST be 330 rejected and RRDP cannot be used. See Section 3.4.5 for 331 considerations. 333 The RP MUST verify whether the session_id in this update notification 334 file matches the last known session_id for this update notification 335 file location. If the session_id matches the last known session_id, 336 then an RP MAY download and process missing delta files as described 337 in section Section 3.4.2, provided that all delta files for serial 338 numbers between the last processed serial number and the current 339 serial number in the notification file can be processed this way. 341 If the session_id was not previously known, or if delta files could 342 not be used, then the RP MUST update its last known session_id to 343 this session_id and download and process snapshot file on the update 344 notification file as described in section Section 3.4.3. 346 3.4.2. Processing Delta Files 348 If an update notification file contains a contiguous chain of links 349 to delta files from the last processed serial number to the current 350 serial number, then RPs MUST attempt to download and process all 351 delta files in order of serial number as follows. 353 When the RP downloads a delta file it MUST verify the file format and 354 perform validation steps described in Section 3.5.3.3. If this 355 verification fails, the file MUST be rejected. 357 Furthermore the RP MUST verify that the hash of the contents of this 358 file matches the hash on the update notification file that referenced 359 it. In case of a mismatch of this hash, the file MUST be rejected. 361 If an RP retrieved a delta file that is valid according to the above 362 criteria, it performs the following actions: 364 The RP MUST verify that the session_id matches the session_id of 365 the notification file. If the session_id values do not match the 366 file MUST be rejected. 368 The RP MUST verify that the serial number of this delta file is 369 exactly one greater than the last processed serial number for this 370 session_id, and if not this file MUST be rejected. 372 The RP SHOULD add all publish elements to a local storage and 373 update its last processed serial number to the serial number of 374 this delta file. 376 The RP SHOULD NOT remove objects from its local storage solely 377 because it encounters a "withdraw" element, because this would 378 enable a publication server to withdraw any object without the 379 signing Certificate Authority consent. The RP could use 380 additional strategies to determine if an object is still relevant 381 for validation before removing it from its local storage. In 382 particular objects should not be removed if they are included in a 383 current validated manifest. 385 If any delta file is rejected RPs MUST process the current Snapshot 386 File instead, as described in Section 3.4.3. 388 3.4.3. Processing a Snapshot File 390 Snapshot Files MUST only be used if Delta Files are unavailable, or 391 were rejected. As is ensured, if the process described in 392 Section 3.4.1 is followed. 394 When the RP downloads a snapshot file it MUST verify the file format 395 and validation steps described in Section 3.5.2.3. If this 396 verification fails, the file MUST be rejected. 398 Furthermore the RP MUST verify that the hash of the contents of this 399 file matches the hash on the update notification file that referenced 400 it. In case of a mismatch of this hash, the file MUST be rejected. 402 If an RP retrieved a snapshot file that is valid according to the 403 above criteria, it performs the following actions: 405 The RP MUST verify that the session_id matches the session_id of 406 the notification file. If the session_id values do not match the 407 file MUST be rejected. 409 The RP MUST verify that the serial number of this snapshot file is 410 greater than the last processed serial number for this session_id. 411 If this fails the file MUST be rejected. 413 The RP SHOULD then add all publish elements to a local storage and 414 update its last processed serial number to the serial number of 415 this snapshot file. 417 If a Snapshot File is rejected that means that RRDP cannot be used. 418 See Section 3.4.5 for considerations. 420 3.4.4. Polling the Update Notification File 422 Once a Relying Party has learned about the location, session_id and 423 last processed serial number of repository that uses the RRDP 424 protocol, the RP MAY start polling the repository server for updates. 425 However the RP MUST NOT poll for updates more often than once every 1 426 minute, and in order to reduce data usage RPs MUST use the "If- 427 Modified-Since" header explained in section 3.3 of [RFC7232] in 428 requests. 430 If an RP finds that updates are available it SHOULD download and 431 process the file as described in Section 3.4.1, and initiate a new 432 RPKI object validation process. However, a detailed description of 433 the RPKI object validation process itself is out of scope of this 434 document. 436 3.4.5. Considerations Regarding Operational Failures in RRDP 438 If an RP experiences any issues with retrieving or processing any of 439 the files used in this protocol, it will be unable to retrieve new 440 RPKI data from the affected publication server. 442 Relying Parties could attempt to use alternative repository access 443 mechanisms, if they are available, according to the accessMethod 444 element value(s) specified in the SIA of the associated certificate 445 (see Section 4.8.8 of [RFC6487]). 447 Furthermore Relying Parties may wish to employ re-try strategies 448 while fetching RRDP files. Relying Parties are also advised to keep 449 old objects in their local cache so that validation can be done using 450 old objects. 452 It is also recommendable that re-validation and retrieval is 453 performed pro-actively before manifests or CRLs go stale, or 454 certificates expire, to ensure that problems on the side of the RP 455 can be identified and resolved before they cause major concerns. 457 3.5. File Definitions 459 3.5.1. Update Notification File 461 3.5.1.1. Purpose 463 The update notification file is used by RPs to discover whether any 464 changes exist between the state of the repository and the RP's cache. 465 It describes the location of the files containing the snapshot and 466 incremental deltas which can be used by the RP to synchronise with 467 the repository. 469 3.5.1.2. Cache Concerns 471 A repository server MAY use caching infrastructure to cache the 472 notification file and reduce the load of HTTPS requests. However, 473 since this file is used by RPs to determine whether any updates are 474 available the repository server SHOULD ensure that this file is not 475 cached for longer than 1 minute. An exception to this rule is that 476 it is better to serve a stale notification file, than no notification 477 file. 479 How this is achieved exactly depends on the caching infrastructure 480 used. In general a repository server may find certain HTTP headers 481 to be useful, such as: "Cache-Control: max-age=60" (see Section 5.2 482 of [RFC7234]). Another approach can be to have the repository server 483 push out new versions of the notification file to the caching 484 infrastructure when appropriate. 486 In case of a high load on a repository server or its distribution 487 network, the Cache-Control HTTP header, or a similar mechanism, MAY 488 be used to suggest an optimal (for the repository server) poll 489 interval for Relying Parties. However, setting it to an interval 490 longer than 1 hour is NOT RECOMMENDED. Relying parties SHOULD align 491 the suggested interval with their operational practices and the 492 expected update frequency of RPKI repository data, and MAY discard 493 suggested value. 495 3.5.1.3. File Format and Validation 497 Example notification file: 499 503 504 505 506 508 Note: URIs and hash values in this example are shortened because of 509 formatting. 511 The following validation rules MUST be observed when creating or 512 parsing notification files: 514 o A RP MUST reject any update notification file that is not well- 515 formed, or which does not conform to the RELAX NG schema outlined 516 in Section 3.5.4 of this document. 518 o The XML namespace MUST be http://www.ripe.net/rpki/rrdp 520 o The encoding MUST be US-ASCII 522 o The version attribute in the notification root element MUST be 1 524 o The session_id attribute MUST be a random version 4 UUID 525 ([RFC4122]), unique to this session 527 o The serial attribute MUST be an unbounded, unsigned positive 528 integer in decimal format indicating the current version of the 529 repository. 531 o The notification file MUST contain exactly one 'snapshot' element 532 for the current repository version. 534 o If delta elements are included they MUST form a contiguous 535 sequence of serial numbers starting at a revision determined by 536 the repository server, up to the serial number mentioned in the 537 notification element. Note that the elements may not be ordered. 539 o The hash attribute in snapshot and delta elements MUST be the 540 hexadecimal encoding of the SHA-256 hash of the referenced file. 541 The RP MUST verify this hash when the file is retrieved and reject 542 the file if the hash does not match. 544 3.5.2. Snapshot File 546 3.5.2.1. Purpose 548 A snapshot is intended to reflect the complete and current contents 549 of the repository for a specific session and version. Therefore it 550 MUST contain all objects from the repository current as of the time 551 of the publication. 553 3.5.2.2. Cache Concerns 555 A snapshot reflects the content of the repository at a specific point 556 in time, and for that reason can be considered immutable data. 557 Snapshot files MUST be published at a URL that is unique to the 558 specific session and serial. 560 Because these files never change, they MAY be cached indefinitely. 561 However, in order to prevent that these files use a lot of space in 562 caching infrastructure it is RECOMMENDED that a limited interval is 563 used in the order of hours or days. 565 To avoid race conditions where an RP downloads a notification file 566 moments before it's updated, Repository Servers SHOULD retain old 567 snapshot files for at least 5 minutes after a new notification file 568 is published. 570 3.5.2.3. File Format and Validation 572 Example snapshot file: 574 578 579 ZXhhbXBsZTE= 580 581 582 ZXhhbXBsZTI= 583 584 585 ZXhhbXBsZTM= 586 587 589 The following rules MUST be observed when creating or parsing 590 snapshot files: 592 o A RP MUST reject any snapshot file that is not well-formed, or 593 which does not conform to the RELAX NG schema outlined in 594 Section 3.5.4 of this document. 596 o The XML namespace MUST be http://www.ripe.net/rpki/rrdp. 598 o The encoding MUST be US-ASCII. 600 o The version attribute in the notification root element MUST be 1 602 o The session_id attribute MUST match the expected session_id in the 603 reference in the notification file. 605 o The serial attribute MUST match the expected serial in the 606 reference in the notification file. 608 o Note that the publish element is similar to the publish element 609 defined in the publication protocol [I-D.ietf-sidr-publication]. 610 However, the "tag" attribute is not used here because it is not 611 relevant to relying parties. The "hash" attribute is not used 612 here because this file represents a complete current state of the 613 repository, and therefore it is not relevant to know which 614 existing RPKI object (if any) is updated. 616 3.5.3. Delta File 617 3.5.3.1. Purpose 619 An incremental delta file contains all changes for exactly one serial 620 increment of the repository server. In other words a single delta 621 will typically include all the new objects, updated objects and 622 withdrawn objects that a Certification Authority sent to the 623 repository server. In its simplest form the update could concern 624 only a single object, but it is RECOMMENDED that CAs send all changes 625 for one of their key pairs (updated objects as well as a new manifest 626 and CRL) as one atomic update message. 628 3.5.3.2. Cache Concerns 630 Deltas reflect the difference between two consecutive versions of a 631 repository for a given session. For that reason deltas can be 632 considered immutable data. Delta files MUST be published at a URL 633 that is unique to the specific session and serial. 635 Because these files never change, they MAY be cached indefinitely. 636 However, in order to prevent these files from using a lot of space in 637 caching infrastructure it is RECOMMENDED that a limited interval is 638 used in the order of hours or days. 640 To avoid race conditions where an RP downloads a notification file 641 moments before it's updated, Repository Servers SHOULD retain old 642 delta files for at least 5 minutes after they are no longer included 643 in the latest notification file. 645 3.5.3.3. File Format and Validation 647 Example delta file: 649 653 655 ZXhhbXBsZTQ= 656 657 659 ZXhhbXBsZTU= 660 661 663 665 Note that a formal RELAX NG specification of this file format is 666 included later in this document. A RP MUST NOT process any delta 667 file that is incomplete or not well-formed. 669 The following validation rules MUST be observed when creating or 670 parsing delta files: 672 o A RP MUST reject any delta file that is not well-formed, or which 673 does not conform to the RELAX NG schema outlined in Section 3.5.4 674 of this document. 676 o The XML namespace MUST be http://www.ripe.net/rpki/rrdp. 678 o The encoding MUST be US-ASCII. 680 o The version attribute in the delta root element MUST be 1 682 o The session_id attribute MUST be a random version 4 UUID unique to 683 this session 685 o The session_id attribute MUST match the expected session_id in the 686 reference in the notification file. 688 o The serial attribute MUST match the expected serial in the 689 reference in the notification file. 691 o Note that the publish element is similar to the publish element 692 defined in the publication protocol [I-D.ietf-sidr-publication]. 693 However, the "tag" attribute is not used here because it is not 694 relevant to relying parties. 696 3.5.4. XML Schema 698 The following is a RELAX NG compact form schema describing version 1 699 of this protocol. 701 # 702 # RelaxNG schema for RPKI Repository Delta Protocol (RRDP). 703 # 705 default namespace = "http://www.ripe.net/rpki/rrdp" 707 version = xsd:positiveInteger { maxInclusive="1" } 708 serial = xsd:positiveInteger 709 uri = xsd:anyURI 710 uuid = xsd:string { pattern = "[\-0-9a-fA-F]+" } 711 hash = xsd:string { pattern = "[0-9a-fA-F]+" } 712 base64 = xsd:base64Binary 713 # Notification file: lists current snapshots and deltas 715 start |= element notification { 716 attribute version { version }, 717 attribute session_id { uuid }, 718 attribute serial { serial }, 719 element snapshot { 720 attribute uri { uri }, 721 attribute hash { hash } 722 }, 723 element delta { 724 attribute serial { serial }, 725 attribute uri { uri }, 726 attribute hash { hash } 727 }* 728 } 730 # Snapshot segment: think DNS AXFR. 732 start |= element snapshot { 733 attribute version { version }, 734 attribute session_id { uuid }, 735 attribute serial { serial }, 736 element publish { 737 attribute uri { uri }, 738 base64 739 }* 740 } 742 # Delta segment: think DNS IXFR. 744 start |= element delta { 745 attribute version { version }, 746 attribute session_id { uuid }, 747 attribute serial { serial }, 748 delta_element+ 749 } 751 delta_element |= element publish { 752 attribute uri { uri }, 753 attribute hash { hash }?, 754 base64 755 } 757 delta_element |= element withdraw { 758 attribute uri { uri }, 759 attribute hash { hash } 760 } 761 # Local Variables: 762 # indent-tabs-mode: nil 763 # comment-start: "# " 764 # comment-start-skip: "#[ \t]*" 765 # End: 767 4. Updates 769 This section provides updates to several paragraphs in [RFC6480], 770 [RFC6481], and [RFC7730]. For clarity, the original text and the 771 replacement text are shown. 773 4.1. Updates to RFC6480 775 4.1.1. Update in Section 4.3, Access Protocols 777 OLD: 779 To ensure all relying parties are able to acquire all RPKI signed 780 objects, all publication points MUST be accessible via rsync (see 781 [RFC5781] and [RSYNC]), although other download protocols MAY also 782 be supported. A repository publication point may provide 783 update/change/delete functionality via (set of) access protocols 784 that it desires, provided that the supported protocols are clearly 785 communicated to all certification authorities publishing data at a 786 given publication point. 788 NEW: 790 To ensure all relying parties are able to acquire all RPKI signed 791 objects, all publication points MUST be accessible using retrieval 792 mechanism(s) consistent with the accessMethod element value(s). 793 Multiple retrieval mechanisms MAY be supported at the repository 794 operator's discretion. A repository publication point may provide 795 update/change/delete functionality via (set of) access protocols 796 that it desires, provided that the supported protocols are clearly 797 communicated to all certification authorities publishing data at a 798 given publication point. 800 4.1.2. Update in Section 11.1, Normative References 802 Remove the reference to RFC5781, "The rsync URI Scheme". 804 4.1.3. Update in Section 11.2, Informative References 806 Remove the reference to rsync, "rsync web pages". 808 4.2. Updates to RFC6481 810 4.2.1. Update in Section 3, Resource Certificate Publication Repository 811 Considerations 813 OLD: 815 The publication repository MUST be available using rsync [RFC5781] 816 [RSYNC]. Support of additional retrieval mechanisms is the choice 817 of the repository operator. The supported retrieval mechanisms 818 MUST be consistent with the accessMethod element value(s) 819 specified in the SIA of the associated CA or EE certificate. 821 NEW: 823 The publication repository MUST be available using retrieval 824 mechanism(s) consistent with the accessMethod element value(s) 825 specified in the SIA of the associated CA or EE certificate. 826 Support of multiple retrieval mechanisms is the choice of the 827 repository operator. 829 4.2.2. Update in Section 9.1, Normative References 831 Remove the reference to RFC5781, "The rsync URI Scheme". 833 4.2.3. Update in Section 9.2, Informative References 835 Remove the reference to rsync, "rsync web pages". 837 4.3. Updates to RFC7730 839 4.3.1. Update in Section 2.1, Trust Anchor Locator Format 841 OLD: 843 where the URI section is comprised of one of more of the ordered 844 sequence of: 846 1.1) an rsync URI [RFC5781], 848 1.2) a or line break. 850 NEW: 852 where the URI section is comprised of one of more of the ordered 853 sequence of: 855 1.1) a URI [RFC3986], 856 1.2) a or line break. 858 4.3.2. Update in Section 2.2, TAL and Trust Anchor Certificate 859 Considerations 861 OLD: 863 Each rsync URI in the TAL MUST reference a single object. It MUST 864 NOT reference a directory or any other form of collection of 865 objects. 867 ... 869 Where the TAL contains two or more rsync URIs, then the same self- 870 signed CA certificate MUST be found at each referenced location. 872 NEW: 874 Each URI in the TAL MUST reference a single object. It MUST NOT 875 reference a directory or any other form of collection of objects. 877 ... 879 Where the TAL contains two or more URIs, then the same self-signed 880 CA certificate MUST be found at each referenced location. 882 4.3.3. Update in Section 5.1, Normative References 884 Remove the reference to RFC5781, "The rsync URI Scheme". 886 Add a reference to RFC3986, "Uniform Resource Identifier (URI): 887 Generic Syntax". 889 5. Operational Considerations 891 5.1. Compatibility with previous standards 893 This protocol has been designed to replace rsync as a distribution 894 mechanism of an RPKI repository. However, it is also designed to co- 895 exist with existing implementations based on rsync, to enable smooth 896 transition from one distribution mechanism to another. 898 For every repository object listed in the snapshot and delta files 899 both the hash of the object's content and the rsync URI [RFC5781] of 900 its location in the repository are listed. This makes it possible to 901 distribute the same RPKI repository, represented by a set of files on 902 a filesystem, using both rsync and RRDP. It also enables Relying 903 Parties tools to query, combine, and consequently validate objects 904 from repositories of different types. (For an example of such 905 implementation see [I-D.ietf-sidrops-rpki-tree-validation].) 907 5.2. Distribution considerations 909 One of the design goals of RRDP was to minimise load on a repository 910 server while serving clients. To achieve this, neither the content, 911 nor the URLs of the snapshot and delta files are modified after they 912 have been published in the notification file. This allows their 913 effective distribution, either by a single HTTP server, or using a 914 Content Distribution Network (CDN). 916 The RECOMMENDED way for RPs to keep up with the repository updates is 917 to poll the Update Notification File for changes. The content of 918 that file is updated with every new serial version of a repository 919 (while its URL remains stable). To effectively implement 920 distribution of the notification file, an "If-Modified-Since" HTTP 921 request header is required to be present in all requests for 922 notification file (see Section 3.4.4.) Therefore it is RECOMMENDED 923 that RP tools implement a mechanism to keep track of a previous 924 successful fetch of a notification file. 926 Implementations of RRDP should also take care of not producing new 927 versions of the repository (and subsequently, new Notification, 928 Snapshot and Delta files) too often. Usually the maintenance of the 929 RPKI repository includes regular updates of manifest and CRL objects, 930 performed on a schedule. This often results in bursts of repository 931 updates during a short period of time. Since the RPs are required to 932 poll for the Update Notification File not more often than once per 933 minute (Section 3.4.4), it is not practical to generate new serial 934 versions of the repository much more often than 1 per minute. It is 935 allowed to combine multiple updates, possibly from different CAs, 936 into a new serial repository version (Section 3.3.2). This will 937 significantly shorten the size of the Update Notification File and 938 total amount of data distributed to all RPs. 940 5.3. HTTPS considerations 942 It is RECOMMENDED that Relying Parties and Publication Servers follow 943 the Best Current Practices outlined in [RFC7525] on the use of HTTP 944 over TLS (HTTPS) [RFC2818]. 946 Note that a Man-in-the-Middle (MITM) cannot produce validly signed 947 RPKI data, but they can perform withhold or replay attacks targeting 948 an RP, and keep the RP from learning about changes in the RPKI. 949 Because of this RPs SHOULD do TLS certificate and host name 950 validation when they fetch from an RRDP Publication Server. 952 RP tools SHOULD log any TLS certificate or host name validation 953 issues they find, so that an operator can investigate the cause. 954 However, such validation issues are often due to configuration 955 errors, or a lack of a common TLS trust anchor. In these cases it is 956 better if the RP retrieves the signed RPKI data regardless, and 957 performs validation on it. Therefore RP MUST continue to retrieve 958 the data in case of errors. The RP MAY choose to log encountered 959 issues only when fetching the notification update file, but not when 960 it subsequently fetches snapshot or delta files from the same host. 961 Furthermore the RP MAY provide a way for operators to accept 962 untrusted connections for a given host, after the cause has been 963 identified. 965 6. Security Considerations 967 RRDP deals exclusively with transfer of RPKI objects from a 968 repository server to a relying party. The trust relation between a 969 CA and its repository server is out of scope for this document. 970 However, it should be noted that from a relying party point of view 971 all RPKI objects (certificates, CRLs, and CMS-wrapped objects) are 972 already covered by object security mechanisms including signed 973 manifests. This allows validation of these objects even though the 974 repository server itself is not trusted. This document makes no 975 change to RPKI validation procedures per se. 977 The original RPKI transport protocol is rsync, which offers no 978 channel security mechanism. RRDP replaces the use of rsync by HTTPS; 979 while the channel security mechanism underlying RRDP (HTTPS) is not a 980 cure-all, it does make some forms of denial of service attack more 981 difficult for the attacker. HTTPS issues are discussed in more 982 detail in Section 5.3. 984 Supporting both RRDP and rsync necessarily increases the number of 985 opportunities for a malicious RPKI CA to perform denial of service 986 attacks on relying parties, by expanding the number of URIs which the 987 RP may need to contact in order to complete a validation run. 988 However, other than the relative cost of HTTPS versus rsync, adding 989 RRDP to the mix does not change this picture significantly: with 990 either RRDP or rsync a malicious CA can supply an effectively 991 infinite series of URIs for the RP to follow. The only real solution 992 to this is for the RP to apply some kind of bound to the amount of 993 work it is willing to do. Note also that the attacker in this 994 scenario must be an RPKI CA, since otherwise the normal RPKI object 995 security checks would reject the malicious URIs. 997 Processing costs for objects retrieved using RRDP may be somewhat 998 different from the same objects retrieved using rsync: because RRDP 999 treats an entire set of changes as a unit (one "delta"), it may not 1000 be practical to start processing any of the objects in the delta 1001 until the entire delta has been received. With rsync, by contrast, 1002 incremental processing may be easy, but the overall cost of transfer 1003 may be higher, as may be the number of corner cases in which the RP 1004 retrieves some but not all of the updated objects. Overall, RRDP's 1005 behavior is closer to a proper transactional system, which (probably) 1006 leads to an overall reliability increase. 1008 RRDP is designed to scale much better than rsync. In particular, 1009 RRDP is designed to allow use of HTTPS caching infrastructure to 1010 reduce load on primary publication servers and increase resilience 1011 against denial of service attacks on the RPKI publication service. 1013 7. IANA Considerations 1015 IANA is requested to update the reference for id-ad-rpkiNotify to 1016 this document in the PKIX Access Descriptor registry 1017 [IANA-AD-NUMBERS]. 1019 8. Acknowledgements 1021 The authors would like to thank David Mandelberg for reviewing this 1022 document. 1024 9. References 1026 9.1. Normative References 1028 [I-D.ietf-sidr-publication] 1029 Weiler, S., Sonalker, A., and R. Austein, "A Publication 1030 Protocol for the Resource Public Key Infrastructure 1031 (RPKI)", draft-ietf-sidr-publication-10 (work in 1032 progress), January 2017. 1034 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1035 Requirement Levels", BCP 14, RFC 2119, 1036 DOI 10.17487/RFC2119, March 1997, 1037 . 1039 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 1040 DOI 10.17487/RFC2818, May 2000, 1041 . 1043 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1044 Resource Identifier (URI): Generic Syntax", STD 66, 1045 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1046 . 1048 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1049 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1050 DOI 10.17487/RFC4122, July 2005, 1051 . 1053 [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI 1054 Scheme", RFC 5781, DOI 10.17487/RFC5781, February 2010, 1055 . 1057 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 1058 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 1059 February 2012, . 1061 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 1062 Resource Certificate Repository Structure", RFC 6481, 1063 DOI 10.17487/RFC6481, February 2012, 1064 . 1066 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 1067 X.509 PKIX Resource Certificates", RFC 6487, 1068 DOI 10.17487/RFC6487, February 2012, 1069 . 1071 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1072 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1073 DOI 10.17487/RFC7231, June 2014, 1074 . 1076 [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1077 Protocol (HTTP/1.1): Conditional Requests", RFC 7232, 1078 DOI 10.17487/RFC7232, June 2014, 1079 . 1081 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 1082 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 1083 RFC 7234, DOI 10.17487/RFC7234, June 2014, 1084 . 1086 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1087 "Recommendations for Secure Use of Transport Layer 1088 Security (TLS) and Datagram Transport Layer Security 1089 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1090 2015, . 1092 [RFC7730] Huston, G., Weiler, S., Michaelson, G., and S. Kent, 1093 "Resource Public Key Infrastructure (RPKI) Trust Anchor 1094 Locator", RFC 7730, DOI 10.17487/RFC7730, January 2016, 1095 . 1097 9.2. Informative References 1099 [I-D.ietf-sidrops-rpki-tree-validation] 1100 Muravskiy, O. and T. Bruijnzeels, "RPKI Certificate Tree 1101 Validation by the RIPE NCC RPKI Validator", draft-ietf- 1102 sidrops-rpki-tree-validation-00 (work in progress), 1103 January 2017. 1105 [IANA-AD-NUMBERS] 1106 "SMI Security for PKIX Access Descriptor", 1107 . 1110 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 1111 "Manifests for the Resource Public Key Infrastructure 1112 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, 1113 . 1115 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object 1116 Template for the Resource Public Key Infrastructure 1117 (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, 1118 . 1120 [rsync] "Rsync home page", . 1122 Authors' Addresses 1124 Tim Bruijnzeels 1125 RIPE NCC 1127 Email: tim@ripe.net 1129 Oleg Muravskiy 1130 RIPE NCC 1132 Email: oleg@ripe.net 1134 Bryan Weber 1135 Cobenian 1137 Email: bryan@cobenian.com 1138 Rob Austein 1139 Dragon Research Labs 1141 Email: sra@hactrn.net