idnits 2.17.1 draft-ietf-sidr-delta-protocol-01.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Relying Parties SHOULD not cache the notification file for longer than 1 minute, regardless of the headers set by the repository server or CDN. -- The document date (October 19, 2015) is 3102 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) == Outdated reference: A later version (-12) exists of draft-ietf-sidr-publication-07 -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-AD-NUMBERS' ** Obsolete normative reference: RFC 6486 (Obsoleted by RFC 9286) Summary: 1 error (**), 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 21, 2016 B. Weber 6 Cobenian 7 R. Austein 8 Dragon Research Labs 9 D. Mandelberg 10 BBN Technologies 11 October 19, 2015 13 RPKI Repository Delta Protocol 14 draft-ietf-sidr-delta-protocol-01 16 Abstract 18 In the Resource Public Key Infrastructure (RPKI), certificate 19 authorities publish certificates, including end entity certificates, 20 and CRLs to repositories on repository servers. Relying Parties (RP) 21 retrieve the published information from the repository and MAY store 22 it in a cache. This document specifies a delta protocol which 23 provides relying parties with a mechanism to query a repository for 24 changes, thus enabling the RP to keep its state in sync with the 25 repository. 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 April 21, 2016. 44 Copyright Notice 46 Copyright (c) 2015 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 . . . . . . . . 3 64 3.1. Informal Overview . . . . . . . . . . . . . . . . . . . . 3 65 3.2. Update Notification File . . . . . . . . . . . . . . . . 4 66 3.2.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 4 67 3.2.2. Cache Concerns . . . . . . . . . . . . . . . . . . . 5 68 3.2.3. File Format and Validation . . . . . . . . . . . . . 5 69 3.2.4. Repository Server Initialisation . . . . . . . . . . 6 70 3.2.5. Publishing Updates . . . . . . . . . . . . . . . . . 6 71 3.3. Snapshot File . . . . . . . . . . . . . . . . . . . . . . 7 72 3.3.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 7 73 3.3.2. Cache Concerns . . . . . . . . . . . . . . . . . . . 7 74 3.3.3. File Format and Validation . . . . . . . . . . . . . 7 75 3.4. Delta File . . . . . . . . . . . . . . . . . . . . . . . 8 76 3.4.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 8 77 3.4.2. Cache Concerns . . . . . . . . . . . . . . . . . . . 9 78 3.4.3. File Format and Validation . . . . . . . . . . . . . 9 79 3.5. SIA for CA certificates . . . . . . . . . . . . . . . . . 10 80 4. Relying Party Use . . . . . . . . . . . . . . . . . . . . . . 10 81 4.1. Full Synchronisation . . . . . . . . . . . . . . . . . . 11 82 4.2. Processing Deltas . . . . . . . . . . . . . . . . . . . . 11 83 5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 86 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 87 9. Normative References . . . . . . . . . . . . . . . . . . . . 13 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 90 1. Requirements notation 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 2. Introduction 98 In the Resource Public Key Infrastructure (RPKI), Certificate 99 Authorities (CAs) publish certificates [RFC6487], RPKI signed objects 100 [RFC6488], manifests [RFC6486], and CRLs to repositories. CAs may 101 have an embedded mechanism to publish to these repositories, or they 102 may use a separate repository server and publication protocol. RPKI 103 repositories are currently accessible using rsync, allowing Relying 104 Parties (RPs) to synchronise a local copy of the RPKI repository used 105 for validation with the central repositories using the rsync protocol 106 [RFC6481]. 108 This document specifies an alternative repository access protocol 109 based on notification, snapshot and delta files that a RP can 110 retrieve over HTTPS. This allows RPs to perform a full 111 (re-)synchronisation of their local copy of the repository using 112 snapshot files. However, typically RPs will use delta files to keep 113 their local repository updated after initial synchronisation. 115 This protocol is designed to be consistent with the publication 116 protocol [I-D.ietf-sidr-publication] and treats publication events of 117 one or more repository objects as discrete events that can be 118 communicated to relying parties. This approach helps to minimize the 119 amount of data that traverses the network and thus helps minimize the 120 amount of time until repository convergence occurs. This protocol 121 also provides a standards based way to obtain consistent, point in 122 time views of a single repository, eliminating a number of 123 consistency related issues. Finally, this approach allows these 124 discrete events to be communicated as immutable files, so that 125 caching infrastructure can be used to reduce the load on a repository 126 server when a large a number of relying parties are querying it. 128 3. RPKI Repository Delta Protocol Implementation 130 3.1. Informal Overview 132 Certification Authorities (CA) in the RPKI use a repository server to 133 publish their RPKI products, such as manifests, CRLs, signed 134 certificates and RPKI signed objects. This repository server may be 135 remote, or embedded in the CA engine itself. Certificates in the 136 RPKI that use a repository server that supports this delta protocol 137 include a special Subject Information Access (SIA) pointer referring 138 to a notification file. 140 The notification file includes a globally unique session_id in the 141 form of a version 4 UUID, and serial number that can be used by the 142 Relying Party (RP) to determine if it and the repository are 143 synchronised. Furthermore it includes a link to the most recent 144 complete snapshot of current objects that are published by the 145 repository servers, and a list of links to delta files, for each 146 revision starting at a point determined by the repository server, up 147 to the current revision of the repository. 149 A RP that learns about a notification file location for the first 150 time can download it, and then proceed to download the latest 151 snapshot file, and thus create a local copy of the repository that is 152 in sync with the repository server. The RP should remember the 153 location of this notification file, the session_id and current serial 154 number. 156 RPs are encouraged to re-fetch this notification file at regular 157 intervals, but not more often than once per minute. After re- 158 fetching the notification file, the RP may find that there are one or 159 more delta files available that allow it to synchronise its local 160 repository with the current state of the repository server. If no 161 contiguous chain of deltas from RP's serial to the latest repository 162 serial is available, or if the session_id has changed, the RP should 163 perform a full resynchronisation instead. 165 As soon as the RP fetches new content in this way it should start a 166 validation process using its local repository. An example of a 167 reason why a RP may not do this immediately is because it has learned 168 of more than one notification location and it prefers to complete all 169 its updates before validating. 171 The repository server may use caching infrastructure to reduce its 172 load. It should be noted that snapshots and deltas for any given 173 session_id and serial number contain an immutable record of the state 174 of the repository server at a certain point in time. For this reason 175 these files can be cached indefinitely. Notification files are 176 polled by RPs to discover if updates exist, and for this reason 177 notification files may not be cached for longer than one minute. 179 3.2. Update Notification File 181 3.2.1. Purpose 183 The update notification file is used by RPs to discover whether any 184 changes exist between the state of the repository and the RP's cache. 185 It describes the location of the files containing the snapshot and 186 incremental deltas which can be used by the RP to synchronise with 187 the repository. 189 3.2.2. Cache Concerns 191 A repository server MAY use caching infrastructure to cache the 192 notification file and reduce the load of HTTPS requests. However, 193 since this file is used by RPs to determine whether any updates are 194 available the repository server MUST ensure that this file is not 195 cached for longer than 1 minute. An exception to this rule is that 196 it is better to serve a stale notification file, then no notification 197 file. 199 How this is achieved exactly depends on the caching infrastructure 200 used. In general a repository server may find certain http headers 201 to be useful, such as: Cache-Control: max-age=60. Another approach 202 can be to have the repository server push out new versions of the 203 notification file to the caching infrastructure when appropriate. 205 Relying Parties SHOULD not cache the notification file for longer 206 than 1 minute, regardless of the headers set by the repository server 207 or CDN. 209 3.2.3. File Format and Validation 211 Example notification file: 213 217 218 219 220 222 The following validation rules must be observed when creating or 223 parsing notification files: 225 o A RP MUST NOT process any update notification file that is not 226 well formed, or which does not conform to the RELAX NG schema 227 outlined in Section 5 of this document. 229 o The XML namespace MUST be http://www.ripe.net/rpki/rrdp 231 o The encoding MUST be us-ascii 233 o The version attribute in the notification root element MUST be 1 235 o The session_id attribute MUST be a random version 4 UUID unique to 236 this session 238 o The serial attribute must be an unbounded, unsigned positive 239 integer indicating the current version of the repository. 241 o The notification file MUST contain exactly one 'snapshot' element 242 for the current repository version. 244 o If delta elements are included they MUST form a contiguous 245 sequence of serial numbers starting at a revision determined by 246 the repository server, up to the serial number mentioned in the 247 notification element. 249 3.2.4. Repository Server Initialisation 251 When the repository server (re-) initialises it MUST generate a new 252 random version 4 UUID to be used as the session_id. Furthermore it 253 MUST then generate a snapshot file for serial number ONE for this new 254 session that includes all currently known published objects that the 255 repository server is responsible for. This snapshot file MUST be 256 made available at a URL that is unique to this session and version, 257 so that it can be cached indefinitely. The format and caching 258 concerns for snapshot files are explained in more detail below in 259 Section 3.3. After the snapshot file has been published the 260 repository server MUST publish a new notification file that contains 261 the new session_id, has serial number ONE, has one reference to the 262 snapshot file that was just published, and that contains no delta 263 references. 265 3.2.5. Publishing Updates 267 Whenever the repository server receives updates from a CA it SHOULD 268 generate new snapshot and delta files and publish a new notification 269 file as follows: 271 o The new repository serial MUST be one greater than the current 272 repository serial. 274 o A new delta file MUST be generated for this new serial. This 275 delta file MUST include all new, replaced and withdrawn objects, 276 as a single change set. 278 o This delta file MUST be made available at a URL that is unique to 279 this session and version, so that it can be cached indefinitely. 281 o The repository server MUST also generate a new snaphost file for 282 this new serial. This file MUST contain all publish elements for 283 all current objects. 285 o The snapshot file MUST be made available at a URL that is unique 286 to this session and new version, so that it can be cached 287 indefinitely. 289 o A new notification file MUST be created by the repository server. 290 This new notification file MUST include a reference to the new 291 snapshot file. The file SHOULD also include available delta files 292 for this and previous updates. However, the server MUST NOT 293 include more delta files than, when combined, exceed the size of 294 the current snapshot. 296 If the repository server is not capable of performing the above for 297 some reason, then it MUST perform a full re-initialisation, as 298 explained above in Section 3.2.4. 300 3.3. Snapshot File 302 3.3.1. Purpose 304 A snapshot is intended to reflect the complete and current contents 305 of the repository for a specific session and version. Therefore it 306 MUST contain all objects from the repository current as of the time 307 of the publication. 309 3.3.2. Cache Concerns 311 A snapshot reflects the content of the repository at a specific point 312 in time, and for that reason can be considered immutable data. 313 Snapshot files MUST be published at a URL that is unique to the 314 specific session and serial. 316 Because these files never change, they MAY be cached indefinitely. 317 However, in order to prevent that these files use a lot of space in 318 caching infrastructure it is RECOMMENDED that a limited interval is 319 used in the order of hours or days. 321 Repository servers MAY delete old snapshot files one hour after they 322 are no longer included in the notification file. 324 3.3.3. File Format and Validation 326 Example snapshot file: 328 332 333 ZXhhbXBsZTE= 334 335 336 ZXhhbXBsZTI= 337 338 339 ZXhhbXBsZTM= 340 341 343 The following rules must be observed when creating or parsing 344 snapshot files: 346 o A RP MUST NOT process any snapshot file that is not well formed, 347 or which does not conform to the RELAX NG schema outlined in 348 Section 5 of this document. 350 o The XML namespace MUST be http://www.ripe.net/rpki/rrdp. 352 o The encoding MUST be us-ascii. 354 o The version attribute in the notification root element MUST be 1 356 o The session_id attribute MUST match the expected session_id in the 357 reference in the notification file. 359 o The serial attribute MUST match the expected serial in the 360 reference in the notification file. 362 o Note that the publish element is defined in the publication 363 protocol [I-D.ietf-sidr-publication] 365 3.4. Delta File 367 3.4.1. Purpose 369 An incremental delta file contains all changes for exactly one serial 370 increment of the repository server. In other words a single delta 371 will typically include all the new objects, updated objects and 372 withdrawn objects that a Certification Authority sent to the 373 repository server. In its simplest form the update could concern 374 only a single object, but it is recommended that CAs send all changes 375 for one of their key pairs: i.e. updated objects as well as a new 376 manifest and CRL as one atomic update message. 378 3.4.2. Cache Concerns 380 Deltas reflect a the difference between two consecutive versions of a 381 repository for a given session. For that reason deltas can be 382 considered immutable data. Delta files MUST be published at a URL 383 that is unique to the specific session and serial. 385 Because these files never change, they MAY be cached indefinitely. 386 However, in order to prevent these files from using a lot of space in 387 caching infrastructure it is RECOMMENDED that a limited interval is 388 used in the order of hours or days. 390 Repository servers MAY delete old delta files one hour after they are 391 no longer included in the notification file. 393 3.4.3. File Format and Validation 395 Example delta file: 397 401 403 ZXhhbXBsZTQ= 404 405 407 ZXhhbXBsZTU= 408 409 411 413 Note that a formal RELAX NG specification of this file format is 414 included later in this document. A RP MUST NOT process any delta 415 file that is incomplete or not well formed. 417 The following validation rules must be observed when creating or 418 parsing delta files: 420 o A RP MUST NOT process any delta file that is not well formed, or 421 which does not conform to the RELAX NG schema outlined in 422 Section 5 of this document. 424 o The XML namespace MUST be http://www.ripe.net/rpki/rrdp. 426 o The encoding MUST be us-ascii. 428 o The version attribute in the delta root element MUST be 1 430 o The session_id attribute MUST be a random version 4 UUID unique to 431 this session 433 o The session_id attribute MUST match the expected session_id in the 434 reference in the notification file. 436 o The serial attribute MUST match the expected serial in the 437 reference in the notification file. 439 o Note that the publish and withdraw elements are defined in the 440 publication protocol [I-D.ietf-sidr-publication] 442 3.5. SIA for CA certificates 444 Certificate Authorities that use this delta protocol MUST have an 445 instance of an SIA AccessDescription in addition to the ones defined 446 in [RFC6487], 448 AccessDescription ::= SEQUENCE { 449 accessMethod OBJECT IDENTIFIER, 450 accessLocation GeneralName } 452 This extension MUST use an accessMethod of id-ad-rpkiNotify, see: 453 [IANA-AD-NUMBERS], 455 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 456 id-ad-rpkiNotify OBJECT IDENTIFIER ::= { id-ad 13 } 458 The accessLocation MUST be a URI [RFC3986], using the 'https' scheme, 459 that will point to the update notification file for the repository 460 server that publishes the products of this CA certificate. 462 Relying Parties that do not support this delta protocol MUST NOT 463 reject a CA certificate merely because it has an SIA extension 464 containing this new kind of AccessDescription. 466 4. Relying Party Use 467 4.1. Full Synchronisation 469 When a Relying Party first encounters a notification file URI as an 470 SIA of a certificate that it has validated it SHOULD retrieve the 471 notification file and download the latest snapshot to get in sync 472 with the current version of the repository server. 474 4.2. Processing Deltas 476 It is RECOMMENDED that the RP notes the URI, session_id and serial 477 number when it first learns about a notification file. The RP MAY 478 then poll the file to discover updates, but SHOULD NOT poll more 479 frequently than once per minute. 481 If the RP finds that the session_id has changed, or if it cannot find 482 a contiguous chain of links to delta files from its current serial to 483 repository server's current serial, then it MUST perform a full 484 synchronisation instead of continuing to process deltas. 486 If the RP finds a contiguous chain of links to delta files from its 487 current serial to the repository server's current serial, and the 488 session_id has not changed, it should download all missing delta 489 files. If any delta file cannot be downloaded, or if no such chain 490 of deltas is available, or the session_id has changed, then the RP 491 MUST perform a full synchronisation instead. 493 New objects found in delta files can be added to the RPs local copy 494 of the repository. However, it is RECOMMENDED that the RP treats 495 object updates and withdraws with some skepticism. A compromised 496 repository server may not have access to the certification 497 authorities' keys, but it can pretend valid objects have been 498 withdrawn. Therefore it may be preferred to use a strategy where 499 local copies of objects are only discarded when the RP is sure that 500 they are no longer relevant, e.g. the CA has explicitly removed the 501 objects in a recent valid manifest and revoked them in a recent valid 502 CRL (unless they have expired). 504 5. XML Schema 506 The following is a RELAX NG compact form schema describing version 1 507 of this protocol. 509 # 510 # RelaxNG schema for RPKI Repository Delta Protocol (RRDP). 511 # 513 default namespace = "http://www.ripe.net/rpki/rrdp" 514 version = xsd:positiveInteger { maxInclusive="1" } 515 serial = xsd:nonNegativeInteger 516 uri = xsd:anyURI 517 uuid = xsd:string { pattern = "[\-0-9a-fA-F]+" } 518 hash = xsd:string { pattern = "[0-9a-fA-F]+" } 519 base64 = xsd:base64Binary 521 # Notification file: lists current snapshots and deltas 523 start |= element notification { 524 attribute version { version }, 525 attribute session_id { uuid }, 526 attribute serial { serial }, 527 element snapshot { 528 attribute uri { uri }, 529 attribute hash { hash } 530 }, 531 element delta { 532 attribute serial { serial }, 533 attribute uri { uri }, 534 attribute hash { hash } 535 }* 536 } 538 # Snapshot segment: think DNS AXFR. 540 start |= element snapshot { 541 attribute version { version }, 542 attribute session_id { uuid }, 543 attribute serial { serial }, 544 element publish { 545 attribute uri { uri }, 546 base64 547 }* 548 } 550 # Delta segment: think DNS IXFR. 552 start |= element delta { 553 attribute version { version }, 554 attribute session_id { uuid }, 555 attribute serial { serial }, 556 delta_element+ 557 } 559 delta_element |= element publish { 560 attribute uri { uri }, 561 attribute hash { hash }?, 562 base64 563 } 565 delta_element |= element withdraw { 566 attribute uri { uri }, 567 attribute hash { hash } 568 } 570 # Local Variables: 571 # indent-tabs-mode: nil 572 # comment-start: "# " 573 # comment-start-skip: "#[ \t]*" 574 # End: 576 6. Security Considerations 578 TBD 580 7. IANA Considerations 582 This document has no actions for IANA. 584 8. Acknowledgements 586 TBD 588 9. Normative References 590 [I-D.ietf-sidr-publication] 591 Weiler, S., Sonalker, A., and R. Austein, "A Publication 592 Protocol for the Resource Public Key Infrastructure 593 (RPKI)", draft-ietf-sidr-publication-07 (work in 594 progress), September 2015. 596 [IANA-AD-NUMBERS] 597 "SMI Security for PKIX Access Descriptor", 598 . 601 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 602 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 603 RFC2119, March 1997, 604 . 606 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 607 Resource Identifier (URI): Generic Syntax", STD 66, RFC 608 3986, DOI 10.17487/RFC3986, January 2005, 609 . 611 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 612 Resource Certificate Repository Structure", RFC 6481, DOI 613 10.17487/RFC6481, February 2012, 614 . 616 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 617 "Manifests for the Resource Public Key Infrastructure 618 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, 619 . 621 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 622 X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/ 623 RFC6487, February 2012, 624 . 626 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object 627 Template for the Resource Public Key Infrastructure 628 (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, 629 . 631 Authors' Addresses 633 Tim Bruijnzeels 634 RIPE NCC 636 Email: tim@ripe.net 638 Oleg Muravskiy 639 RIPE NCC 641 Email: oleg@ripe.net 643 Bryan Weber 644 Cobenian 646 Email: bryan@cobenian.com 648 Rob Austein 649 Dragon Research Labs 651 Email: sra@hactrn.net 652 David Mandelberg 653 BBN Technologies 655 Email: david@mandelberg.org