idnits 2.17.1 draft-kent-sidrops-8211bis-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 (July 25, 2020) is 1364 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIDROPS S. Kent 3 Internet-Draft Independent 4 Intended status: Informational D. Ma 5 Expires: January 26, 2021 ZDNS 6 July 25, 2020 8 Adverse Actions by a Certification Authority (CA) or Repository Manager 9 in the Resource Public Key Infrastructure (RPKI) 10 draft-kent-sidrops-8211bis-00 12 Abstract 14 This document analyzes actions by or against a Certification 15 Authority (CA) or an independent repository manager in the RPKI that 16 can adversely affect the Internet Number Resources (INRs) associated 17 with that CA or its subordinate CAs. The analysis is done from the 18 perspective of an affected INR holder. The analysis is based on 19 examination of the data items in the RPKI repository, as controlled 20 by a CA (or an independent repository manager) and fetched by Relying 21 Parties (RPs). The analysis does not purport to be comprehensive; it 22 does represent an orderly way to analyze a number of ways that errors 23 by or attacks against a CA or repository manager can affect the RPKI 24 and routing decisions based on RPKI data. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 26, 2021. 43 Copyright Notice 45 Copyright (c) 2020 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Analysis of RPKI Repository Objects . . . . . . . . . . . . . 3 62 2.1. CA Certificates . . . . . . . . . . . . . . . . . . . . . 5 63 2.2. Manifest . . . . . . . . . . . . . . . . . . . . . . . . 9 64 2.3. Certificate Revocation List . . . . . . . . . . . . . . . 11 65 2.4. ROA . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 66 2.5. Ghostbusters Record . . . . . . . . . . . . . . . . . . . 16 67 2.6. Router Certificates . . . . . . . . . . . . . . . . . . . 17 68 3. Analysis of Actions Relative to Scenarios . . . . . . . . . . 18 69 3.1. Scenario A . . . . . . . . . . . . . . . . . . . . . . . 20 70 3.2. Scenario B . . . . . . . . . . . . . . . . . . . . . . . 20 71 3.3. Scenario C . . . . . . . . . . . . . . . . . . . . . . . 20 72 3.4. Scenario D . . . . . . . . . . . . . . . . . . . . . . . 21 73 4. Security Considerations . . . . . . . . . . . . . . . . . . . 21 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 75 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 77 7.1. Normative References . . . . . . . . . . . . . . . . . . 22 78 7.2. Informative References . . . . . . . . . . . . . . . . . 24 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 81 1. Introduction 83 In the context of this document, any change to the Resource Public 84 Key Infrastructure (RPKI) [RFC6480] that diminishes the set of 85 Internet Number Resources (INRs) associated with an INR holder, and 86 that is contrary to the holder's wishes, is termed "adverse". This 87 analysis is done from the perspective of an affected INR holder. An 88 action that results in an adverse charge (as defined above) may be 89 the result of an attack on a CA [RFC7132], an error by a CA, or an 90 error by or an attack on a repository operator. Note that the CA 91 that allocated the affected INRs may be acting in accordance with 92 established policy; thus, the change may be contractually justified 93 even though viewed as adverse by the INR holder. This document 94 examines the implications of adverse actions within the RPKI with 95 respect to INRs, irrespective of the cause of the actions. 97 Additionally, when a Route Origin Authorization (ROA) or router 98 certificate is created that "competes" with an existing ROA or router 99 certificate (respectively), the creation of the new ROA or router 100 certificate may be adverse. (A newer ROA competes with an older ROA 101 if the newer ROA points to a different Autonomous System Number 102 (ASN), contains the same or a more specific prefix, and is issued by 103 a different CA. A newer router certificate competes with an older 104 router certificate if the newer one contains the same ASN, contains a 105 different public key, and is issued by a different CA.) Note that 106 transferring resources or changing of upstream providers may yield 107 competing ROAs and/or router certificates under some circumstances. 108 Thus, not all instances of competition are adverse actions. 110 As noted above, adverse changes to RPKI data may arise due to several 111 types of causes. A CA may make a mistake in managing the RPKI 112 objects it signs, or it may be subject to an attack. If an attack 113 allows an adversary to use the private key of that CA to sign RPKI 114 objects, then the effect is analogous to the CA making mistakes. 115 There is also the possibility that a CA or repository operator may be 116 subject to legal measures that compel them to make adverse changes to 117 RPKI data. In many cases, such actions may be hard to distinguish 118 from mistakes or attacks, other than with respect to the time 119 required to remedy the adverse action. (Presumably, the CA will take 120 remedial action when a mistake or an attack is detected, so the 121 effects are similar in these cases. If a CA has been legally 122 compelled to effect an adverse change, remediation will likely not be 123 swift.) 125 This document analyzes the various types of actions by a CA (or an 126 independent repository operator) that can adversely affect the INRs 127 associated with that CA, as well as the INRs of subordinate CAs. The 128 analysis is based on examination of the data items in the RPKI 129 repository, as controlled by a CA (or an independent repository 130 operator) and fetched by RPs. 132 2. Analysis of RPKI Repository Objects 134 This section enumerates the RPKI repository system objects and 135 examines how changes to them affect Route Origin Authorizations 136 (ROAs) and router certificate validation. Identifiers are assigned 137 to errors for reference by later sections of this document. Note 138 that not all adverse actions may be encompassed by this taxonomy. 140 The RPKI repository [RFC6481] contains a number of (digitally signed) 141 objects that are fetched and processed by RPs. Until the deployment 142 of BGPsec [RFC8205], the principal goal of the RPKI is to enable an 143 RP to validate ROAs [RFC6482]. A ROA binds address space to an ASN. 144 A ROA can be used to verify BGP announcements with respect to route 145 origin [RFC6483]. The most important objects in the RPKI for origin 146 validation are ROAs; all of the other RPKI objects exist to enable 147 the validation of ROAs in a fashion consistent with the INR 148 allocation system. Thus, errors that result in changes to a ROA, or 149 to RPKI objects needed to validate a ROA, can cause RPs to reach 150 different (from what was intended) conclusions about the validity of 151 the bindings expressed in a ROA. 153 When BGPsec is deployed, router certificates [RFC8209] will be added 154 to repository publication points. These are end entity (EE) 155 certificates used to verify signatures applied to BGP update data and 156 to enable path validation [RFC8205]. Router certificates are as 157 important to path validation as ROAs are to origin validation. 159 The objects contained in the RPKI repository are of two types: 160 conventional PKI objects (certificates and Certificate Revocation 161 Lists (CRLs)) and RPKI-specific signed objects. The latter make use 162 of a common encapsulation format [RFC6488] based on the Cryptographic 163 Message Syntax (CMS) [RFC5652]. A syntax error in this common format 164 will cause an RP to reject the object, e.g., a ROA or manifest, as 165 invalid. 167 Adverse actions take several forms: 169 * Deletion (D) is defined as removing an object from a 170 publication point, without the permission of the INR holder. 172 * Suppression (S) is defined as not deleting an object, or not 173 publishing an object, as intended by an INR holder. This 174 action also includes retaining a prior version of an object in 175 a publication point when a newer version is available for 176 publication. 178 * Corruption (C) is defined as modification of a signed object in 179 a fashion not requiring access to the private key used to sign 180 the object. Thus, a corrupted object will not carry a valid 181 signature. Implicitly, the corrupted object replaces the 182 legitimate version. 184 * Modification (M) is defined as publishing a syntactically 185 valid, verifiable version of an object that differs from the 186 (existing) version authorized by the INR holder. Implicitly, 187 the legitimate version of the affected object is deleted and 188 replaced by the modified object. 190 * Revocation (R) is defined as revoking a certificate (EE or CA) 191 by placing its Serial Number on the appropriate CRL, without 192 authorization of the INR holder. 194 * Injection (I) is defined as introducing an instance of a signed 195 object into a publication point (without authorization of the 196 INR holder). It assumes that the signature on the object will 197 be viewed as valid by RPs. 199 The first three of these actions (deletion, suppression, and 200 corruption) can be effected by any entity that manages the 201 publication point of the affected INR holder or by the CA (due to an 202 error or compromise). Also, an entity with the ability to act as a 203 man-in-the-middle between an RP and a repository can effect these 204 actions with respect to the RP in question. 206 The latter three actions (modification, revocation, and injection) 207 nominally require access to the private key of the INR holder. 209 All six of these actions also can be effected by a parent CA. A 210 parent CA could reissue the INR holder's CA certificate, but with a 211 different public key, matching a private key to which the parent CA 212 has access. The CA could generate new signed objects using the 213 private key associated with the reissued certificate and publish 214 these objects at a location of its choosing. 216 Most of these actions may be performed independently or in 217 combination with one another. For example, a ROA may be revoked and 218 deleted or revoked and replaced with a modified ROA. Where 219 appropriate, the analysis of adverse actions will distinguish between 220 individual actions, or combinations thereof, that yield different 221 outcomes for RPs. Recall that the focus of the analysis is the 222 impact on ROAs and router certificates, with respect to RP 223 processing. 225 The following sections examine how the actions enumerated above 226 affect objects in the RPKI repository system. Each action is 227 addressed in order (deletion, suppression, corruption, modification, 228 revocation, and injection) for each object, making it easy to see how 229 each action has been considered with regard to each object. (For the 230 Ghostbusters Record [RFC6493], we condensed the discussion of the 231 actions because the impact is the same in each case.) 233 2.1. CA Certificates 235 Every INR holder is represented by one or more CA certificates. An 236 INR holder has multiple CA certificates if it holds resources 237 acquired from different sources. Also, every INR holder has more 238 than one CA certificate during key rollover [RFC6489] and algorithm 239 rollover [RFC6916]. 241 If a publication point is not a "leaf" in the RPKI hierarchy, then 242 the publication point will contain one or more CA certificates, each 243 representing a subordinate CA. Each subordinate CA certificate 244 contains a Subject Information Access (SIA) pointer to the 245 publication point where the signed objects associated with that CA 246 can be found [RFC6487]. 248 A CA certificate is a complex data structure; thus, errors in that 249 structure may have different implications for RPs depending on the 250 specific data that is in error. 252 Adverse actions against a CA certificate can cause the following 253 errors: 255 A-1.1 Deletion 257 A-1.1.1 Deletion of a CA certificate would cause an RP to 258 not be able to locate signed objects generated by 259 that CA, except those that have been cached by the 260 RP. Thus, an RP would be unaware of changed or 261 new (issued after the cached data) INR bindings 262 asserted in subordinate ROAs, and the RP would be 263 unable to validate new or changed router 264 certificates. If the missed objects were intended 265 to replace ROAs or router certificates prior to 266 expiration, then when those objects expire, RPs 267 may cease to view them as valid. As a result, 268 valid routes may be viewed as NotFound or Invalid. 270 A-1.2 Suppression 272 A-1.2.1 If publication of a CA certificate is suppressed, 273 the impact depends on what changes appeared in the 274 suppressed certificate. If the SIA value changed, 275 the effect would be the same as in A-1.1 or 276 A-1.4.3. If the [RFC3779] extensions in the 277 suppressed certificate changed, the impact would 278 be the same as in A-1.4.1. If the Authority 279 Information Access (AIA) extension changed in the 280 suppressed certificate, the impact would be the 281 same as in A-1.4.4. Suppression of a renewed/re- 282 issued certificate may cause an old certificate to 283 expire and thus be rejected by RPs. 285 A-1.3 Corruption 287 A-1.3.1 Corruption of a CA certificate will cause it to be 288 rejected by RPs. In turn, this may cause 289 subordinate signed objects to become invalid. An 290 RP that has cached the subtree under the affected 291 CA certificate may continue to view it as valid, 292 until objects expire. But changed or new objects 293 might not be retrieved, depending on details of 294 the design of the RP software. Thus, this action 295 may be equivalent to suppressing changes to the 296 affected subtree. 298 A-1.4 Modification 300 A-1.4.1 If a CA certificate is modified but still conforms 301 to the RPKI certificate profile [RFC7935], it will 302 be accepted by RPs. If an [RFC3779] extension in 303 this certificate is changed to exclude INRs that 304 were previously present, then subordinate signed 305 objects will become invalid if they rely on the 306 excised INRs. If these objects are CA 307 certificates, their subordinate signed objects 308 will be treated as invalid. If the objects are 309 ROAs, the binding expressed by the affected ROAs 310 will be ignored by RPs. If the objects are router 311 certificates, BGPsec_PATH attributes [RFC8205] 312 verifiable under these certificates will be 313 considered invalid. 315 A-1.4.2 If the SIA extension of a CA certificate is 316 modified to refer to another publication point, 317 this will cause an RP to look at another location 318 for subordinate objects. This could cause RPs to 319 not acquire the objects that the INR holder 320 intended to be retrieved -- manifests, ROAs, 321 router certificates, Ghostbuster Records, or any 322 subordinate CA certificates associated with that 323 CA. If the objects at this new location contain 324 invalid signatures or appear to be corrupted, they 325 may be rejected. In this case, cached versions of 326 the objects may be viewed as valid by an RP, until 327 they expire. If the objects at the new location 328 have valid signatures and pass path validation 329 checks, they will replace the cached objects, 330 effectively replacing the INR holder's objects. 332 A-1.4.3 If the AIA extension in a CA certificate is 333 modified, it would point to a different CA 334 certificate, not the parent CA certificate. This 335 extension is used only for path discovery, not 336 path validation. Path discovery in the RPKI is 337 usually performed on a top-down basis, starting 338 with trust anchors (TAs) and recursively 339 descending the RPKI hierarchy. Thus, there may be 340 no impact on the ability of clients to acquire and 341 validate certificates if the AIA is modified. 343 A-1.4.4 If the Subject Public Key Info (and Subject Key 344 Identifier extension) in a CA certificate is 345 modified to contain a public key corresponding to 346 a private key held by the parent, the parent could 347 sign objects as children of the affected CA 348 certificate. With this capability, the parent 349 could replace the INR holder, issuing new signed 350 objects that would be accepted by RPs (as long as 351 they do not violate the path validation criteria). 352 This would enable the parent to effect 353 modification, revocation, and injection actions 354 against all of the objects under the affected CA 355 certificate, including subordinate CA 356 certificates. (Note that key rollover also yields 357 a new CA certificate. However, the new 358 certificate will coexist with the old one for a 359 while, which may help distinguish this legitimate 360 activity from an adverse action.) 362 A-1.5 Revocation 364 A-1.5.1 If a CA certificate is revoked, an RP will treat 365 as invalid all subordinate signed objects, both 366 immediate and transitive. The effects are 367 essentially the same as described in A-3.4.2. 369 A-1.6 Injection 371 A-1.6.1 If a CA certificate is injected, the impact will 372 depend on the data contained in the injected 373 certificate. Changes will generally be equivalent 374 to modification actions as described in A-1.4. 376 2.2. Manifest 378 Each repository publication point contains a manifest 379 [I-D.ymbk-sidrops-6486bis]. The RPKI incorporates manifests to 380 enable RPs to detect suppression and/ or substitution of (more 381 recent) publication point objects, as the result of a mistake or 382 attack. A manifest enumerates (by filename) all of the other signed 383 objects at the publication point. The manifest also contains a hash 384 of each enumerated file to enable an RP to determine if the named 385 file content matches what the INR holder identified in the manifest. 387 A manifest is an RPKI signed object, so it is validated as per 388 [RFC6488]. If a manifest is modified in a way that causes any of 389 these checks to fail, the manifest will be considered invalid. 390 Suppression of a manifest itself (indicated by a stale manifest) can 391 also cause an RP to not detect suppression of other signed objects at 392 the publication point. (Note that if a manifest's EE certificate 393 expires at the time that the manifest is scheduled to be replaced, a 394 delay in publication will cause the manifest to become invalid, not 395 merely stale. This very serious outcome should be avoided, e.g., by 396 making the manifest EE certificate's notAfter value the same as that 397 of the CA certificate under which it was issued). 399 Corruption, suppression, modification, or deletion of a manifest will 400 significantly affect RP processing of other publication point 401 objects, as required in [I-D.ymbk-sidrops-6486bis]. That document 402 requires RP implementations to ignore objects that are present at a 403 publication point but not listed in a valid manifest. Thus, the 404 following actions against a manifest can impact RP processing: 406 A-2.1 Deletion 408 A-2.1.1 A manifest may be deleted from the indicated 409 publication point. In this circumstance, an RP 410 will rely on cached (not stale) objects from the 411 publication point until a successful fetch is 412 effected. This action is equivalent to 413 suppression of publication of the objects that are 414 not recognized by RPs, because the new objects are 415 not present in the old manifest. For example, a 416 new ROA could be ignored (A-1.2). A newly issued 417 CA certificate might be ignored (A-1.1). A 418 subordinate CA certificate that was revoked might 419 still be viewed as valid by RPs (A-4.1). A new or 420 changed router certificate might be ignored 421 (A-6.2) as would a revised Ghostbusters Record 422 (A-4.1). 424 A-2.2 Suppression 426 A-2.2.1 Publication of a newer manifest may be suppressed. 427 Suppression of a newer manifest generally will 428 cause an RP to rely on a cached manifest (if 429 available and not stale). The older manifest 430 would not enumerate newly added objects; thus, 431 those objects might be ignored by an RP, which is 432 equivalent to deletion of those objects (A-1.1, 433 A-3.1, A-4.1, A-5.1, and A-6.1). 435 A-2.3 Corruption 437 A-2.3.1 A manifest may be corrupted. A corrupted manifest 438 will be rejected by RPs. This may cause RPs to 439 rely on a previous manifest, with the same impact 440 as A-2.2. If an RP does not revert to using a 441 cached manifest, the impact of this action is very 442 severe, i.e., all publication point objects will 443 probably be viewed as invalid, including 444 subordinate tree objects. This is equivalent to 445 revoking or deleting an entire subtree (see 446 A-4.4.2). 448 A-2.4 Modification 450 A-2.4.1 A manifest may be modified to remove one or more 451 objects. Because the modified manifest is viewed 452 as valid by RPs, any objects that were removed may 453 be ignored by RPs. This is equivalent to deleting 454 these objects from the repository. The impact of 455 this action will vary, depending on which objects 456 are (effectively) removed. However, the impact is 457 equivalent to deletion of the object in question, 458 (A-1.1, A-3.1, A-4.1, A-5.1, and A-6.1). 460 A-2.4.2 A manifest may be modified to add one or more 461 objects. If an added object has a valid signature 462 (and is not expired), it will be accepted by RPs 463 and processed accordingly. If the added object 464 was previously deleted by the INR holder, this 465 action is equivalent to suppressing deletion of 466 that object. If the object is newly created or 467 modified, it is equivalent to a modification or 468 injection action for the type of object in 469 question and is thus discussed in the relevant 470 section for those actions for the object type. 472 A-2.4.3 A manifest may be modified to list an incorrect 473 hash for one or more objects. An object with an 474 incorrect hash will be ignored by an RP. Thus, 475 the effect may be equivalent to corrupting the 476 object in question, although the error reported by 477 RP software would differ from that reported for a 478 corrupted object. (The manifest specifications 479 require an RP to ignore an object that has a valid 480 signature and that is not revoked or expired, but 481 for which the hash doesn't match the object.) 483 A-2.5 Revocation 485 A-2.5.1 A manifest may be revoked (by including its EE 486 certificate on the CRL for the publication point). 487 A revoked manifest will be rejected by an RP; the 488 RP would revert to an older (cached, but not 489 stale) manifest. The implications for RPs are 490 equivalent to A-2.1 with regard to new/changed 491 objects. 493 A-2.6 Injection 495 A-2.6.1 A manifest representing different objects may be 496 injected into a publication point. The effects 497 are the same as for a modified manifest (see 498 above). The impact will depend on the type of the 499 affected object(s) and is thus discussed in the 500 relevant section(s) for each object type. 502 2.3. Certificate Revocation List 504 Each publication point contains a CRL that enumerates revoked (not 505 yet expired) certificates issued by the CA associated with the 506 publication point [RFC6481]. 508 Adverse actions against a CRL can cause the following errors: 510 A-3.1 Deletion 512 A-3.1.1 If a CRL is deleted, RPs will continue to use an 513 older, previously fetched Certificate Revocation 514 List. As a result, they will not be informed of 515 any changes in revocation status of subordinate CA 516 or router certificates or the EE certificates of 517 signed objects, e.g., ROAs. This action is 518 equivalent to corruption of a CRL, since a 519 corrupted CRL will not be accepted by an RP. 521 A-3.1.2 Deletion of a CRL could cause an RP to continue to 522 accept a ROA that no longer expresses the intent 523 of an INR holder. As a result, an announcement 524 for the affected prefixes would be viewed as 525 Valid, instead of NotFound or Invalid. In this 526 case, the effect is analogous to A-5.2. 528 A-3.1.3 If a router certificate were revoked and the CRL 529 were deleted, RPs would not be aware of the 530 revocation. They might continue to accept the 531 old, revoked router certificate. If the 532 certificate had been revoked due to a compromise 533 of the router's private key, RPs would be 534 vulnerable to accepting routes signed by an 535 unauthorized entity. 537 A-3.1.4 If a subordinate CA certificate were revoked on 538 the deleted CRL, the revocation would not take 539 effect. This could interfere with a transfer of 540 address space from the subordinate CA, adversely 541 affecting routing to the new holder of the space. 543 A-3.2 Suppression 545 A-3.2.1 If publication of the most recent CRL is 546 suppressed, an RP will not be informed of the most 547 recent revocation status of a subordinate CA or 548 router certificates or the EE certificates of 549 signed objects. If an EE certificate has been 550 revoked and the associated signed object is still 551 present in the publication point, an RP might 552 mistakenly treat that object as valid. (This 553 would happen if the object is still in the 554 manifest or if the RP is configured to process 555 valid objects that are not on the manifest.) This 556 type of action is of special concern if the 557 affected object is a ROA, a router certificate, or 558 a subordinate CA certificate. The effects here 559 are equivalent to CRL deletion (A-3.1), but 560 suppression of a new CRL may not even be reported 561 as an error, i.e., if the suppressed CRL were 562 issued before the NextUpdate time (of the previous 563 CRL). 565 A-3.3 Corruption 567 A-3.3.1 If a CRL is corrupted, an RP will reject it. If a 568 prior CRL has not yet exceeded its NextUpdate 569 time, an RP will continue to use the prior CRL. 570 Even if the prior CRL has passed the NextUpdate 571 time, an RP may choose to continue to rely on the 572 prior CRL. The effects are essentially equivalent 573 to suppression or deletion of a CRL (A-3.1 and 574 A-3.2). 576 A-3.4 Modification 578 A-3.4.1 If a CRL is modified to erroneously list a signed 579 object's EE certificate as revoked, the 580 corresponding object will be treated as invalid by 581 RPs, even if it is present in a publication point. 582 If this object is a ROA, the (legitimate) binding 583 expressed by the ROA will be ignored by an RP (see 584 A-5.5). If a CRL is modified to erroneously list 585 a router certificate as revoked, a path signature 586 associated with that certificate will be treated 587 as Not Valid by RPs (see A-6.5). 589 A-3.4.2 If a CRL is modified to erroneously list a CA 590 certificate as revoked, that CA and all 591 subordinate signed objects will be treated as 592 invalid by RPs. Depending on the location of the 593 affected CA in the hierarchy, these effects could 594 be very substantial, causing routes that should be 595 Valid to be treated as NotFound. 597 A-3.4.3 If a CRL is modified to omit a revoked EE, router, 598 or CA certificate, RPs will likely continue to 599 accept the revoked, signed object as valid. This 600 contravenes the intent of the INR holder. If an 601 RP continues to accept a revoked ROA, it may make 602 routing decisions on now-invalid data. This could 603 cause valid routes to be de-preferenced and 604 invalid routes to continue to be accepted. 606 A-3.5 Revocation 608 A-3.5.1 A CRL cannot be revoked per se, but it will fail 609 validation if the CA certificate under which it 610 was issued is revoked. See A-1.5 for a discussion 611 of that action. 613 A-3.6 Injection 615 A-3.6.1 Insertion of a bogus CRL can have the same effects 616 as listed above for a modified CRL, depending on 617 how the inserted CRL differs from the correct CRL. 619 2.4. ROA 621 In addition to the generic RPKI object syntax checks, ROA validation 622 requires that the signature on the ROA can be validated using the 623 public key from the EE certificate embedded in the ROA [RFC6482]. It 624 also requires that the EE certificate be validated consistently with 625 the procedures described in [RFC6482] and [RFC6487]. Adverse actions 626 against a ROA can cause the following errors: 628 A-4.1 Deletion 630 A-4.1.1 A ROA may be deleted from the indicated 631 publication point. The result is to void the 632 binding between the prefix(es) and the Autonomous 633 System (AS) number in the ROA. An RP that 634 previously viewed this binding as authentic will 635 now not have any evidence about its validity. For 636 origin validation, this means that a legitimate 637 route will be treated as NotFound (if there are no 638 other ROAs for the same prefix) or Invalid (if 639 there is another ROA for the same prefix, but with 640 a different AS number). 642 A-4.2 Suppression 644 A-4.2.1 Publication of a newer ROA may be suppressed. If 645 the INR holder intended to change the binding 646 between the prefix(es) and the AS number in the 647 ROA, this change will not be effected. As a 648 result, RPs may continue to believe an old prefix/ 649 ASN binding that is no longer what the INR holder 650 intended. 652 A-4.2.2 If an INR holder intends to issue and publish two 653 (or more) new ROAs for the same address space, one 654 (or more) of the new ROAs may be suppressed while 655 the other is published. In this case, RPs will 656 de-preference the suppressed prefix/ASN binding. 657 Suppression of the new ROA might cause traffic to 658 flow to an ASN other than the one(s) intended by 659 the INR holder. 661 A-4.2.3 If an INR holder intends to delete all ROAs for 662 the same address space, some of them may be 663 retained while the others are deleted. Preventing 664 the deletion of some ROAs can cause traffic to 665 continue to be delivered to the ASNs that were 666 advertised by these ROAs. Deletion of all ROAs is 667 consistent with a transfer of address space to a 668 different INR holder in a phased fashion. Thus, 669 this sort of attack could interfere with the 670 successful transfer of the affected address space 671 (until such time as the prefixes are removed from 672 the previous INR holder's CA certificate). 674 A-4.3 Corruption 676 A-4.3.1 A ROA may be corrupted. A corrupted ROA will be 677 ignored by an RP, so the effect is essentially the 678 same as for A-4.1 and A-4.5. A possible 679 difference is that an RP may be alerted to the 680 fact that the ROA was corrupted, which might 681 attract attention to the attack. 683 A-4.4 Modification 685 A-4.4.1 A ROA may be modified so that the Autonomous 686 System Number (ASN) or one or more of the address 687 blocks in a ROA is different from the values the 688 INR holder intended for this ROA. (This action 689 assumes that the modified ROA's ASN and address 690 ranges are authorized for use by the INR holder.) 691 This attack will cause RPs to de-preference the 692 legitimate prefix/ASN binding intended by the INR 693 holder. 695 A-4.5 Revocation 697 A-4.5.1 A ROA may be revoked (by placing its EE 698 certificate on the CRL for the publication point). 699 This has the same effect as A-4.1. 701 A-4.6 Injection 702 A-4.6.1 A ROA expressing different bindings than those 703 published by the INR holder may be injected into a 704 publication point. This action could authorize an 705 additional ASN to advertise the specified prefix, 706 allowing that ASN to originate routes for the 707 prefix, thus enabling route origin spoofing. In 708 this case, the injected ROA is considered to be in 709 competition with any existing authorized ROAs for 710 the specified prefix. 712 A-4.6.2 An injected ROA might express a different prefix 713 for an ASN already authorized to originate a 714 route, e.g., a longer prefix, which could enable 715 that ASN to override other advertisements using 716 shorter prefixes. If there are other ROAs that 717 authorize different ASNs to advertise routes to 718 the injected ROA's prefix, then the injected ROA 719 is in competition with these ROAs. 721 2.5. Ghostbusters Record 723 The Ghostbusters Record [RFC6493] is a signed object that may be 724 included at a publication point, at the discretion of the INR holder 725 or publication point operator. The record is validated according to 726 [RFC6488]. Additionally, the syntax of the record is verified based 727 on the vCard profile from Section 5 of [RFC6493]. Errors in this 728 record do not affect RP processing. However, if an RP encounters a 729 problem with objects at a publication point, the RP may use 730 information from the record to contact the publication point 731 operator. 733 Adverse actions against a Ghostbusters Record can cause the following 734 error: 736 A-5.1 Deletion, suppression, corruption, or revocation of a 737 Ghostbusters Record could prevent an RP from contacting the 738 appropriate entity when a problem is detected by the RP. 739 Modification or injection of a Ghostbusters Record could 740 cause an RP to contact the wrong entity, thus delaying 741 remediation of a detected anomaly. All of these actions 742 are viewed as equivalent from an RP processing perspective; 743 they do not alter RP validation of ROAs or router 744 certificates. However, these actions can interfere with 745 remediation of a problem when detected by an RP. 747 2.6. Router Certificates 749 Router certificates are used by RPs to verify signatures on 750 BGPsec_PATH attributes carried in UPDATE messages. 752 Each AS is free to determine the granularity at which router 753 certificates are managed [RFC8209]. Each participating AS is 754 represented by one or more router certificates. During key or 755 algorithm rollover, multiple router certificates will be present in a 756 publication point, even if the AS is normally represented by just one 757 such certificate. 759 Adverse actions against router certificates can cause the following 760 errors: 762 A-6.1 Deletion 764 A-6.1.1 Deletion of a router certificate would cause an RP 765 to be unable to verify signatures applied to 766 BGPsec_PATH attributes on behalf of the AS in 767 question. In turn, this would cause the route to 768 be treated with lower preference than competing 769 routes that have valid BGPsec_PATH attribute 770 signatures. (However, if another router 771 certificate for the affected AS is valid and 772 contains the same AS number and public key, and it 773 is in use by that AS, there would be no effect on 774 routing. This scenario will arise if a router 775 certificate is renewed, i.e., issued with a new 776 validity interval.) 778 A-6.2 Suppression 780 A-6.2.1 Suppression of a router certificate could have the 781 same impact as deletion of a certificate of this 782 type, i.e., if no router certificate was 783 available, BGPsec attributes that should be 784 verified using the certificate would fail 785 validation. If an older certificate existed and 786 has not expired, it would be used by RPs. If the 787 older certificate contained a different ASN, the 788 impact would be the same as in A-6.4. 790 A-6.3 Corruption 791 A-6.3.1 Corruption of a router certificate will result in 792 the certificate being rejected by RPs. Absent a 793 valid router certificate, BGPsec_PATH attributes 794 associated with that certificate will be 795 unverifiable. In turn, this would cause the route 796 to be treated with lower preference than competing 797 routes that have valid BGPsec_PATH attribute 798 signatures. 800 A-6.4 Modification 802 A-6.4.1 If a router certificate is modified to represent a 803 different ASN, but it still passes syntax checks, 804 then this action could cause signatures on 805 BGPsec_PATH attributes to be associated with the 806 wrong AS. This could cause signed routes to be 807 inconsistent with the intent of the INR holder, 808 e.g., traffic might be routed via a different AS 809 than intended. 811 A-6.5 Revocation 813 A-6.5.1 If a router certificate were revoked, BGPsec_PATH 814 attributes verifiable using that certificate would 815 no longer be considered valid. The impact would 816 be the same as for a deleted certificate, as 817 described in A-6.1. 819 A-6.6 Injection 821 A-6.6.1 Insertion of a router certificate could authorize 822 additional routers to sign BGPsec traffic for the 823 targeted ASN, and thus undermine fundamental 824 BGPsec security guarantees. If there are 825 existing, authorized router certificates for the 826 same ASN, then the injected router certificate is 827 in competition with these existing certificates. 829 3. Analysis of Actions Relative to Scenarios 831 This section examines the types of problems that can arise in four 832 scenarios described below. We consider mistakes, (successful) 833 attacks against a CA or a publication point, and situations in which 834 a CA or publication point manager is compelled to take action by a 835 law enforcement authority. 837 We explore the following four scenarios: 839 A. An INR holder operates its own CA and manages its own 840 repository publication point. 842 B. An INR holder operates its own CA, but outsources management 843 of its repository publication point to its parent or another 844 entity. 846 C. An INR holder outsources management of its CA to its parent, 847 but manages its own repository publication point. 849 D. An INR holder outsources management of its CA and its 850 publication point to its parent. 852 Note that these scenarios focus on the affected INR holder as the 853 party directly affected by an adverse action. The most serious cases 854 arise when the INR holder appears as a high-tier CA in the RPKI 855 hierarchy; in such situations, subordinate INR holders may be 856 affected as a result of an action. A mistake by or an attack against 857 a "leaf" has more limited impact because all of the affected INRs 858 belong to the INR holder itself. 860 In Scenario A, actions by the INR holder can adversely affect all of 861 its resources and, transitively, resources of any subordinate CAs. 862 (If the CA is a "leaf" in the RPKI, then it has no subordinate CAs 863 and the damage is limited to its own INRs.) 865 In Scenario B, actions by the (outsourced) repository operator can 866 also adversely affect the resources of the INR holder and those of 867 any subordinates CAs. (If the CA is a "leaf" in the RPKI, then it 868 has no subordinate CAs and the damage is limited, as in Scenario A.) 869 The range of adverse effects here includes those in Scenario A and 870 adds a new potential source of adverse actions, i.e., the outsourced 871 repository operator. 873 In Scenario C, all signed objects associated with the INR holder are 874 generated by the parent CA but are self-hosted. (We expect this 875 scenario to be rare, because an INR holder that elects to outsource 876 CA operation seems unlikely to manage its own repository publication 877 point.) Because that CA has the private key used to sign them, it 878 can generate alternative signed objects -- ones not authorized by the 879 INR holder. However, erroneous objects created by the parent CA will 880 not be published by the INR holder IF the holder checks them first. 881 Because the parent CA is acting on behalf of the INR holder, mistakes 882 by or attacks against that entity are equivalent to ones effected by 883 the INR holder in Scenario A. 885 The INR holder is most vulnerable in Scenario D. Actions by the 886 parent CA, acting on behalf of the INR holder, can adversely affect 887 all signed objects associated with that INR holder, including any 888 subordinate CA certificates. These actions will presumably translate 889 directly into publication point changes because the parent CA is 890 managing the publication point for the INR holder. The range of 891 adverse effects here includes those in Scenarios A, B, and C. 893 3.1. Scenario A 895 In this scenario, the INR holder acts as its own CA and it manages 896 its own publication point. Actions by the INR holder can adversely 897 affect all of its resources and, transitively, resources of any 898 subordinate CAs. (If the CA is a "leaf" in the RPKI, then it has no 899 subordinate CAs and the damage is limited to its own INRs.) Mistakes 900 by the INR holder can cause any of the actions noted in Section 2. A 901 successful attack against this CA can effect all of the modification, 902 revocation, or injection actions noted in that section. (We assume 903 that objects generated by the CA are automatically published). An 904 attack against the publication point can effect all of the deletion, 905 suppression, or corruption actions noted in that section. 907 3.2. Scenario B 909 In this scenario, the INR holder acts as its own CA but it delegates 910 management of it own publication point to a third party. Mistakes by 911 the INR holder can cause any of the modification, revocation, or 912 injection actions described in Section 2. Actions by the repository 913 operator can adversely affect the resources of the INR holder, and 914 those of any subordinate CAs. (If the CA is a "leaf" in the RPKI, 915 then it has no subordinate CAs and the damage is limited, as in 916 Scenario A.) The range of adverse effects here includes those in 917 Scenario A, and adds a new potential source of adverse actions, i.e., 918 the third party repository operator. A successful attack against the 919 CA can effect all of the modification, revocation, or injection 920 actions noted in that section (assuming that objects generated by the 921 CA are automatically published). Here, actions by the publication 922 point manager (or attacks against that entity) can effect all of the 923 deletion, suppression, or corruption actions noted in Section 2. 925 3.3. Scenario C 927 In this scenario, the INR holder outsources management of its CA to 928 its parent, but manages its own repository publication point. All 929 signed objects associated with the INR holder are generated by the 930 parent CA but are self-hosted. (We expect this scenario to be rare, 931 because an INR holder that elects to outsource CA operation seems 932 unlikely to manage its own repository publication point.) Because 933 that CA has the private key used to sign them, it can generate 934 alternative signed objects -- ones not authorized by the INR holder. 936 However, erroneous objects created by the parent CA will not be 937 published by the INR holder IF the holder checks them first. Because 938 the parent CA is acting on behalf of the INR holder, mistakes by or 939 attacks against that entity are equivalent to ones effected by the 940 INR holder in Scenario A. Mistakes by the INR holder, acted upon by 941 the parent CA, can cause any of the actions noted in Section 2. 942 Actions unilaterally undertaken by the parent CA also can have the 943 same effect, unless the INR holder checks the signed objects before 944 publishing them. A successful attack against the parent CA can 945 effect all of the modification, revocation, or injection actions 946 noted in Section 2, unless the INR holder checks the signed objects 947 before publishing them. An attack against the INR holder (in its 948 role as repository operator) can effect all of the deletion, 949 suppression, or corruption actions noted in Section 2 (because the 950 INR holder is managing its publication point), unless the INR holder 951 checks the signed objects before publishing them. (An attack against 952 the INR holder implies that the path it uses to direct the parent CA 953 to issue and publish objects has been compromised.) 955 3.4. Scenario D 957 In this scenario, an INR holder outsources management of both its CA 958 and its publication point to its parent. The INR holder is most 959 vulnerable in this scenario. Actions by the parent CA, acting on 960 behalf of the INR holder, can adversely affect all signed objects 961 associated with that INR holder, including any subordinate CA 962 certificates. These actions will presumably translate directly into 963 publication point changes, because the parent CA is managing the 964 publication point for the INR holder. The range of adverse effects 965 here includes those in Scenarios A, B, and C. Mistakes by the INR 966 holder, acted upon by the parent CA, can cause any of the actions 967 noted in Section 2. Actions unilaterally undertaken by the parent CA 968 also can have the same effect. A successful attack against the 969 parent CA can effect all of the modification, revocation, or 970 injection actions noted in Section 2. An attack against the parent 971 CA , or an error by the CA, can also effect all of the deletion, 972 suppression, or corruption actions noted in Section 2. 974 4. Security Considerations 976 This informational document describes a threat model for the RPKI, 977 focusing on mistakes by or attacks against CAs and independent 978 repository managers. It is intended to provide a basis for the 979 design of future RPKI security mechanisms that seek to address the 980 concerns associated with such actions. 982 The analysis in this document identifies a number of circumstances in 983 which attacks or errors can have significant impacts on routing. One 984 ought not interpret this as a condemnation of the RPKI. It is only 985 an attempt to document the implications of a wide range of attacks 986 and errors in the context of the RPKI. The primary alternative 987 mechanism for disseminating routing information is Internet Routing 988 Registry (IRR) technology [RFC2650] [RFC2725], which uses the Routing 989 Policy Specification Language (RPSL) [RFC2622]. IRR technology 990 exhibits its own set of security problems, which are discussed in 991 [RFC7682]. 993 5. IANA Considerations 995 This document does not require any IANA actions. 997 6. Acknowledgements 999 7. References 1001 7.1. Normative References 1003 [I-D.ymbk-sidrops-6486bis] 1004 Austein, R., Huston, G., Kent, S., and M. Lepinski, 1005 "Manifests for the Resource Public Key Infrastructure 1006 (RPKI)", draft-ymbk-sidrops-6486bis-00 (work in progress), 1007 July 2020. 1009 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 1010 Addresses and AS Identifiers", RFC 3779, 1011 DOI 10.17487/RFC3779, June 2004, 1012 . 1014 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 1015 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 1016 February 2012, . 1018 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 1019 Resource Certificate Repository Structure", RFC 6481, 1020 DOI 10.17487/RFC6481, February 2012, 1021 . 1023 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 1024 Origin Authorizations (ROAs)", RFC 6482, 1025 DOI 10.17487/RFC6482, February 2012, 1026 . 1028 [RFC6483] Huston, G. and G. Michaelson, "Validation of Route 1029 Origination Using the Resource Certificate Public Key 1030 Infrastructure (PKI) and Route Origin Authorizations 1031 (ROAs)", RFC 6483, DOI 10.17487/RFC6483, February 2012, 1032 . 1034 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 1035 X.509 PKIX Resource Certificates", RFC 6487, 1036 DOI 10.17487/RFC6487, February 2012, 1037 . 1039 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object 1040 Template for the Resource Public Key Infrastructure 1041 (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, 1042 . 1044 [RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification 1045 Authority (CA) Key Rollover in the Resource Public Key 1046 Infrastructure (RPKI)", BCP 174, RFC 6489, 1047 DOI 10.17487/RFC6489, February 2012, 1048 . 1050 [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) 1051 Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493, 1052 February 2012, . 1054 [RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility 1055 Procedure for the Resource Public Key Infrastructure 1056 (RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April 1057 2013, . 1059 [RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for 1060 Algorithms and Key Sizes for Use in the Resource Public 1061 Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935, 1062 August 2016, . 1064 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 1065 Specification", RFC 8205, DOI 10.17487/RFC8205, September 1066 2017, . 1068 [RFC8209] Reynolds, M., Turner, S., and S. Kent, "A Profile for 1069 BGPsec Router Certificates, Certificate Revocation Lists, 1070 and Certification Requests", RFC 8209, 1071 DOI 10.17487/RFC8209, September 2017, 1072 . 1074 7.2. Informative References 1076 [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., 1077 Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, 1078 "Routing Policy Specification Language (RPSL)", RFC 2622, 1079 DOI 10.17487/RFC2622, June 1999, 1080 . 1082 [RFC2650] Meyer, D., Schmitz, J., Orange, C., Prior, M., and C. 1083 Alaettinoglu, "Using RPSL in Practice", RFC 2650, 1084 DOI 10.17487/RFC2650, August 1999, 1085 . 1087 [RFC2725] Villamizar, C., Alaettinoglu, C., Meyer, D., and S. 1088 Murphy, "Routing Policy System Security", RFC 2725, 1089 DOI 10.17487/RFC2725, December 1999, 1090 . 1092 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1093 RFC 5652, DOI 10.17487/RFC5652, September 2009, 1094 . 1096 [RFC7132] Kent, S. and A. Chi, "Threat Model for BGP Path Security", 1097 RFC 7132, DOI 10.17487/RFC7132, February 2014, 1098 . 1100 [RFC7682] McPherson, D., Amante, S., Osterweil, E., Blunk, L., and 1101 D. Mitchell, "Considerations for Internet Routing 1102 Registries (IRRs) and Routing Policy Configuration", 1103 RFC 7682, DOI 10.17487/RFC7682, December 2015, 1104 . 1106 Authors' Addresses 1108 Stephen Kent 1109 Independent 1111 Email: kent@alum.mit.edu 1113 Di Ma 1114 ZDNS 1115 4 South 4th St. Zhongguancun 1116 Haidian, Beijing 100190 1117 China 1119 Email: madi@zdns.cn