idnits 2.17.1 draft-ietf-sidrops-rpki-tree-validation-00.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 (January 14, 2017) is 2659 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6485 (Obsoleted by RFC 7935) ** Obsolete normative reference: RFC 6486 (Obsoleted by RFC 9286) ** Obsolete normative reference: RFC 7730 (Obsoleted by RFC 8630) == Outdated reference: A later version (-08) exists of draft-ietf-sidr-delta-protocol-04 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIDR Operations O. Muravskiy 3 Internet-Draft T. Bruijnzeels 4 Intended status: Informational RIPE NCC 5 Expires: July 18, 2017 January 14, 2017 7 RPKI Certificate Tree Validation by the RIPE NCC RPKI Validator 8 draft-ietf-sidrops-rpki-tree-validation-00 10 Abstract 12 This document describes the approach to validate the content of the 13 RPKI certificate tree, as used by the RIPE NCC RPKI Validator. This 14 approach is independent of a particular object retrieval mechanism. 15 This allows it to be used with repositories available over the rsync 16 protocol, the RPKI Repository Delta Protocol, and repositories that 17 use a mix of both. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on July 18, 2017. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Scope of this document . . . . . . . . . . . . . . . . . . . 3 54 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. General Considerations . . . . . . . . . . . . . . . . . . . 4 56 3.1. Hash comparisons . . . . . . . . . . . . . . . . . . . . 4 57 3.2. Discovery of RPKI objects issued by a CA . . . . . . . . 4 58 3.3. Manifest entries versus repository content . . . . . . . 4 59 4. Top-down Validation of a Single Trust Anchor Certificate Tree 5 60 4.1. Fetching the Trust Anchor Certificate Using the Trust 61 Anchor Locator . . . . . . . . . . . . . . . . . . . . . 5 62 4.2. CA Certificate Validation . . . . . . . . . . . . . . . . 6 63 4.2.1. Finding the most recent valid manifest and CRL . . . 7 64 4.2.2. Manifest entries validation . . . . . . . . . . . . . 7 65 4.3. Object Store Cleanup . . . . . . . . . . . . . . . . . . 8 66 5. Remote Objects Fetcher . . . . . . . . . . . . . . . . . . . 9 67 5.1. Fetcher Operations . . . . . . . . . . . . . . . . . . . 9 68 5.1.1. Fetch repository objects . . . . . . . . . . . . . . 9 69 5.1.2. Fetch single repository object . . . . . . . . . . . 10 70 6. Local Object Store . . . . . . . . . . . . . . . . . . . . . 11 71 6.1. Store Operations . . . . . . . . . . . . . . . . . . . . 11 72 6.1.1. Store Repository Object . . . . . . . . . . . . . . . 11 73 6.1.2. Get objects by hash . . . . . . . . . . . . . . . . . 11 74 6.1.3. Get certificate objects by URI . . . . . . . . . . . 11 75 6.1.4. Get manifest objects by AKI . . . . . . . . . . . . . 11 76 6.1.5. Delete objects for a URI . . . . . . . . . . . . . . 11 77 6.1.6. Delete outdated objects . . . . . . . . . . . . . . . 11 78 6.1.7. Update object's validation time . . . . . . . . . . . 11 79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 81 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 82 9.1. Hash collisions . . . . . . . . . . . . . . . . . . . . . 12 83 9.2. Mismatch between the expected and the actual location of 84 an object in the repository . . . . . . . . . . . . . . . 12 85 9.3. Manifest content versus publication point content . . . . 13 86 9.4. Storing of a TA certificate object before its complete 87 validation . . . . . . . . . . . . . . . . . . . . . . . 13 88 9.5. Possible denial of service . . . . . . . . . . . . . . . 13 89 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 90 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 91 10.2. Informative References . . . . . . . . . . . . . . . . . 14 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 94 1. Scope of this document 96 This document describes how the RIPE NCC RPKI Validator version 2.23 97 has been implemented. Source code to this software can be found 98 here: [github]. The purpose of this document is to provide 99 transparency to users of (and contributors to) this software tool, as 100 well as serve to be subjected to scrutiny by the SIDR Operations 101 Working Group. It is not intended as a document that describes a 102 standard or best practices on how validation should be done in 103 general. 105 2. Introduction 107 In order to use information published in RPKI repositories, Relying 108 Parties (RP) need to retrieve and validate the content of 109 certificates, certificate revocation lists (CRLs), and other RPKI 110 signed objects. To validate a particular object, one must ensure 111 that all certificates in the certificate chain up to the Trust Anchor 112 (TA) are valid. Therefore the validation of a certificate tree is 113 performed top-down, starting from the TA certificate and descending 114 down the certificate chain, validating every encountered certificate 115 and its products. The result of this process is a list of all 116 encountered RPKI objects with a validity status attached to each of 117 them. These results may later be used by a Relying Party in taking 118 routing decisions, etc. 120 Traditionally RPKI data is made available to RPs through the 121 repositories [RFC6481] accessible over [rsync] protocol. Relying 122 parties are advised to keep a local copy of repository data, and 123 perform regular updates of this copy from the repository (Section 5 124 of [RFC6481]). The RPKI Repository Delta Protocol 125 [I-D.ietf-sidr-delta-protocol] introduces another method to fetch 126 repository data and keep the local copy up to date with the 127 repository. 129 This document describes how the RIPE NCC RPKI Validator discovers 130 RPKI objects to download, builds certificate paths, and validates 131 RPKI objects, independently from what repository access protocol is 132 used. To achieve this, it puts downloaded RPKI objects in an object 133 store, where each RPKI object can be found by its URI, the hash of 134 its content, value of its Authority Key Identifier (AKI) extension, 135 or a combination of these. It also keeps track of the download and 136 the validation time for every object, to decide which locally stored 137 objects are not used in the RPKI tree validation and could be 138 removed. 140 3. General Considerations 142 3.1. Hash comparisons 144 This algorithm relies on the properties of the file hash algorithm 145 (defined in [RFC6485]) to compute the hash of repository objects. It 146 assumes that any two objects for which the hash value is the same, 147 are identical. 149 The hash comparison is used when matching objects in the repository 150 with entries on the manifest (Section 4.2.2), and when looking up 151 objects in the object store (Section 6). 153 3.2. Discovery of RPKI objects issued by a CA 155 There are several possible ways of discovering products of a CA 156 certificate: one could use all objects located in a repository 157 directory designated as a publication point for a CA, or only objects 158 mentioned on the manifest located at that publication point (see 159 Section 6 of [RFC6486]), or use all objects whose AKI extension 160 matches the Subject Key Identifier (SKI) extension (Section 4.2.1 of 161 [RFC5280]) of a CA certificate. 163 For publication points whose content is consistent with the manifest 164 and issuing certificate all of these approaches should produce the 165 same result. For inconsistent publication points the results might 166 be different. Section 6 of [RFC6486] leaves the decision on how to 167 deal with inconsistencies to a local policy. 169 The implementation described here does not rely on content of 170 repository directories, but uses the Authority Key Identifier (AKI) 171 extension of a manifest and a certificate revocation list (CRL) to 172 find in an object store (Section 6) a manifest and a CRL issued by a 173 particular Certification Authority (CA) (see Section 4.2.1). It 174 further uses the hashes of manifest's fileList entries (Section 4.2.1 175 of [RFC6486]) to find other objects issued by the CA, as described in 176 Section 4.2.2. 178 3.3. Manifest entries versus repository content 180 Since the current set of RPKI standards requires use of the manifest 181 [RFC6486] to describe the content of a publication point, this 182 implementation requires strict consistency between the publication 183 point content and manifest content. (This is a more stringent 184 requirement than established in [RFC6486].) Therefore it will not 185 process objects that are found in the publication point but do not 186 match any of the entries of that publication point's manifest (see 187 Section 4.2.2). It will also issue warnings for all found 188 mismatches, so that the responsible operators could be made aware of 189 inconsistencies and fix them. 191 4. Top-down Validation of a Single Trust Anchor Certificate Tree 193 1. The validation of a Trust Anchor (TA) certificate tree starts 194 from its TA certificate. To retrieve the TA certificate, a Trust 195 Anchor Locator (TAL) object is used, as described in Section 4.1. 197 2. If the TA certificate is retrieved, it is validated according to 198 Section 7 of [RFC6487] and Section 2.2 of [RFC7730]. Otherwise 199 the validation of certificate tree is aborted and an error is 200 issued. 202 3. If the TA certificate is valid, then all its subordinate objects 203 are validated as described in Section 4.2. Otherwise the 204 validation of certificate tree is aborted and an error is issued. 206 4. For each repository object that was validated during this 207 validation run, its validation timestamp is updated in the object 208 store (see Section 6.1.7). 210 5. Outdated objects are removed from the store as described in 211 Section 4.3. This completes the validation of the TA certificate 212 tree. 214 4.1. Fetching the Trust Anchor Certificate Using the Trust Anchor 215 Locator 217 The following steps are performed in order to fetch a Trust Anchor 218 Certificate: 220 1. (Optional) If the Trust Anchor Locator contains a "prefetch.uris" 221 field, pass the URIs contained in that field to the fetcher (see 222 Section 5.1.1). (This field is a non-standard addition to the 223 TAL format. It helps fetching non-hierarchical rsync 224 repositories more efficiently.) 226 2. Extract the first TA certificate URI from the TAL's URI section 227 (see Section 2.1 of [RFC7730]) and pass it to the object fetcher 228 (Section 5.1.2). If the fetcher returns an error, repeat this 229 step for every URI in the URI section, until no error is 230 encountered, or no more URIs left. 232 3. Retrieve from the object store (see Section 6.1.3) all 233 certificate objects, for which the URI matches the URI extracted 234 from the TAL in the previous step, and the public key matches the 235 subjectPublicKeyInfo extension of the TAL (see Section 2.1 of 236 [RFC7730]). 238 4. If no, or more than one such objects are found, issue an error 239 and abort certificate tree validation process with an error. 240 Otherwise, use the single found object as the Trust Anchor 241 certificate. 243 4.2. CA Certificate Validation 245 The following steps describe the validation of a single CA Resource 246 certificate: 248 1. If both the caRepository (Section 4.8.8.1 of [RFC6487]), and the 249 id-ad-rpkiNotify (Section 3.2 of [I-D.ietf-sidr-delta-protocol]) 250 SIA pointers are present in the CA certificate, use a local 251 policy to determine which pointer to use. Extract the URI from 252 the selected pointer and pass it to the object fetcher (see 253 Section 5.1.1). 255 2. For the CA certificate, find the current manifest and certificate 256 revocation list (CRL), using the procedure described in 257 Section 4.2.1. If no such manifest and CRL could be found, stop 258 validation of this certificate, consider it invalid, and issue an 259 error. 261 3. Compare the URI found in the id-ad-rpkiManifest field 262 (Section 4.8.8.1 of [RFC6487]) of the SIA extension of the 263 certificate with the URI of the manifest found in the previous 264 step. If they are different, issue a warning, but continue 265 validation process using this manifest object. (This warning 266 indicates that there is a mismatch between the expected and the 267 actual location of an object in a repository. See Section 9 for 268 the explanation of this mismatch and the decision taken.) 270 4. Perform manifest entries discovery and validation as described in 271 Section 4.2.2. 273 5. Validate all resource certificate objects found on the manifest, 274 using the CRL object found on the manifest, according to 275 Section 7 of [RFC6487]. 277 6. Validate all ROA objects found on the manifest, using the CRL 278 object found on the manifest, according to Section 4 of 279 [RFC6482]. 281 7. Validate all Ghostbusters Record objects found on the manifest, 282 using the CRL object found on the manifest, according to 283 Section 7 of [RFC6493]. 285 8. For every valid CA certificate object found on the manifest, 286 apply the procedure described in this section (Section 4.2), 287 recursively, provided that this CA certificate (identified by its 288 SKI) has not yet been validated during current tree validation 289 run. 291 4.2.1. Finding the most recent valid manifest and CRL 293 1. Fetch from the store (see Section 6.1.4) all objects of type 294 manifest, whose certificate's AKI extension matches the SKI of 295 the current CA certificate. If no such objects are found, stop 296 processing the current CA certificate and issue an error. 298 2. Find among found objects the manifest object with the highest 299 manifestNumber field (Section 4.2.1 of [RFC6486]), for which all 300 following conditions are met: 302 * There is only one entry in the manifest for which the store 303 contains exactly one object of type CRL, the hash of which 304 matches the hash of the entry. 306 * The manifest's certificate AKI equals the above CRL's AKI. 308 * The above CRL is a valid object according to Section 6.3 of 309 [RFC5280]. 311 * The manifest is a valid object according to Section 4.4 of 312 [RFC6486], and its EE certificates is not in the CRL found 313 above. 315 3. If there is an object that matches above criteria, consider this 316 object to be the valid manifest, and the CRL found at the 317 previous step - the valid CRL for the current CA certificate's 318 publication point. 320 4. Report an error for every other manifest with a number higher 321 than the number of the valid manifest. 323 4.2.2. Manifest entries validation 325 For every entry in the manifest object: 327 1. Construct an entry's URI by appending the entry name to the 328 current CA's publication point URI. 330 2. Get all objects from the store whose hash attribute equals 331 entry's hash (see Section 6.1.2). 333 3. If no such objects are found, issue an error for this manifest 334 entry and progress to the next entry. This case indicates that 335 the repository does not have an object at the location listed in 336 the manifest, or that the object's hash does not match the hash 337 listed in the manifest. 339 4. For every found object, compare its URI with the URI of the 340 manifest entry. 342 * For every object with a non-matching URI issue a warning. 343 This case indicates that the object from the manifest entry is 344 (also) found at a different location in a (possibly different) 345 repository. 347 * If no objects with a matching URI are found, issue a warning. 348 This case indicates that there is no object found in the 349 repository at the location listed in the manifest entry (but 350 there is at least one matching object found at a different 351 location). 353 5. Use all found objects for further validation as per Section 4.2. 355 Please note that the above steps will not reject objects whose hash 356 matches the hash listed in the manifest, but the URI does not. See 357 Section 9.2 for additional information. 359 4.3. Object Store Cleanup 361 At the end of every TA tree validation some objects are removed from 362 the store using the following rules: 364 1. Given all objects that were encountered during the current 365 validation run, remove from the store (Section 6.1.6) all objects 366 whose URI attribute matches the URI of one of the encountered 367 objects, but the content's hash is different. This removes from 368 the store objects that were replaced in the repository by their 369 newer versions with the same URIs. 371 2. Remove from the store all objects that were last encountered 372 during validation a long time ago (as specified by the local 373 policy). This removes objects that do not appear on any valid 374 manifest anymore (but possibly are still published in a 375 repository). 377 3. Remove from the store all objects that were downloaded recently 378 (as specified by the local policy), but have never been used in 379 the validation process. This removes objects that have never 380 appeared on any valid manifest. 382 Shortening the time interval used in step 2 will free more disk space 383 used by the store, at the expense of downloading removed objects 384 again if they are still published in the repository. 386 Extending the time interval used in step 3 will prevent repeated 387 downloads of repository objects, with the risk that such objects, if 388 created massively by mistake or by an adversary, will fill up local 389 disk space, if they are not cleaned up promptly. 391 5. Remote Objects Fetcher 393 The fetcher is responsible for downloading objects from remote 394 repositories (described in Section 3 of [RFC6481]) using rsync 395 protocol ([rsync]), or RPKI Repository Delta Protocol (RRDP) 396 ([I-D.ietf-sidr-delta-protocol]). 398 5.1. Fetcher Operations 400 For every visited URI the fetcher keeps track of the last time a 401 successful fetch occurred. 403 5.1.1. Fetch repository objects 405 This operation receives one parameter - a URI. For an rsync 406 repository this URI points to a directory. For an RRDP repository it 407 points to the repository's notification file. 409 The fetcher performs following steps: 411 1. If data associated with the URI has been downloaded recently (as 412 specified by the local policy), skip following steps. 414 2. Download remote objects using the URI provided (for an rsync 415 repository use recursive mode). If the URI contains schema 416 "https" and download has failed, issue a warning, replace "https" 417 schema in the URI by "http", and try to download objects again, 418 using the resulting URI. 420 3. If remote objects can not be downloaded, issue an error and skip 421 following steps. 423 4. Perform syntactic verification of fetched objects. The type of 424 every object (certificate, manifest, CRL, ROA, or Ghostbusters 425 record), is determined based on the object's filename extension 426 (.cer, .mft, .crl, .roa, and .gbr, respectively). The syntax of 427 the object is described in Section 4 of [RFC6487] for resource 428 certificates, step 1 of Section 3 of [RFC6488] for signed 429 objects, and specifically, Section 4 of [RFC6486] for manifests, 430 [RFC5280] for CRLs, Section 3 of [RFC6482] for ROAs, and 431 Section 5 of [RFC6493] for Ghostbusters records. 433 5. Put every downloaded and syntactically correct object in the 434 object store (Section 6.1.1). 436 The time interval used in the step 1 should be chosen based on the 437 acceptable delay in receiving repository updates. 439 5.1.2. Fetch single repository object 441 This operation receives one parameter - a URI that points to an 442 object in a repository. 444 The fetcher performs following operations: 446 1. Download remote object using the URI provided. If the URI 447 contains "https" schema and download failed, issue a warning, 448 replace "https" schema in the URI by "http", and try to download 449 the object using the resulting URI. 451 2. If the remote object can not be downloaded, issue an error and 452 skip following steps. 454 3. Perform syntactic verification of fetched object. The type of 455 object (certificate, manifest, CRL, ROA, or Ghostbusters record), 456 is determined based on the object's filename extension (.cer, 457 .mft, .crl, .roa, and .gbr, respectively). The syntax of the 458 object is described in Section 4 of [RFC6487] for resource 459 certificates, step 1 of Section 3 of [RFC6488] for signed 460 objects, and specifically, Section 4 of [RFC6486] for manifests, 461 [RFC5280] for CRLs, Section 3 of [RFC6482] for ROAs, and 462 Section 5 of [RFC6493] for Ghostbusters records. 464 4. If the downloaded object is not syntactically correct, issue an 465 error and skip further steps. 467 5. Delete all objects from the object store (Section 6.1.5) whose 468 URI matches the URI given. 470 6. Put the downloaded object in the object store (Section 6.1.1). 472 6. Local Object Store 474 6.1. Store Operations 476 6.1.1. Store Repository Object 478 Put given object in the store, along with its type, URI, hash, and 479 AKI, if there is no record with the same hash and URI fields. Note 480 that in the (unlikely) event of hash collision the given object will 481 not replace the object in the store. 483 6.1.2. Get objects by hash 485 Retrieve all objects from the store whose hash attribute matches the 486 given hash. 488 6.1.3. Get certificate objects by URI 490 Retrieve from the store all objects of type certificate, whose URI 491 attribute matches the given URI. 493 6.1.4. Get manifest objects by AKI 495 Retrieve from the store all objects of type manifest, whose AKI 496 attribute matches the given AKI. 498 6.1.5. Delete objects for a URI 500 For a given URI, delete all objects in the store with matching URI 501 attribute. 503 6.1.6. Delete outdated objects 505 For a given URI and a list of hashes, delete all objects in the store 506 with matching URI, whose hash attribute is not in the given list of 507 hashes. 509 6.1.7. Update object's validation time 511 For all objects in the store whose hash attribute matches the given 512 hash, set the last validation time attribute to the given timestamp. 514 7. Acknowledgements 516 This document describes the algorithm as it is implemented by the 517 software development team at the RIPE NCC. The authors would also 518 like to acknowledge contributions by Carlos Martinez, Andy Newton, 519 Rob Austein, and Stephen Kent. 521 8. IANA Considerations 523 This document has no actions for IANA. 525 9. Security Considerations 527 9.1. Hash collisions 529 This implementation will not detect possible hash collisions in the 530 hashes of repository objects (calculated using the file hash 531 algorithm specified in [RFC6485]). It considers objects with same 532 hash values as identical. 534 9.2. Mismatch between the expected and the actual location of an object 535 in the repository 537 According to Section 2 of [RFC6481], all objects issued by a 538 particular CA certificate are expected to be located in one 539 repository publication point, specified in the SIA extension of that 540 CA certificate. The manifest object issued by that CA certificate 541 enumerates all other issued objects, listing their file names and 542 content hashes. 544 However, it is possible that an object whose content hash matches the 545 hash listed in the manifest, has either a different file name, or is 546 located at a different publication point in a repository. 548 On the other hand, all RPKI objects, either explicitly or within 549 their embedded EE certificate, have an Authority Key Identifier 550 extension that contains the key identifier of their issuing CA 551 certificate. Therefore it is always possible to perform an RPKI 552 validation of the object whose expected location does not match its 553 actual location, provided that the certificate that matches the AKI 554 of the object in question is known to the system that performs 555 validation. 557 In case of a mismatch described above this implementation will not 558 exclude an object from further validation merely because it's actual 559 location or file name does not match the expected location or file 560 name. This decision was chosen because the actual location of a file 561 in a repository is taken from the repository retrieval mechanism, 562 which, in case of an rsync repository, does not provide any 563 cryptographic security, and in case of an RRDP repository, provides 564 only a transport layer security, with the fallback to unsecured 565 transport. On the other hand, the manifest is an RPKI signed object, 566 and its content could be verified in the context of the RPKI 567 validation. 569 9.3. Manifest content versus publication point content 571 This algorithm uses the content of a manifest object to determine 572 other objects issued by a CA certificate. It verifies that the 573 manifest is located in the publication point designated in the CA 574 Certificate's SIA extension. However, if there are other (not listed 575 in the manifest) objects located in the same publication point 576 directory, they are ignored, even if they might be valid and issued 577 by the same CA certificate as the manifest. (This behavior is 578 allowed, but not required, by [RFC6486].) 580 9.4. Storing of a TA certificate object before its complete validation 582 When fetching and storing a TA certificate to the object store, only 583 a syntactic validation of a downloaded object is performed before 584 newly downloaded object replaces the previously downloaded object in 585 the object store (see Section 5.1.2). If an attacker will be able to 586 replace a genuine TA certificate by a syntactically valid certificate 587 object (either by manipulating the content of a repository, or by a 588 man-in-the-middle attack), this implementation will discard 589 previously downloaded genuine object, and replace it by a false 590 object. Such false object will be detected later, but the validation 591 of the whole RPKI tree under this TA will be aborted, as described in 592 Section 4. 594 9.5. Possible denial of service 596 The store cleanup procedure described in Section 4.3 tries to 597 minimise removal and subsequent re-fetch of objects that are 598 published in a repository, but not used in the validation. Once such 599 objects are removed from the remote repository, they will be 600 discarded from the local object store after a period of time 601 specified by a local policy. By generating an excessive amount of 602 syntactically valid RPKI objects, a man-in-the-middle attack between 603 a validating tool and a repository could force an implementation to 604 fetch and store those objects in the object store before they are 605 validated and discarded, leading to an out-of-memory or out-of-disk- 606 space conditions, and, subsequently, a denial of service. 608 10. References 610 10.1. Normative References 612 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 613 Housley, R., and W. Polk, "Internet X.509 Public Key 614 Infrastructure Certificate and Certificate Revocation List 615 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 616 . 618 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 619 Resource Certificate Repository Structure", RFC 6481, 620 DOI 10.17487/RFC6481, February 2012, 621 . 623 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 624 Origin Authorizations (ROAs)", RFC 6482, 625 DOI 10.17487/RFC6482, February 2012, 626 . 628 [RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for 629 Use in the Resource Public Key Infrastructure (RPKI)", 630 RFC 6485, DOI 10.17487/RFC6485, February 2012, 631 . 633 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 634 "Manifests for the Resource Public Key Infrastructure 635 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, 636 . 638 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 639 X.509 PKIX Resource Certificates", RFC 6487, 640 DOI 10.17487/RFC6487, February 2012, 641 . 643 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object 644 Template for the Resource Public Key Infrastructure 645 (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, 646 . 648 [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) 649 Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493, 650 February 2012, . 652 [RFC7730] Huston, G., Weiler, S., Michaelson, G., and S. Kent, 653 "Resource Public Key Infrastructure (RPKI) Trust Anchor 654 Locator", RFC 7730, DOI 10.17487/RFC7730, January 2016, 655 . 657 10.2. Informative References 659 [github] "RIPE NCC RPKI Validator on GitHub", . 662 [I-D.ietf-sidr-delta-protocol] 663 Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein, 664 "RPKI Repository Delta Protocol", draft-ietf-sidr-delta- 665 protocol-04 (work in progress), September 2016. 667 [rsync] "Rsync home page", . 669 Authors' Addresses 671 Oleg Muravskiy 672 RIPE NCC 674 Email: oleg@ripe.net 676 Tim Bruijnzeels 677 RIPE NCC 679 Email: tim@ripe.net