idnits 2.17.1 draft-ietf-sidr-delta-protocol-04.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 date (September 29, 2016) is 2763 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) == Unused Reference: 'RFC7232' is defined on line 842, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-sidr-publication-09 -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-AD-NUMBERS' ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 6486 (Obsoleted by RFC 9286) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7232 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Bruijnzeels 3 Internet-Draft O. Muravskiy 4 Intended status: Standards Track RIPE NCC 5 Expires: April 2, 2017 B. Weber 6 Cobenian 7 R. Austein 8 Dragon Research Labs 9 September 29, 2016 11 RPKI Repository Delta Protocol 12 draft-ietf-sidr-delta-protocol-04 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 delta 21 protocol which provides relying parties with a mechanism to query a 22 repository for incremental updates, thus enabling the RP to keep its 23 state in sync with the repository. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 2, 2017. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 60 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 3. RPKI Repository Delta Protocol Implementation . . . . . . . . 3 62 3.1. Informal Overview . . . . . . . . . . . . . . . . . . . . 3 63 3.2. Certificate Authority Use . . . . . . . . . . . . . . . . 4 64 3.3. Repository Server Use . . . . . . . . . . . . . . . . . . 5 65 3.3.1. Initialisation . . . . . . . . . . . . . . . . . . . 5 66 3.3.2. Publishing Updates . . . . . . . . . . . . . . . . . 5 67 3.4. Relying Party Use . . . . . . . . . . . . . . . . . . . . 7 68 3.4.1. Processing the Update Notification File . . . . . . . 7 69 3.4.2. Processing a Snapshot File . . . . . . . . . . . . . 8 70 3.4.3. Processing Delta Files . . . . . . . . . . . . . . . 8 71 3.4.4. Polling the Update Notification File . . . . . . . . 9 72 3.5. File Definitions . . . . . . . . . . . . . . . . . . . . 9 73 3.5.1. Update Notification File . . . . . . . . . . . . . . 9 74 3.5.2. Snapshot File . . . . . . . . . . . . . . . . . . . . 11 75 3.5.3. Delta File . . . . . . . . . . . . . . . . . . . . . 12 76 3.5.4. XML Schema . . . . . . . . . . . . . . . . . . . . . 14 77 4. HTTPS considerations . . . . . . . . . . . . . . . . . . . . 16 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 81 8. Normative References . . . . . . . . . . . . . . . . . . . . 17 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 84 1. Requirements notation 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in [RFC2119]. 90 2. Introduction 92 In the Resource Public Key Infrastructure (RPKI), Certificate 93 Authorities (CAs) publish certificates [RFC6487], RPKI signed objects 94 [RFC6488], manifests [RFC6486], and CRLs to repositories. CAs may 95 have an embedded mechanism to publish to these repositories, or they 96 may use a separate repository server and publication protocol. RPKI 97 repositories are currently accessible using the rsync protocol, 98 allowing Relying Parties (RPs) to synchronise a local copy of the 99 RPKI repository used for validation with the remote repositories 100 [RFC6481]. 102 This document specifies an alternative repository access protocol 103 based on notification, snapshot and delta files that a RP can 104 retrieve over the HTTPS protocol. This allows RPs to perform either 105 a full (re-)synchronisation of their local copy of the repository 106 using snapshot files, or use delta files to keep their local 107 repository updated after initial synchronisation. 109 This protocol is designed to be consistent (in terms of data 110 structures) with the publication protocol [I-D.ietf-sidr-publication] 111 and treats publication events of one or more repository objects as 112 discrete events that can be communicated to relying parties. This 113 approach helps to minimize the amount of data that traverses the 114 network and thus helps minimize the amount of time until repository 115 convergence occurs. This protocol also provides a standards based 116 way to obtain consistent, point in time views of a single repository, 117 eliminating a number of consistency related issues. Finally, this 118 approach allows these discrete events to be communicated as immutable 119 files, so that caching infrastructure can be used to reduce the load 120 on a repository server when a large number of relying parties are 121 querying it. 123 3. RPKI Repository Delta Protocol Implementation 125 3.1. Informal Overview 127 Certification Authorities (CA) in the RPKI use a repository server to 128 publish their RPKI products, such as manifests, CRLs, signed 129 certificates and RPKI signed objects. This repository server may be 130 remote, or embedded in the CA engine itself. Certificates in the 131 RPKI that use a repository server that supports this delta protocol 132 include a special Subject Information Access (SIA) pointer referring 133 to a notification file. 135 The notification file includes a globally unique session_id in the 136 form of a version 4 UUID, and serial number that can be used by the 137 Relying Party (RP) to determine if it and the repository are 138 synchronised. Furthermore it includes a link to the most recent 139 complete snapshot of current objects that are published by the 140 repository server, and a list of links to delta files, for each 141 revision starting at a point determined by the repository server, up 142 to the current revision of the repository. 144 A RP that learns about a notification file location for the first 145 time can download it, and then proceed to download the latest 146 snapshot file, and thus create a local copy of the repository that is 147 in sync with the repository server. The RP should remember the 148 location of this notification file, the session_id and current serial 149 number. 151 RPs are encouraged to re-fetch this notification file at regular 152 intervals, but not more often than once per minute. After re- 153 fetching the notification file, the RP may find that there are one or 154 more delta files available that allow it to synchronise its local 155 repository with the current state of the repository server. If no 156 contiguous chain of deltas from RP's serial to the latest repository 157 serial is available, or if the session_id has changed, the RP should 158 perform a full resynchronisation instead. 160 As soon as the RP fetches new content in this way it should start a 161 validation process. An example of a reason why a RP may not do this 162 immediately is because it has learned of more than one notification 163 location and it prefers to complete all its updates before 164 validating. 166 The repository server may use caching infrastructure to reduce its 167 load. It should be noted that snapshots and deltas for any given 168 session_id and serial number contain an immutable record of the state 169 of the repository server at a certain point in time. For this reason 170 these files can be cached indefinitely. Notification files are 171 polled by RPs to discover if updates exist, and for this reason 172 notification files may not be cached for longer than one minute. 174 3.2. Certificate Authority Use 176 Certificate Authorities that use this delta protocol MUST include an 177 instance of an SIA AccessDescription extension in resource 178 certificates they produce, in addition to the ones defined in 179 [RFC6487], 181 AccessDescription ::= SEQUENCE { 182 accessMethod OBJECT IDENTIFIER, 183 accessLocation GeneralName } 185 This extension MUST use an accessMethod of id-ad-rpkiNotify, see: 186 [IANA-AD-NUMBERS], 188 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 189 id-ad-rpkiNotify OBJECT IDENTIFIER ::= { id-ad 13 } 191 The accessLocation MUST be an HTTPS URI as defined in [RFC2818], that 192 will point to the update notification file for the repository server 193 that publishes the products of this CA certificate. 195 Relying Parties that do not support this delta protocol MUST NOT 196 reject a CA certificate merely because it has an SIA extension 197 containing this new kind of AccessDescription. 199 3.3. Repository Server Use 201 3.3.1. Initialisation 203 When the repository server initialises it must perform the following 204 actions: 206 The server MUST generate a new random version 4 UUID to be used as 207 the session_id 209 The server MUST then generate a snapshot file for serial number 210 ONE for this new session that includes all currently known 211 published objects that the repository server is responsible for. 212 Note that this snapshot file MAY contain zero publish elements at 213 this point if no objects have been submitted for publication yet. 215 This snapshot file MUST be made available at a URL that is unique 216 to this session_id and serial number, so that it can be cached 217 indefinitely. 219 The format and caching concerns for snapshot files are explained 220 in more detail in Section 3.5.2. 222 After the snapshot file has been published the repository server 223 MUST publish a new notification file that contains the new 224 session_id, has serial number ONE, has one reference to the 225 snapshot file that was just published, and that contains no delta 226 references. 228 The format and caching concerns for update notification files are 229 explained in more detail in Section 3.5.1. 231 3.3.2. Publishing Updates 233 Whenever the repository server receives updates from a CA it SHOULD 234 generate new snapshot and delta files. However, if a publication 235 server services a large number of CAs it MAY choose to combine 236 updates from multiple CAs. If a publication server combines updates 237 in this way, it MUST NOT postpone publishing for longer than one 238 minute. 240 Updates must be processed as follows: 242 o The new repository serial number MUST be one greater than the 243 current repository serial number. 245 o A new delta file MUST be generated for this new serial. This 246 delta file MUST include all new, replaced and withdrawn objects 247 for multiple CAs if applicable, as a single change set. 249 o This delta file MUST be made available at a URL that is unique to 250 the current session_id and serial number, so that it can be cached 251 indefinitely. 253 o The format and caching concerns for delta files are explained in 254 more detail in Section 3.5.3. 256 o The repository server MUST also generate a new snapshot file for 257 this new serial. This file MUST contain all "publish" elements 258 for all current objects. 260 o The snapshot file MUST be made available at a URL that is unique 261 to this session and new serial, so that it can be cached 262 indefinitely. 264 o The format and caching concerns for snapshot files are explained 265 in more detail in Section 3.5.2. 267 o The update notification file SHOULD be kept small, and in order to 268 do so the repository server needs to make a decision about which 269 delta files to support. Any older delta files that, when combined 270 with all more recent delta files, will result in total size of 271 deltas exceeding the size of the snapshot, MUST be excluded. 273 o The server MAY also exclude more recent delta files if it finds 274 that their usage by a small number of RPs that would be forced to 275 perform a full synchronisation is outweighed by the performance 276 penalty for all RPs in having a large update notification file. 277 However the repository server SHOULD include all deltas for the 278 last two hours. 280 o A new notification file MUST now be created by the repository 281 server. This new notification file MUST include a reference to 282 the new snapshot file, and all delta files selected in the 283 previous steps. 285 o The format and caching concerns for update notification files are 286 explained in more detail in Section 3.5.1. 288 If the repository server is not capable of performing the above for 289 some reason, then it MUST perform a full re-initialisation, as 290 explained above in Section 3.3.1. 292 3.4. Relying Party Use 294 3.4.1. Processing the Update Notification File 296 When a Relying Party (RP) performs RPKI validation and learns about a 297 valid certificate with an SIA entry for the RRDP protocol, it SHOULD 298 prefer to use this protocol as follows. 300 The RP SHOULD download the update notification file, unless an update 301 notification file was already downloaded and processed from the same 302 location in this validation run. 304 The RP MAY use a "User-Agent" header explained in section 5.5.3. of 305 [RFC7231] to identify the name and version of the RP software used. 306 This is not required, but would be useful to help track capabilities 307 of Relying Parties in the event of changes to the RPKI standards. 309 When the RP downloads an update notification file it MUST verify the 310 file format and validation steps described in section 311 Section 3.5.1.3. If this verification fails, the file MUST be 312 rejected. 314 The RP MUST verify whether the session_id in this update notification 315 file matches the last known session_id for this update notification 316 file location. If the session_id matches the last known session_id, 317 then an RP MAY download and process missing delta files as described 318 in section Section 3.4.3, provided that all delta files for serial 319 numbers between the last processed serial number and the current 320 serial number in the notification file can be processed this way. 322 If the session_id was not previously known, or if delta files could 323 not be used, then the RP MUST update its last known session_id to 324 this session_id and download and process snapshot file on the update 325 notification file as described in section Section 3.4.2. 327 If neither update notification file and one snapshot file or delta 328 files could be processed this way, the RP MUST issue an operator 329 error, and SHOULD use an alternate repository retrieval mechanism if 330 it is available. 332 3.4.2. Processing a Snapshot File 334 When the RP downloads a snapshot file it MUST verify the file format 335 and validation steps described in Section 3.5.2.3. If this 336 verification fails, the file MUST be rejected. 338 Furthermore the RP MUST verify that the hash of the contents of this 339 file matches the hash on the update notification file that referenced 340 it. In case of a mismatch of this hash, the file MUST be rejected. 342 If an RP retrieved a snapshot file that is valid according to the 343 above criteria, it should perform the following actions: 345 The RP MUST verify that the session_id matches the session_id of 346 the notification file. If the session_id values do not match the 347 file MUST be rejected. 349 The RP MUST verify that the serial number of this snapshot file is 350 greater than the last processed serial number for this session_id. 351 If this fails the file MUST be rejected. 353 The RP SHOULD then add all publish elements to a local storage and 354 update its last processed serial number to the serial number of 355 this snapshot file. 357 3.4.3. Processing Delta Files 359 If an update notification file contains a contiguous chain of links 360 to delta files from the last processed serial number to the current 361 serial number, then RPs MUST attempt to download and process all 362 delta files in order of serial number as follows. 364 When the RP downloads a delta file it MUST verify the file format and 365 perform validation steps described in Section 3.5.3.3. If this 366 verification fails, the file MUST be rejected. 368 Furthermore the RP MUST verify that the hash of the contents of this 369 file matches the hash on the update notification file that referenced 370 it. In case of a mismatch of this hash, the file MUST be rejected. 372 If an RP retrieved a delta file that is valid according to the above 373 criteria, it should perform the following actions: 375 The RP MUST verify that the session_id matches the session_id of 376 the notification file. If the session_id values do not match the 377 file MUST be rejected. 379 The RP MUST verify that the serial number of this delta file is 380 exactly one greater than the last processed serial number for this 381 session_id, and if not this file MUST be rejected. 383 The RP SHOULD add all publish elements to a local storage and 384 update its last processed serial number to the serial number of 385 this snapshot file. 387 The RP SHOULD NOT remove objects from its local storage solely 388 because it encounters a "withdraw" element, because this would 389 enable a publication server to withdraw any object without the 390 signing Certificate Authority consent. Instead it is RECOMMENDED 391 that a RP uses additional strategies to determine if an object is 392 still relevant for validation before removing it from its local 393 storage. 395 3.4.4. Polling the Update Notification File 397 Once a Relying Party has learned about the location, session_id and 398 last processed serial number of repository that uses the RRDP 399 protocol, the RP MAY start polling the repository server for updates. 400 However the RP MUST NOT poll for updates more often than once every 1 401 minute, and in order to reduce data usage RPs MUST use the "If- 402 Modified-Since" header explained in section 3.3 of [RFC7232]in 403 requests. 405 If an RP finds that updates are available it SHOULD download and 406 process the file as described in Section 3.4.1, and initiate a new 407 validation process. A detailed description of the validation process 408 itself is out of scope of this document. 410 3.5. File Definitions 412 3.5.1. Update Notification File 414 3.5.1.1. Purpose 416 The update notification file is used by RPs to discover whether any 417 changes exist between the state of the repository and the RP's cache. 418 It describes the location of the files containing the snapshot and 419 incremental deltas which can be used by the RP to synchronise with 420 the repository. 422 3.5.1.2. Cache Concerns 424 A repository server MAY use caching infrastructure to cache the 425 notification file and reduce the load of HTTPS requests. However, 426 since this file is used by RPs to determine whether any updates are 427 available the repository server MUST ensure that this file is not 428 cached for longer than 1 minute. An exception to this rule is that 429 it is better to serve a stale notification file, then no notification 430 file. 432 How this is achieved exactly depends on the caching infrastructure 433 used. In general a repository server may find certain HTTP headers 434 to be useful, such as: Cache-Control: max-age=60. Another approach 435 can be to have the repository server push out new versions of the 436 notification file to the caching infrastructure when appropriate. 438 Relying Parties SHOULD NOT cache the notification file for longer 439 than 1 minute, regardless of the headers set by the repository server 440 or CDN. 442 3.5.1.3. File Format and Validation 444 Example notification file: 446 450 451 452 453 455 Note: URIs and hash values in this example are shortened because of 456 formatting. 458 The following validation rules must be observed when creating or 459 parsing notification files: 461 o A RP MUST reject any update notification file that is not well- 462 formed, or which does not conform to the RELAX NG schema outlined 463 in Section 3.5.4 of this document. 465 o The XML namespace MUST be http://www.ripe.net/rpki/rrdp 467 o The encoding MUST be US-ASCII 469 o The version attribute in the notification root element MUST be 1 471 o The session_id attribute MUST be a random version 4 UUID unique to 472 this session 474 o The serial attribute must be an unbounded, unsigned positive 475 integer in decimal format indicating the current version of the 476 repository. 478 o The notification file MUST contain exactly one 'snapshot' element 479 for the current repository version. 481 o If delta elements are included they MUST form a contiguous 482 sequence of serial numbers starting at a revision determined by 483 the repository server, up to the serial number mentioned in the 484 notification element. 486 o The hash attribute in snapshot and delta elements must be the 487 hexadecimal encoding of the SHA-256 hash of the referenced file. 488 The RP MUST verify this hash when the file is retrieved and reject 489 the file if the hash does not match. 491 3.5.2. Snapshot File 493 3.5.2.1. Purpose 495 A snapshot is intended to reflect the complete and current contents 496 of the repository for a specific session and version. Therefore it 497 MUST contain all objects from the repository current as of the time 498 of the publication. 500 3.5.2.2. Cache Concerns 502 A snapshot reflects the content of the repository at a specific point 503 in time, and for that reason can be considered immutable data. 504 Snapshot files MUST be published at a URL that is unique to the 505 specific session and serial. 507 Because these files never change, they MAY be cached indefinitely. 508 However, in order to prevent that these files use a lot of space in 509 caching infrastructure it is RECOMMENDED that a limited interval is 510 used in the order of hours or days. 512 To avoid race conditions where an RP downloads a notification file 513 moments before it's updated, Repository Servers SHOULD retain old 514 snapshot files for at least 5 minutes after a new notification file 515 is published. 517 3.5.2.3. File Format and Validation 519 Example snapshot file: 521 525 526 ZXhhbXBsZTE= 527 528 529 ZXhhbXBsZTI= 530 531 532 ZXhhbXBsZTM= 533 534 536 The following rules must be observed when creating or parsing 537 snapshot files: 539 o A RP MUST reject any snapshot file that is not well-formed, or 540 which does not conform to the RELAX NG schema outlined in 541 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 match the expected session_id in the 550 reference in the notification file. 552 o The serial attribute MUST match the expected serial in the 553 reference in the notification file. 555 o Note that the publish element is defined in the publication 556 protocol [I-D.ietf-sidr-publication] 558 3.5.3. Delta File 560 3.5.3.1. Purpose 562 An incremental delta file contains all changes for exactly one serial 563 increment of the repository server. In other words a single delta 564 will typically include all the new objects, updated objects and 565 withdrawn objects that a Certification Authority sent to the 566 repository server. In its simplest form the update could concern 567 only a single object, but it is recommended that CAs send all changes 568 for one of their key pairs: i.e. updated objects as well as a new 569 manifest and CRL as one atomic update message. 571 3.5.3.2. Cache Concerns 573 Deltas reflect the difference between two consecutive versions of a 574 repository for a given session. For that reason deltas can be 575 considered immutable data. Delta files MUST be published at a URL 576 that is unique to the specific session and serial. 578 Because these files never change, they MAY be cached indefinitely. 579 However, in order to prevent these files from using a lot of space in 580 caching infrastructure it is RECOMMENDED that a limited interval is 581 used in the order of hours or days. 583 To avoid race conditions where an RP downloads a notification file 584 moments before it's updated, Repository Servers SHOULD retain old 585 delta files for at least 5 minutes after they are no no longer 586 included in the latest notification file. 588 3.5.3.3. File Format and Validation 590 Example delta file: 592 596 598 ZXhhbXBsZTQ= 599 600 602 ZXhhbXBsZTU= 603 604 606 608 Note that a formal RELAX NG specification of this file format is 609 included later in this document. A RP MUST NOT process any delta 610 file that is incomplete or not well-formed. 612 The following validation rules must be observed when creating or 613 parsing delta files: 615 o A RP MUST reject any delta file that is not well-formed, or which 616 does not conform to the RELAX NG schema outlined in Section 3.5.4 617 of this document. 619 o The XML namespace MUST be http://www.ripe.net/rpki/rrdp. 621 o The encoding MUST be US-ASCII. 623 o The version attribute in the delta root element MUST be 1 625 o The session_id attribute MUST be a random version 4 UUID unique to 626 this session 628 o The session_id attribute MUST match the expected session_id in the 629 reference in the notification file. 631 o The serial attribute MUST match the expected serial in the 632 reference in the notification file. 634 o Note that the publish and withdraw elements are defined in the 635 publication protocol [I-D.ietf-sidr-publication] 637 3.5.4. XML Schema 639 The following is a RELAX NG compact form schema describing version 1 640 of this protocol. 642 # 643 # RelaxNG schema for RPKI Repository Delta Protocol (RRDP). 644 # 646 default namespace = "http://www.ripe.net/rpki/rrdp" 648 version = xsd:positiveInteger { maxInclusive="1" } 649 serial = xsd:nonNegativeInteger 650 uri = xsd:anyURI 651 uuid = xsd:string { pattern = "[\-0-9a-fA-F]+" } 652 hash = xsd:string { pattern = "[0-9a-fA-F]+" } 653 base64 = xsd:base64Binary 655 # Notification file: lists current snapshots and deltas 657 start |= element notification { 658 attribute version { version }, 659 attribute session_id { uuid }, 660 attribute serial { serial }, 661 element snapshot { 662 attribute uri { uri }, 663 attribute hash { hash } 664 }, 665 element delta { 666 attribute serial { serial }, 667 attribute uri { uri }, 668 attribute hash { hash } 669 }* 670 } 672 # Snapshot segment: think DNS AXFR. 674 start |= element snapshot { 675 attribute version { version }, 676 attribute session_id { uuid }, 677 attribute serial { serial }, 678 element publish { 679 attribute uri { uri }, 680 base64 681 }* 682 } 684 # Delta segment: think DNS IXFR. 686 start |= element delta { 687 attribute version { version }, 688 attribute session_id { uuid }, 689 attribute serial { serial }, 690 delta_element+ 691 } 693 delta_element |= element publish { 694 attribute uri { uri }, 695 attribute hash { hash }?, 696 base64 697 } 699 delta_element |= element withdraw { 700 attribute uri { uri }, 701 attribute hash { hash } 702 } 704 # Local Variables: 705 # indent-tabs-mode: nil 706 # comment-start: "# " 707 # comment-start-skip: "#[ \t]*" 708 # End: 710 4. HTTPS considerations 712 It is RECOMMENDED that Relying Parties and Publication Servers follow 713 the Best Current Practices outlined in [RFC7525] on the use of HTTP 714 over TLS (https). 716 Note that a Man-in-the-Middle (MITM) cannot produce validly signed 717 RPKI data, but they can perform withhold or replay attacks targeting 718 an RP, and keep the RP from learning about changes in the RPKI. 719 Because of this RPs SHOULD do TLS certificate and host name 720 validation when they fetch from an RRDP Publication Server 722 However, such validation issues are often due to configuration 723 errors, or a lack of a common TLS trust anchor. In these cases it 724 would be better that the RP retrieves the signed RPKI data 725 regardless, and performs validation on it. 727 Therefore RPs SHOULD log any TLS certificate or host name validation 728 issues they find, so that an operator can investigate the cause. But 729 the RP MUST continue to retrieve the data. The RP MAY choose to log 730 this issue only when fetching the notification update file, but not 731 when it subsequently fetches snapshot or delta files from the same 732 host. Furthermore the RP MAY provide a way for operators to accept 733 untrusted connections for a given host, after the cause has been 734 identified. 736 5. Security Considerations 738 RRDP deals exclusively with transfer of RPKI objects from a 739 repository server to a relying party. The trust relation between a 740 CA and its repository server is out of scope for this document. 741 However, it should be noted the from a relying party point of view 742 all RPKI objects (certificates, CRLs, and CMS-wrapped objects) are 743 already covered by object security mechanisms including signed 744 manifests. This allows validation of these objects even though the 745 repository server itself is not trusted. This document makes no 746 change to RPKI validation procedures per se. 748 The original RPKI transport mechanism is rsync, which offers no 749 channel security mechanism. RRDP replaces the use of rsync by HTTPS; 750 while the channel security mechanism underlying RRDP (HTTPS) is not a 751 cure-all, it does make some forms of denial of service attack more 752 difficult for the attacker. HTTPS issues are discussed in more 753 detail in Section 4. 755 Supporting both RRDP and rsync necessarily increases the number of 756 opportunities for a malicious RPKI CA to perform denial of service 757 attacks on relying parties, by expanding the number of URIs which the 758 RP may need to contact in order to complete a validation run. 759 However, other than the relative cost of HTTPS versus rsync, adding 760 RRDP to the mix does not change this picture significantly: with 761 either RRDP or rsync a malicious CA can supply an effectively 762 infinite series of URIs for the RP to follow. The only real solution 763 to this is for the RP to apply some kind of bound to the amount of 764 work it is willing to do. Note also that the attacker in this 765 scenario must be an RPKI CA, since otherwise the normal RPKI object 766 security checks would reject the malicious URIs. 768 Processing costs for objects retrieved using RRDP may be somewhat 769 different from the same objects retrieved using rsync: because RRDP 770 treats an entire set of changes as a unit (one "delta"), it may not 771 be practical to start processing any of the objects in the delta 772 until the entire delta has been received. With rsync, by contrast, 773 incremental processing may be easy, but the overall cost of transfer 774 may be higher, as may be the number of corner cases in which the RP 775 retrieves some but not all of the updated objects. Overall, RRDP's 776 behavior is closer to a proper transactional system, which (probably) 777 leads to an overall reliability increase. 779 RRDP is designed to scale much better than rsync. In particular, 780 RRDP is designed to allow use of HTTPS caching infrastructure to 781 reduce load on primary publication servers and increase resilience 782 against denial of service attacks on the RPKI publication service. 784 6. IANA Considerations 786 IANA is requested to update the reference for id-ad-rpkiNotify to 787 this document in the PKIX Access Descriptor registry 788 [IANA-AD-NUMBERS]. 790 7. Acknowledgements 792 The authors would like to thank David Mandelberg for reviewing this 793 document. 795 8. Normative References 797 [I-D.ietf-sidr-publication] 798 Weiler, S., Sonalker, A., and R. Austein, "A Publication 799 Protocol for the Resource Public Key Infrastructure 800 (RPKI)", draft-ietf-sidr-publication-09 (work in 801 progress), September 2016. 803 [IANA-AD-NUMBERS] 804 "SMI Security for PKIX Access Descriptor", 805 . 808 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 809 Requirement Levels", BCP 14, RFC 2119, 810 DOI 10.17487/RFC2119, March 1997, 811 . 813 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 814 DOI 10.17487/RFC2818, May 2000, 815 . 817 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 818 Resource Certificate Repository Structure", RFC 6481, 819 DOI 10.17487/RFC6481, February 2012, 820 . 822 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 823 "Manifests for the Resource Public Key Infrastructure 824 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, 825 . 827 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 828 X.509 PKIX Resource Certificates", RFC 6487, 829 DOI 10.17487/RFC6487, February 2012, 830 . 832 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object 833 Template for the Resource Public Key Infrastructure 834 (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, 835 . 837 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 838 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 839 DOI 10.17487/RFC7231, June 2014, 840 . 842 [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 843 Protocol (HTTP/1.1): Conditional Requests", RFC 7232, 844 DOI 10.17487/RFC7232, June 2014, 845 . 847 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 848 "Recommendations for Secure Use of Transport Layer 849 Security (TLS) and Datagram Transport Layer Security 850 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 851 2015, . 853 Authors' Addresses 855 Tim Bruijnzeels 856 RIPE NCC 858 Email: tim@ripe.net 860 Oleg Muravskiy 861 RIPE NCC 863 Email: oleg@ripe.net 865 Bryan Weber 866 Cobenian 868 Email: bryan@cobenian.com 870 Rob Austein 871 Dragon Research Labs 873 Email: sra@hactrn.net