idnits 2.17.1 draft-ietf-sidr-delta-protocol-08.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 : ---------------------------------------------------------------------------- No issues found here. 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). -- The document date (March 13, 2017) is 2600 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) ** Downref: Normative reference to an Informational RFC: RFC 5781 ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHS' -- Obsolete informational reference (is this intentional?): RFC 6486 (Obsoleted by RFC 9286) Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Bruijnzeels 3 Internet-Draft O. Muravskiy 4 Intended status: Standards Track RIPE NCC 5 Expires: September 14, 2017 B. Weber 6 Cobenian 7 R. Austein 8 Dragon Research Labs 9 March 13, 2017 11 RPKI Repository Delta Protocol (RRDP) 12 draft-ietf-sidr-delta-protocol-08 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 retrieve the published information 20 from those repositories. This document specifies a new RPKI 21 Repository Delta Protocol (RRDP) for this purpose. RRDP was 22 specifically designed for scaling. It relies on a notification file 23 which lists the current snapshot and delta files that can be 24 retrieved using HTTP over TLS (HTTPS), and enables to use of CDNs or 25 other caching infrastructure for the retrieval of these files. 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 September 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 . . . . . . . . . . . . . . . . . . . . 2 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 . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . 10 74 3.4.5. Considerations Regarding Operational Failures in RRDP 10 75 3.5. File Definitions . . . . . . . . . . . . . . . . . . . . 11 76 3.5.1. Update Notification File . . . . . . . . . . . . . . 11 77 3.5.2. Snapshot File . . . . . . . . . . . . . . . . . . . . 13 78 3.5.3. Delta File . . . . . . . . . . . . . . . . . . . . . 14 79 3.5.4. XML Schema . . . . . . . . . . . . . . . . . . . . . 16 80 4. Operational Considerations . . . . . . . . . . . . . . . . . 17 81 4.1. Compatibility with previous standards . . . . . . . . . . 17 82 4.2. Distribution considerations . . . . . . . . . . . . . . . 18 83 4.3. HTTPS considerations . . . . . . . . . . . . . . . . . . 18 84 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 86 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 87 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 88 8.1. Normative References . . . . . . . . . . . . . . . . . . 21 89 8.2. Informative References . . . . . . . . . . . . . . . . . 22 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 92 1. Requirements notation 94 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", 95 "RECOMMENDED", "NOT RECOMMENDED", and "MAY" in this document are to 96 be interpreted as described in [RFC2119]. 98 2. Introduction 100 In the Resource Public Key Infrastructure (RPKI), Certificate 101 Authorities publish certificates [RFC6487], RPKI signed objects 102 [RFC6488], manifests [RFC6486], and CRLs to repositories. CAs may 103 have an embedded mechanism to publish to these repositories, or they 104 may use a separate Repository Server and publication protocol. RPKI 105 repositories are currently accessible using the [rsync] protocol, 106 allowing Relying Parties to synchronise a local copy of the RPKI 107 repository used for validation with the remote repositories 108 [RFC6481]. 110 [rsync] has proven valuable in the early deployment of RPKI, because 111 it allowed operators to gain experience without the need to invent a 112 custom protocol. However, operational experience has brought 113 concerns to light that we wish to address here: 115 o [rsync] is designed to limit the amount of data that needs to be 116 transferred between client and server. However the server needs 117 to spend significant resources in terms of CPU and memory for 118 every connection. This is a problem in an envisioned RPKI 119 deployment where thousands of Relying Parties query a small number 120 of central repositories, and it makes these repositories weak to 121 denial of service attacks. 123 o A secondary concern is the lack of supported rsync server and 124 client libraries. In practice all implementations have to make 125 system calls to an rsync binary. This is inefficient, introduces 126 fragility with regards to updates of this binary, makes it 127 difficult to catch and report problems to operators, and it 128 complicates software development and testing. 130 This document specifies an alternative repository access protocol 131 based on notification, snapshot and delta files that a Relying Party 132 can retrieve over the HTTPS protocol. This allows Relying Parties to 133 perform either a full (re-)synchronisation of their local copy of the 134 repository using snapshot files, or use delta files to keep their 135 local repository updated after initial synchronisation. We call this 136 the RPKI Repository Delta Protocol, or RRDP in short. 138 RRDP was designed to support scaling in RPKI's asymmetric deployment. 139 It is consistent (in terms of data structures) with the publication 140 protocol [I-D.ietf-sidr-publication] and treats publication events of 141 one or more repository objects as discrete events that can be 142 communicated to Relying Parties. This approach helps to minimize the 143 amount of data that traverses the network and thus helps minimize the 144 amount of time until repository convergence occurs. RRDP also 145 provides a standards based way to obtain consistent, point in time 146 views of a single repository, eliminating a number of consistency 147 related issues. Finally, this approach allows these discrete events 148 to be communicated as immutable files. This enables Repository 149 Servers to pre-calculate these files only once for all clients - thus 150 limiting the CPU and memory investments required, and enables the use 151 of caching infrastructure to reduce the load on a repository server 152 when a large number of Relying Parties are querying it. 154 This document allows the use of RRDP as an additional repository 155 distribution mechanism for RPKI. In time RRDP may replace [rsync] as 156 the only mandatory to implement repository distribution mechanism. 157 However this transition is outside of the scope of this document. 159 3. RPKI Repository Delta Protocol Implementation 161 3.1. Informal Overview 163 Certification Authorities in the RPKI use a repository server to 164 publish their RPKI products, such as manifests, CRLs, signed 165 certificates and RPKI signed objects. This repository server may be 166 remote, or embedded in the Certificate Authority engine itself. 167 Certificates in the RPKI that use a repository server that supports 168 RRDP include a special Subject Information Access (SIA) pointer 169 referring to a notification file. 171 The notification file includes a globally unique session_id in the 172 form of a version 4 UUID ([RFC4122]), and serial number that can be 173 used by the Relying Party to determine if it and the repository are 174 synchronised. Furthermore it includes a link to the most recent 175 complete snapshot of current objects that are published by the 176 repository server, and a list of links to delta files, for each 177 revision starting at a point determined by the repository server, up 178 to the current revision of the repository. 180 A Relying Party that learns about a notification file location for 181 the first time can download it, and then proceed to download the 182 latest snapshot file, and thus create a local copy of the repository 183 that is in sync with the repository server. The Relying Party 184 records the location of this notification file, the session_id and 185 current serial number. 187 Relying Parties are encouraged to re-fetch this notification file at 188 regular intervals, but not more often than once per minute. After 189 re-fetching the notification file, the Relying Party may find that 190 there are one or more delta files available that allow it to 191 synchronise its local repository with the current state of the 192 repository server. If no contiguous chain of deltas from the Relying 193 Party's serial to the latest repository serial is available, or if 194 the session_id has changed, the Relying Party performs a full 195 resynchronisation instead. 197 As soon as the Relying Party fetches new content in this way it could 198 start a validation process. An example of a reason why a Relying 199 Party may not choose to do this immediately is because it has learned 200 of more than one notification location and it prefers to complete all 201 its updates before validating. 203 The repository server could use caching infrastructure to reduce its 204 load, particularly because snapshots and deltas for any given 205 session_id and serial number contain an immutable record of the state 206 of the repository server at a certain point in time. For this reason 207 these files can be cached indefinitely. Notification files are 208 polled by Relying Parties to discover if updates exist, and for this 209 reason notification files may not be cached for longer than one 210 minute. 212 3.2. Certificate Authority Use 214 Certificate Authorities that use RRDP MUST include an instance of an 215 SIA AccessDescription extension in resource certificates they 216 produce, in addition to the ones defined in [RFC6487], 218 AccessDescription ::= SEQUENCE { 219 accessMethod OBJECT IDENTIFIER, 220 accessLocation GeneralName } 222 This extension MUST use an accessMethod of id-ad-rpkiNotify, see 223 Section 6: 225 id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 226 dod(6) internet(1) security(5) mechanisms(5) pkix(7) } 228 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 230 id-ad-rpkiNotify OBJECT IDENTIFIER ::= { id-ad 13 } 232 The accessLocation MUST be an HTTPS URI as defined in [RFC7230], that 233 will point to the update notification file for the repository server 234 that publishes the products of this Certificate Authority 235 certificate. 237 3.3. Repository Server Use 238 3.3.1. Initialisation 240 When the repository server initialises it performs the following 241 actions: 243 o The server MUST generate a new random version 4 UUID (see section 244 4.1.3 of [RFC4122]) to be used as the session_id 246 o The server MUST then generate a snapshot file for serial number 247 ONE for this new session that includes all currently known 248 published objects that the repository server is responsible for. 249 Note that this snapshot file may contain zero publish elements at 250 this point if no objects have been submitted for publication yet. 252 o This snapshot file MUST be made available at a URL that is unique 253 to this session_id and serial number, so that it can be cached 254 indefinitely. The format and caching concerns for snapshot files 255 are explained in more detail in Section 3.5.2. 257 o After the snapshot file has been published the repository server 258 MUST publish a new notification file that contains the new 259 session_id, has serial number ONE, has one reference to the 260 snapshot file that was just published, and that contains no delta 261 references. The format and caching concerns for update 262 notification files are explained in more detail in Section 3.5.1. 264 3.3.2. Publishing Updates 266 Whenever the repository server receives updates from a Certificate 267 Authority it MUST generate new snapshot and delta files within one 268 minute. If a Repository Server services a large number of 269 Certificate Authorities it MAY choose to combine updates from 270 multiple CAs. If a Repository Server combines updates in this way, 271 it MUST ensure that publication never postponed for longer than one 272 minute for any of the CAs involved. 274 Updates are processed as follows: 276 o The new repository serial number MUST be one greater than the 277 current repository serial number. 279 o A new delta file MUST be generated for this new serial. This 280 delta file MUST include all new, replaced and withdrawn objects 281 for multiple CAs if applicable, as a single change set. 283 o This delta file MUST be made available at a URL that is unique to 284 the current session_id and serial number, so that it can be cached 285 indefinitely. 287 o The format and caching concerns for delta files are explained in 288 more detail in Section 3.5.3. 290 o The repository server MUST also generate a new snapshot file for 291 this new serial. This file MUST contain all "publish" elements 292 for all current objects. 294 o The snapshot file MUST be made available at a URL that is unique 295 to this session and new serial, so that it can be cached 296 indefinitely. 298 o The format and caching concerns for snapshot files are explained 299 in more detail in Section 3.5.2. 301 o Any older delta files that, when combined with all more recent 302 delta files, will result in total size of deltas exceeding the 303 size of the snapshot, MUST be excluded to avoid that Relying 304 Parties download more data than necessary. 306 o A new notification file MUST now be created by the repository 307 server. This new notification file MUST include a reference to 308 the new snapshot file, and all delta files selected in the 309 previous steps. 311 o The format and caching concerns for update notification files are 312 explained in more detail in Section 3.5.1. 314 If the repository server is not capable of performing the above for 315 some reason, then it MUST perform a full re-initialisation, as 316 explained above in Section 3.3.1. 318 3.4. Relying Party Use 320 3.4.1. Processing the Update Notification File 322 When a Relying Party performs RPKI validation and learns about a 323 valid certificate with an SIA entry for the RRDP protocol, it SHOULD 324 use this protocol as follows. 326 The Relying Party MUST download the update notification file, unless 327 an update notification file was already downloaded and processed from 328 the same location in this validation run, or because a polling 329 strategy was used (see Section 3.4.4). 331 It is RECOMMENDED that Relying Party uses a "User-Agent" header 332 explained in section 5.5.3. of [RFC7231] to identify the name and 333 version of the Relying Party software used. It is useful to track 334 capabilities of Relying Parties in the event of changes to the RPKI 335 standards. 337 When the Relying Party downloads an update notification file it MUST 338 verify the file format and validation steps described in section 339 Section 3.5.1.3. If this verification fails, the file MUST be 340 rejected and RRDP cannot be used. See Section 3.4.5 for 341 considerations. 343 The Relying Party MUST verify whether the session_id matches the last 344 known session_id for this update notification file location. Note 345 that even though the session_id is a random UUID value, it alone MUST 346 NOT be used by a Relying Party as a unique identifier of a session, 347 but always together with the location of the notification file. The 348 reason for this is that a malicious server can use an existing 349 session_id from another Repository Server. 351 If the session_id matches the last known session_id, then a Relying 352 Party MAY download and process missing delta files as described in 353 Section 3.4.2, provided that all delta files for serial numbers 354 between the last processed serial number and the current serial 355 number in the notification file can be processed this way. 357 If the session_id matches the last known session_id, but delta files 358 were not used, then the Relying Party MUST download and process the 359 snapshot file on the update notification file as described in 360 Section 3.4.3. 362 If the session_id does not match the last known session_id, the 363 Relying Party MUST update its last known session_id to the value 364 specified in the downloaded notification file. The Relying Party 365 MUST then download and process the snapshot file specified in the 366 downloaded update notification file as described in Section 3.4.3. 368 3.4.2. Processing Delta Files 370 If an update notification file contains a contiguous chain of links 371 to delta files from the last processed serial number to the current 372 serial number, then Relying Parties MUST attempt to download and 373 process all delta files in order of serial number as follows. 375 When the Relying Party downloads a delta file it MUST verify the file 376 format and perform validation steps described in Section 3.5.3.3. If 377 this verification fails, the file MUST be rejected. 379 Furthermore the Relying Party MUST verify that the hash of the 380 contents of this file matches the hash on the update notification 381 file that referenced it. In case of a mismatch of this hash, the 382 file MUST be rejected. 384 If a Relying Party retrieved a delta file that is valid according to 385 the above criteria, it performs the following actions: 387 o The Relying Party MUST verify that the session_id matches the 388 session_id of the notification file. If the session_id values do 389 not match the file MUST be rejected. 391 o The Relying Party MUST verify that the serial number of this delta 392 file is exactly one greater than the last processed serial number 393 for this session_id, and if not this file MUST be rejected. 395 o The Relying Party SHOULD add all publish elements to a local 396 storage and update its last processed serial number to the serial 397 number of this delta file. 399 o When a Relying Party encounters a "withdraw" element, or a 400 "publish" element where an object is replaced, in a delta that it 401 retrieves from a Repository Server, it MUST verify that the object 402 to be withdrawn or replaced was retrieved from this same 403 Repository Server, before applying the appropriate action. 404 Failing to do so will leave the Relying Party vulnerable to 405 malicious Repository Servers instructing it to delete or change 406 arbitrary objects. 408 If any delta file is rejected Relying Parties MUST process the 409 current Snapshot File instead, as described in Section 3.4.3. 411 3.4.3. Processing a Snapshot File 413 Snapshot Files MUST only be used if Delta Files are unavailable, or 414 were rejected. As is ensured, if the process described in 415 Section 3.4.1 is followed. 417 When the Relying Party downloads a snapshot file it MUST verify the 418 file format and validation steps described in Section 3.5.2.3. If 419 this verification fails, the file MUST be rejected. 421 Furthermore the Relying Party MUST verify that the hash of the 422 contents of this file matches the hash on the update notification 423 file that referenced it. In case of a mismatch of this hash, the 424 file MUST be rejected. 426 If a Relying Party retrieved a snapshot file that is valid according 427 to the above criteria, it performs the following actions: 429 o The Relying Party MUST verify that the session_id matches the 430 session_id of the notification file. If the session_id values do 431 not match the file MUST be rejected. 433 o The Relying Party MUST verify that the serial number of this 434 snapshot file is greater than the last processed serial number for 435 this session_id. If this fails the file MUST be rejected. 437 o The Relying Party SHOULD then add all publish elements to a local 438 storage and update its last processed serial number to the serial 439 number of this snapshot file. 441 If a Snapshot File is rejected that means that RRDP cannot be used. 442 See Section 3.4.5 for considerations. 444 3.4.4. Polling the Update Notification File 446 Once a Relying Party has learned about the location, session_id and 447 last processed serial number of repository that uses the RRDP 448 protocol, the Relying Party MAY start polling the repository server 449 for updates. However the Relying Party MUST NOT poll for updates 450 more often than once every 1 minute, and in order to reduce data 451 usage Relying Parties MUST use the "If-Modified-Since" header 452 explained in section 3.3 of [RFC7232] in requests. 454 If a Relying Party finds that updates are available it SHOULD 455 download and process the file as described in Section 3.4.1, and 456 initiate a new RPKI object validation process. However, a detailed 457 description of the RPKI object validation process itself is out of 458 scope of this document. 460 3.4.5. Considerations Regarding Operational Failures in RRDP 462 If a Relying Party experiences any issues with retrieving or 463 processing any of the files used in this protocol, it will be unable 464 to retrieve new RPKI data from the affected Repository Server. 466 Relying Parties could attempt to use alternative repository access 467 mechanisms, if they are available, according to the accessMethod 468 element value(s) specified in the SIA of the associated certificate 469 (see Section 4.8.8 of [RFC6487]). 471 Furthermore Relying Parties may wish to employ re-try strategies 472 while fetching RRDP files. Relying Parties are also advised to keep 473 old objects in their local cache so that validation can be done using 474 old objects. 476 It is also recommendable that re-validation and retrieval is 477 performed pro-actively before manifests or CRLs go stale, or 478 certificates expire, to ensure that problems on the side of the 479 Relying Party can be identified and resolved before they cause major 480 concerns. 482 3.5. File Definitions 484 3.5.1. Update Notification File 486 3.5.1.1. Purpose 488 The update notification file is used by Relying Parties to discover 489 whether any changes exist between the state of the repository and the 490 Relying Party's cache. It describes the location of the files 491 containing the snapshot and incremental deltas which can be used by 492 the Relying Party to synchronise with the repository. 494 3.5.1.2. Cache Concerns 496 A repository server MAY use caching infrastructure to cache the 497 notification file and reduce the load of HTTPS requests. However, 498 since this file is used by Relying Parties to determine whether any 499 updates are available the repository server SHOULD ensure that this 500 file is not cached for longer than 1 minute. An exception to this 501 rule is that it is better to serve a stale notification file, than no 502 notification file. 504 How this is achieved exactly depends on the caching infrastructure 505 used. In general a repository server may find certain HTTP headers 506 to be useful, such as: "Cache-Control: max-age=60" (see Section 5.2 507 of [RFC7234]). Another approach can be to have the repository server 508 push out new versions of the notification file to the caching 509 infrastructure when appropriate. 511 In case of a high load on a repository server or its distribution 512 network, the Cache-Control HTTP header, or a similar mechanism, MAY 513 be used to suggest an optimal (for the repository server) poll 514 interval for Relying Parties. However, setting it to an interval 515 longer than 1 hour is NOT RECOMMENDED. Relying parties SHOULD align 516 the suggested interval with their operational practices and the 517 expected update frequency of RPKI repository data, and MAY discard 518 suggested value. 520 3.5.1.3. File Format and Validation 522 Example notification file: 524 528 529 530 531 533 Note: URIs and hash values in this example are shortened because of 534 formatting. 536 The following validation rules MUST be observed when creating or 537 parsing notification files: 539 o A Relying Party MUST reject any update notification file that is 540 not well-formed, or which does not conform to the RELAX NG schema 541 outlined in Section 3.5.4 of this document. 543 o The XML namespace MUST be http://www.ripe.net/rpki/rrdp 545 o The encoding MUST be US-ASCII 547 o The version attribute in the notification root element MUST be 1 549 o The session_id attribute MUST be a random version 4 UUID 550 ([RFC4122]), unique to this session 552 o The serial attribute MUST be an unbounded, unsigned positive 553 integer in decimal format indicating the current version of the 554 repository. 556 o The notification file MUST contain exactly one 'snapshot' element 557 for the current repository version. 559 o If delta elements are included they MUST form a contiguous 560 sequence of serial numbers starting at a revision determined by 561 the repository server, up to the serial number mentioned in the 562 notification element. Note that the elements may not be ordered. 564 o The hash attribute in snapshot and delta elements MUST be the 565 hexadecimal encoding of the SHA-256 [SHS] hash of the referenced 566 file. The Relying Party MUST verify this hash when the file is 567 retrieved and reject the file if the hash does not match. 569 3.5.2. Snapshot File 571 3.5.2.1. Purpose 573 A snapshot is intended to reflect the complete and current contents 574 of the repository for a specific session and version. Therefore it 575 MUST contain all objects from the repository current as of the time 576 of the publication. 578 3.5.2.2. Cache Concerns 580 A snapshot reflects the content of the repository at a specific point 581 in time, and for that reason can be considered immutable data. 582 Snapshot files MUST be published at a URL that is unique to the 583 specific session and serial. 585 Because these files never change, they MAY be cached indefinitely. 586 However, in order to prevent that these files use a lot of space in 587 caching infrastructure it is RECOMMENDED that a limited interval is 588 used in the order of hours or days. 590 To avoid race conditions where a Relying Party downloads a 591 notification file moments before it's updated, Repository Servers 592 SHOULD retain old snapshot files for at least 5 minutes after a new 593 notification file is published. 595 3.5.2.3. File Format and Validation 597 Example snapshot file: 599 603 604 ZXhhbXBsZTE= 605 606 607 ZXhhbXBsZTI= 608 609 610 ZXhhbXBsZTM= 611 612 614 The following rules MUST be observed when creating or parsing 615 snapshot files: 617 o A Relying Party MUST reject any snapshot file that is not well- 618 formed, or which does not conform to the RELAX NG schema outlined 619 in Section 3.5.4 of this document. 621 o The XML namespace MUST be http://www.ripe.net/rpki/rrdp. 623 o The encoding MUST be US-ASCII. 625 o The version attribute in the notification root element MUST be 1 627 o The session_id attribute MUST match the expected session_id in the 628 reference in the notification file. 630 o The serial attribute MUST match the expected serial in the 631 reference in the notification file. 633 o Note that the publish element is similar to the publish element 634 defined in the publication protocol [I-D.ietf-sidr-publication]. 635 However, the "tag" attribute is not used here because it is not 636 relevant to Relying Parties. The "hash" attribute is not used 637 here because this file represents a complete current state of the 638 repository, and therefore it is not relevant to know which 639 existing RPKI object (if any) is updated. 641 3.5.3. Delta File 643 3.5.3.1. Purpose 645 An incremental delta file contains all changes for exactly one serial 646 increment of the repository server. In other words a single delta 647 will typically include all the new objects, updated objects and 648 withdrawn objects that a Certification Authority sent to the 649 repository server. In its simplest form the update could concern 650 only a single object, but it is RECOMMENDED that CAs send all changes 651 for one of their key pairs (updated objects as well as a new manifest 652 and CRL) as one atomic update message. 654 3.5.3.2. Cache Concerns 656 Deltas reflect the difference between two consecutive versions of a 657 repository for a given session. For that reason deltas can be 658 considered immutable data. Delta files MUST be published at a URL 659 that is unique to the specific session and serial. 661 Because these files never change, they MAY be cached indefinitely. 662 However, in order to prevent these files from using a lot of space in 663 caching infrastructure it is RECOMMENDED that a limited interval is 664 used in the order of hours or days. 666 To avoid race conditions where a Relying Party downloads a 667 notification file moments before it's updated, Repository Servers 668 SHOULD retain old delta files for at least 5 minutes after they are 669 no longer included in the latest notification file. 671 3.5.3.3. File Format and Validation 673 Example delta file: 675 679 681 ZXhhbXBsZTQ= 682 683 685 ZXhhbXBsZTU= 686 687 689 691 Note that a formal RELAX NG specification of this file format is 692 included later in this document. A Relying Party MUST NOT process 693 any delta file that is incomplete or not well-formed. 695 The following validation rules MUST be observed when creating or 696 parsing delta files: 698 o A Relying Party MUST reject any delta file that is not well- 699 formed, or which does not conform to the RELAX NG schema outlined 700 in Section 3.5.4 of this document. 702 o The XML namespace MUST be http://www.ripe.net/rpki/rrdp. 704 o The encoding MUST be US-ASCII. 706 o The version attribute in the delta root element MUST be 1 708 o The session_id attribute MUST be a random version 4 UUID unique to 709 this session 711 o The session_id attribute MUST match the expected session_id in the 712 reference in the notification file. 714 o The serial attribute MUST match the expected serial in the 715 reference in the notification file. 717 o Note that the publish element is similar to the publish element 718 defined in the publication protocol [I-D.ietf-sidr-publication]. 719 However, the "tag" attribute is not used here because it is not 720 relevant to Relying Parties. 722 3.5.4. XML Schema 724 The following is a RELAX NG compact form schema describing version 1 725 of this protocol. 727 # 728 # RelaxNG schema for RPKI Repository Delta Protocol (RRDP). 729 # 731 default namespace = "http://www.ripe.net/rpki/rrdp" 733 version = xsd:positiveInteger { maxInclusive="1" } 734 serial = xsd:positiveInteger 735 uri = xsd:anyURI 736 uuid = xsd:string { pattern = "[\-0-9a-fA-F]+" } 737 hash = xsd:string { pattern = "[0-9a-fA-F]+" } 738 base64 = xsd:base64Binary 740 # Notification file: lists current snapshots and deltas 742 start |= element notification { 743 attribute version { version }, 744 attribute session_id { uuid }, 745 attribute serial { serial }, 746 element snapshot { 747 attribute uri { uri }, 748 attribute hash { hash } 749 }, 750 element delta { 751 attribute serial { serial }, 752 attribute uri { uri }, 753 attribute hash { hash } 754 }* 755 } 757 # Snapshot segment: think DNS AXFR. 759 start |= element snapshot { 760 attribute version { version }, 761 attribute session_id { uuid }, 762 attribute serial { serial }, 763 element publish { 764 attribute uri { uri }, 765 base64 766 }* 767 } 769 # Delta segment: think DNS IXFR. 771 start |= element delta { 772 attribute version { version }, 773 attribute session_id { uuid }, 774 attribute serial { serial }, 775 delta_element+ 776 } 778 delta_element |= element publish { 779 attribute uri { uri }, 780 attribute hash { hash }?, 781 base64 782 } 784 delta_element |= element withdraw { 785 attribute uri { uri }, 786 attribute hash { hash } 787 } 789 # Local Variables: 790 # indent-tabs-mode: nil 791 # comment-start: "# " 792 # comment-start-skip: "#[ \t]*" 793 # End: 795 4. Operational Considerations 797 4.1. Compatibility with previous standards 799 This protocol has been designed to replace rsync as a distribution 800 mechanism of an RPKI repository. However, it is also designed to co- 801 exist with existing implementations based on rsync, to enable smooth 802 transition from one distribution mechanism to another. 804 For every repository object listed in the snapshot and delta files 805 both the hash of the object's content and the rsync URI [RFC5781] of 806 its location in the repository are listed. This makes it possible to 807 distribute the same RPKI repository, represented by a set of files on 808 a filesystem, using both rsync and RRDP. It also enables Relying 809 Parties tools to query, combine, and consequently validate objects 810 from repositories of different types. 812 4.2. Distribution considerations 814 One of the design goals of RRDP was to minimise load on a repository 815 server while serving clients. To achieve this, neither the content, 816 nor the URLs of the snapshot and delta files are modified after they 817 have been published in the notification file. This allows their 818 effective distribution, either by a single HTTP server, or using a 819 Content Distribution Network (CDN). 821 The RECOMMENDED way for Relying Parties to keep up with the 822 repository updates is to poll the Update Notification File for 823 changes. The content of that file is updated with every new serial 824 version of a repository (while its URL remains stable). To 825 effectively implement distribution of the notification file, an "If- 826 Modified-Since" HTTP request header is required to be present in all 827 requests for notification file (see Section 3.4.4.) Therefore it is 828 RECOMMENDED that Relying Party tools implement a mechanism to keep 829 track of a previous successful fetch of a notification file. 831 Implementations of RRDP should also take care of not producing new 832 versions of the repository (and subsequently, new Notification, 833 Snapshot and Delta files) too often. Usually the maintenance of the 834 RPKI repository includes regular updates of manifest and CRL objects, 835 performed on a schedule. This often results in bursts of repository 836 updates during a short period of time. Since the Relying Parties are 837 required to poll for the Update Notification File not more often than 838 once per minute (Section 3.4.4), it is not practical to generate new 839 serial versions of the repository much more often than 1 per minute. 840 It is allowed to combine multiple updates, possibly from different 841 CAs, into a new serial repository version (Section 3.3.2). This will 842 significantly shorten the size of the Update Notification File and 843 total amount of data distributed to all Relying Parties. 845 4.3. HTTPS considerations 847 Note that a Man-in-the-Middle (MITM) cannot produce validly signed 848 RPKI data, but can perform withhold or replay attacks targeting a 849 Relying Party, and keep the Relying Party from learning about changes 850 in the RPKI. Because of this Relying Parties SHOULD do TLS 851 certificate and host name validation when they fetch from an RRDP 852 Repository Server. 854 Relying Party tools SHOULD log any TLS certificate or host name 855 validation issues found, so that an operator can investigate the 856 cause. However, such validation issues are often due to 857 configuration errors, or a lack of a common TLS trust anchor. In 858 these cases it is better if the Relying Party retrieves the signed 859 RPKI data regardless, and performs validation on it. Therefore 860 Relying Party MUST continue to retrieve the data in case of errors. 861 The Relying Party MAY choose to log encountered issues only when 862 fetching the notification update file, but not when it subsequently 863 fetches snapshot or delta files from the same host. Furthermore the 864 Relying Party MAY provide a way for operators to accept untrusted 865 connections for a given host, after the cause has been identified. 867 It is RECOMMENDED that Relying Parties and Repository Servers follow 868 the Best Current Practices outlined in [RFC7525] on the use of HTTP 869 over TLS (HTTPS) [RFC7230]. Relying Parties SHOULD do TLS 870 certificate and host name validation using subjectAltName dNSName 871 identities as described in [RFC6125]. The rules and guidelines 872 defined in [RFC6125] apply here, with the following considerations: 874 o Relying Parties and Repository Servers SHOULD support the DNS-ID 875 identifier type. The DNS-ID identifier type SHOULD be present in 876 Repository Server certificates. 878 o DNS names in Repository Server certificates SHOULD NOT contain the 879 wildcard character "*". 881 o A CN field may be present in Repository Server certificates's 882 subject name, but SHOULD NOT be used for authentication within the 883 rules described in [RFC6125]. 885 o This protocol does not require the use of SRV-IDs. 887 o This protocol does not require the use of URI-IDs. 889 Note however that this validation is done on a best effort basis, and 890 serves to highlight potential issues, but RPKI object security does 891 not depend on this. Therefore Relying Parties MAY deviate from the 892 validation steps listed above. 894 5. Security Considerations 896 RRDP deals exclusively with transfer of RPKI objects from a 897 repository server to a Relying Party. The trust relation between a 898 Certificate Authority and its repository server is out of scope for 899 this document. However, it should be noted that from a Relying Party 900 point of view all RPKI objects (certificates, CRLs, and CMS-wrapped 901 objects) are already covered by object security mechanisms including 902 signed manifests. This allows validation of these objects even 903 though the repository server itself is not trusted. This document 904 makes no change to RPKI validation procedures per se. 906 The original RPKI transport protocol is rsync, which offers no 907 channel security mechanism. RRDP replaces the use of rsync by HTTPS; 908 while the channel security mechanism underlying RRDP (HTTPS) is not a 909 cure-all, it does make some forms of denial of service attack more 910 difficult for the attacker. HTTPS issues are discussed in more 911 detail in Section 4.3. 913 Supporting both RRDP and rsync necessarily increases the number of 914 opportunities for a malicious RPKI Certificate Authority to perform 915 denial of service attacks on Relying Parties, by expanding the number 916 of URIs which the Relying Party may need to contact in order to 917 complete a validation run. However, other than the relative cost of 918 HTTPS versus rsync, adding RRDP to the mix does not change this 919 picture significantly: with either RRDP or rsync a malicious 920 Certificate Authority can supply an effectively infinite series of 921 URIs for the Relying Party to follow. The only real solution to this 922 is for the Relying Party to apply some kind of bound to the amount of 923 work it is willing to do. Note also that the attacker in this 924 scenario must be an RPKI Certificate Authority, since otherwise the 925 normal RPKI object security checks would reject the malicious URIs. 927 Processing costs for objects retrieved using RRDP may be somewhat 928 different from the same objects retrieved using rsync: because RRDP 929 treats an entire set of changes as a unit (one "delta"), it may not 930 be practical to start processing any of the objects in the delta 931 until the entire delta has been received. With rsync, by contrast, 932 incremental processing may be easy, but the overall cost of transfer 933 may be higher, as may be the number of corner cases in which the 934 Relying Party retrieves some but not all of the updated objects. 935 Overall, RRDP's behavior is closer to a proper transactional system, 936 which (probably) leads to an overall reliability increase. 938 RRDP is designed to scale much better than rsync. In particular, 939 RRDP is designed to allow use of HTTPS caching infrastructure to 940 reduce load on primary Repository Servers and increase resilience 941 against denial of service attacks on the RPKI publication service. 943 6. IANA Considerations 945 IANA is requested to update the reference for id-ad-rpkiNotify to 946 this document in the PKIX Access Descriptor registry 947 [IANA-AD-NUMBERS]. 949 7. Acknowledgements 951 The authors would like to thank David Mandelberg for reviewing this 952 document. 954 8. References 956 8.1. Normative References 958 [I-D.ietf-sidr-publication] 959 Weiler, S., Sonalker, A., and R. Austein, "A Publication 960 Protocol for the Resource Public Key Infrastructure 961 (RPKI)", draft-ietf-sidr-publication-12 (work in 962 progress), March 2017. 964 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 965 Requirement Levels", BCP 14, RFC 2119, 966 DOI 10.17487/RFC2119, March 1997, 967 . 969 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 970 Unique IDentifier (UUID) URN Namespace", RFC 4122, 971 DOI 10.17487/RFC4122, July 2005, 972 . 974 [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI 975 Scheme", RFC 5781, DOI 10.17487/RFC5781, February 2010, 976 . 978 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 979 Verification of Domain-Based Application Service Identity 980 within Internet Public Key Infrastructure Using X.509 981 (PKIX) Certificates in the Context of Transport Layer 982 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 983 2011, . 985 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 986 Resource Certificate Repository Structure", RFC 6481, 987 DOI 10.17487/RFC6481, February 2012, 988 . 990 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 991 X.509 PKIX Resource Certificates", RFC 6487, 992 DOI 10.17487/RFC6487, February 2012, 993 . 995 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 996 Protocol (HTTP/1.1): Message Syntax and Routing", 997 RFC 7230, DOI 10.17487/RFC7230, June 2014, 998 . 1000 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1001 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1002 DOI 10.17487/RFC7231, June 2014, 1003 . 1005 [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1006 Protocol (HTTP/1.1): Conditional Requests", RFC 7232, 1007 DOI 10.17487/RFC7232, June 2014, 1008 . 1010 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 1011 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 1012 RFC 7234, DOI 10.17487/RFC7234, June 2014, 1013 . 1015 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1016 "Recommendations for Secure Use of Transport Layer 1017 Security (TLS) and Datagram Transport Layer Security 1018 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1019 2015, . 1021 [SHS] National Institute of Standards and Technology, "Secure 1022 Hash Standard", March 2012, 1023 . 1026 8.2. Informative References 1028 [IANA-AD-NUMBERS] 1029 "SMI Security for PKIX Access Descriptor", 1030 . 1033 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 1034 "Manifests for the Resource Public Key Infrastructure 1035 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, 1036 . 1038 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object 1039 Template for the Resource Public Key Infrastructure 1040 (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, 1041 . 1043 [rsync] "Rsync home page", . 1045 Authors' Addresses 1047 Tim Bruijnzeels 1048 RIPE NCC 1050 Email: tim@ripe.net 1052 Oleg Muravskiy 1053 RIPE NCC 1055 Email: oleg@ripe.net 1057 Bryan Weber 1058 Cobenian 1060 Email: bryan@cobenian.com 1062 Rob Austein 1063 Dragon Research Labs 1065 Email: sra@hactrn.net