idnits 2.17.1 draft-ietf-sidr-adverse-actions-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 12, 2016) is 2754 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-21) exists of draft-ietf-sidr-bgpsec-pki-profiles-18 == Outdated reference: A later version (-23) exists of draft-ietf-sidr-bgpsec-protocol-18 ** Obsolete normative reference: RFC 6485 (Obsoleted by RFC 7935) ** Obsolete normative reference: RFC 6486 (Obsoleted by RFC 9286) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIDR S. Kent 3 Internet-Draft BBN Technologies 4 Intended status: Informational D. Ma 5 Expires: March 16, 2017 ZDNS 6 September 12, 2016 8 Adverse Actions by a Certification Authority (CA) or Repository Manager 9 in the Resource Public Key Infrastructure (RPKI) 10 draft-ietf-sidr-adverse-actions-03 12 Abstract 14 This document analyzes actions by or against a CA or independent 15 repository manager in the RPKI that can adversely affect the Internet 16 Number Resources (INRs) associated with that CA or its subordinate 17 CAs. The analysis is done from the perspective of an affected INR 18 holder. The analysis is based on examination of the data items in 19 the RPKI repository, as controlled by a CA (or independent repository 20 manager) and fetched by Relying Parties (RPs). The analysis does not 21 purport to be comprehensive; it does represent an orderly way to 22 analyze a number of ways that errors by or attacks against a CA or 23 repository manager can affect the RPKI and routing decisions based on 24 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 http://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 March 16, 2017. 43 Copyright Notice 45 Copyright (c) 2016 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 (http://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 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Analysis of RPKI Repository Objects . . . . . . . . . . . . . 3 63 2.1. CA Certificates . . . . . . . . . . . . . . . . . . . . . 6 64 2.2. Manifest . . . . . . . . . . . . . . . . . . . . . . . . 9 65 2.3. Certificate Revocation List . . . . . . . . . . . . . . . 11 66 2.4. ROA . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 67 2.5. Ghostbusters Record . . . . . . . . . . . . . . . . . . . 16 68 2.6. Router Certificates . . . . . . . . . . . . . . . . . . . 17 69 3. Analysis of Actions Relative to Scenarios . . . . . . . . . . 18 70 3.1. Scenario A . . . . . . . . . . . . . . . . . . . . . . . 20 71 3.2. Scenario B . . . . . . . . . . . . . . . . . . . . . . . 20 72 3.3. Scenario C . . . . . . . . . . . . . . . . . . . . . . . 21 73 3.4. Scenario D . . . . . . . . . . . . . . . . . . . . . . . 21 74 4. Security Considerations . . . . . . . . . . . . . . . . . . . 22 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 76 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 77 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 78 7.1. Normative References . . . . . . . . . . . . . . . . . . 22 79 7.2. Informative References . . . . . . . . . . . . . . . . . 24 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 82 1. Introduction 84 In the context of this document, any change to the Resource Public 85 Key Infrastructure (RPKI) [RFC6480] that diminishes the set of 86 Internet Numeric Resources (INRs) associated with an INR holder, and 87 that is contrary to the holder's wishes, is termed "adverse". This 88 analysis is done from the perspective of an affected INR holder. An 89 action that results in an adverse charge (as defined above), may be 90 the result of an attack on a CA [RFC7132], an error by a CA, or an 91 error by or an attack on a repository operator. Note that the CA 92 that allocated the affected INRs may be acting in accordance with 93 established policy, and thus the change may be contractually 94 justified, even though viewed as adverse by the INR holder. This 95 document examines the implications of adverse actions within the RPKI 96 with respect to INRs irrespective of the cause of the actions. 98 Additionally, when a ROA or router certificate is created that 99 "competes" with an existing ROA or router certificate (respectively), 100 the creation of the new ROA or router certificate may be adverse. (A 101 newer ROA competes with an older ROA if the newer ROA points to a 102 different ASN, contains the same or a more specific prefix, and is 103 issued by a different CA. A newer router certificate competes with 104 an older router certificate if the newer one contains the same ASN 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 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 independent repository 130 operator) and fetched by Relying Parties (RPs). 132 1.1. Terminology 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119]. 138 2. Analysis of RPKI Repository Objects 140 This section enumerates the RPKI repository system objects and 141 examines how changes to them affect Route Origination Authorizations 142 (ROAs) and router certificate validation. Identifiers are assigned 143 to errors for reference by later sections of this document. Note 144 that not all adverse actions may be addressed by this taxonomy. 146 The RPKI repository [RFC6481] contains a number of (digitally signed) 147 objects that are fetched and processed by RPs. Until the deployment 148 of BGPsec [I-D.ietf-sidr-bgpsec-overview], the principal goal of the 149 RPKI is to enable an RP to validate ROAs [RFC6482]. A ROA binds 150 address space to an Autonomous System Number (ASN). A ROA can be 151 used to verify BGP announcements with respect to route origin 152 [RFC6483]. The most important objects in the RPKI for origin 153 validation are ROAs; all of the other RPKI objects exist to enable 154 the validation of ROAs in a fashion consistent with the INR 155 allocation system. Thus errors that result in changes to a ROA, or 156 to RPKI objects needed to validate a ROA, can cause RPs to reach 157 different (from what was intended) conclusions about the validity of 158 the bindings expressed in a ROA. 160 When BGPsec is deployed, router certificates 161 [I-D.ietf-sidr-bgpsec-pki-profiles] will be added to repository 162 publication points. These are End-Entity (EE) certificates used to 163 verify signatures applied to BGP update data, to enable path 164 validation [I-D.ietf-sidr-bgpsec-protocol]. Router certificates are 165 as important to path validation as ROAs are to origin validation. 167 The objects contained in the RPKI repository are of two types: 168 conventional PKI objects (certificates and Certificate Revocation 169 Lists (CRLs)) and RPKI-specific signed objects. The latter make use 170 of a common encapsulation format [RFC6488] based on the Cryptographic 171 Message Syntax (CMS) [RFC5652]. A syntax error in this common format 172 will cause an RP to reject the object, e.g., a ROA or Manifest, as 173 invalid. 175 Adverse actions take several forms: 177 * Deletion (D) is defined as removing an object from a 178 publication point, without the permission of the INR holder. 180 * Suppression (S) is defined as not deleting an object, or not 181 publishing an object, as intended by an INR holder. This 182 action also includes retaining a prior version of an object in 183 a publication point when a newer version is available for 184 publication. 186 * Corruption (C) is defined as modification of a signed object in 187 a fashion not requiring access to the private key used to sign 188 the object. Thus a corrupted object will not carry a valid 189 signature. Implicitly, the corrupted object replaces the 190 legitimate version. 192 * Modification (M) is defined as publishing a syntactically 193 valid, verifiable version of an object that differs from the 194 (existing) version authorized by the INR holder. Implicitly, 195 the legitimate version of the affected object is deleted and 196 replaced by the modified object. 198 * Revocation (R) is defined as revoking a certificate (EE or CA) 199 by placing its serial number on the appropriate CRL, without 200 authorization of the INR holder. 202 * Injection (I) is defined as introducing an instance of a signed 203 object into a publication point (without authorization of the 204 INR holder). It assumes that the signature on the object will 205 be viewed as valid by RPs. 207 The first three of these actions (deletion, suppression, and 208 corruption) can be effected by any entity that manages the 209 publication point of the affected INR holder. Also, an entity with 210 the ability to act as a man-in-the-middle between an RP and a 211 repository can effect these actions with respect to the RP in 212 question. 214 The latter three actions (modification, revocation, and injection) 215 nominally require access to the private key of the INR holder. 217 All six of these actions also can be effected by a parent CA. A 218 parent CA could reissue the INR holder's CA certificate, but with a 219 different public key, matching a private key to which the parent CA 220 has access. The CA could generate new signed objects using the 221 private key associated with the reissued certificate, and publish 222 these objects at a location of its choosing. 224 Most of these actions may be performed independently or in 225 combination with one another. For example, a ROA may be revoked and 226 deleted or revoked and replaced with a modified ROA. Where 227 appropriate, the analysis of adverse actions will distinguish between 228 individual actions, or combinations thereof, that yield different 229 outcomes for RPs. Recall that the focus of the analysis is the 230 impact on ROAs and router certificates, with respect to RP 231 processing. 233 The following sections examine how the actions enumerated above 234 affect objects in the RPKI repository system. Each action is 235 addressed in order (Deletion, Suppression, Corruption, Modification, 236 Revocation, and Injection) for each object, making it easy to see how 237 each action has been considered with regard to each object. (For the 238 GhostBusters record we condensed the discussion of the actions 239 because the impact is the same in each case.) 241 2.1. CA Certificates 243 Every INR holder is represented by one or more CA certificates. An 244 INR holder has multiple CA certificates if it holds resources 245 acquired from different sources. Also, every INR holder has more 246 than one CA certificate during key rollover [RFC6489] and algorithm 247 rollover [RFC6916]. 249 If a publication point is not a leaf in the RPKI hierarchy, then the 250 publication point will contain one or more CA certificates, each 251 representing a subordinate CA. Each subordinate CA certificate 252 contains a pointer (SIA) to the publication point where the signed 253 objects associated with that CA can be found [RFC6487]. 255 A CA certificate is a complex data structure and thus errors in that 256 structure may have different implications for RPs depending on the 257 specific data that is in error. 259 Adverse actions against a CA certificate can cause the following 260 errors: 262 A-1.1 Deletion 264 A-1.1.1 Deletion of a CA certificate would cause an RP to 265 not be able to locate signed objects generated by 266 that CA, except those that have been cached by the 267 RP. Thus an RP would be unaware of changed or new 268 (issued after the cached data) INR bindings 269 asserted in subordinate ROAs, and the RP would be 270 unable to validate new or changed router 271 certificates. If the missed objects were intended 272 to replace ROAs or router certificates prior to 273 expiration, then when those objects expire, RPs 274 may cease to view them as valid. As a result, 275 valid routes may be viewed as NotFound or Invalid. 277 A-1.2 Suppression 279 A-1.2.1 If publication of a CA certificate is suppressed, 280 the impact depends on what changes appeared in the 281 suppressed certificate. If the SIA value changed, 282 the effect would be the same as in A-1.1 or 1.4.3. 284 If the 3779 extensions in the suppressed 285 certificate changed, the impact would be the same 286 as in 1.4.1. If the AIA extension changed in the 287 suppressed certificate, the impact would be the 288 same as in 1.4.4. 290 A-1.3 Corruption 292 A-1.3.1 Corruption of a CA certificate will cause it to be 293 rejected by RPs. In turn, this may cause 294 subordinate signed objects to become invalid. An 295 RP that has cached the subtree under the affected 296 CA certificate may continue to view it as valid, 297 until objects expire. But changed or new objects 298 might not be retrieved, depending on details of 299 the design of the RP software. Thus this action 300 may be equivalent to suppressing changes to the 301 affected subtree. 303 A-1.4 Modification 305 A-1.4.1 If a CA certificate is modified, but still 306 conforms to the RPKI certificate profile 307 [RFC6485], it will be accepted by RPs. If an 308 [RFC3779] extension in this certificate is changed 309 to exclude INRs that were previously present, then 310 subordinate signed objects will become invalid if 311 they rely on the excised INRs. If these objects 312 are CA certificates, their subordinate signed 313 objects will be treated as invalid. If the 314 objects are ROAs, the binding expressed by the 315 affected ROAs will be ignored by RPs. If the 316 objects are router certificates, BGPsec_Path 317 attributes [I-D.ietf-sidr-bgpsec-protocol] 318 verifiable under these certificates will be 319 considered invalid. 321 A-1.4.2 If the SIA extension of a CA certificate is 322 modified to refer to another publication point, 323 this will cause an RP to look at another location 324 for subordinate objects. This could cause RPs to 325 not acquire the objects that the INR holder 326 intended to be retrieved - manifests, ROAs, router 327 certificates, Ghostbuster records, or any 328 subordinate CA certificates associated with that 329 CA. If the objects at this new location contain 330 invalid signatures or appear to be corrupted, they 331 may be rejected. In this case, cached versions of 332 the objects may be viewed as valid by an RP, until 333 they expire. If the objects at the new location 334 have valid signatures and pass path validation 335 checks, they will replace the cached objects, 336 effectively replacing the INR holder's objects. 338 A-1.4.3 If the AIA extension in a CA certificate is 339 modified, it would point to a different CA 340 certificate, not the parent CA certificate. This 341 extension is used only for path discovery, not 342 path validation. Path discovery in the RPKI is 343 usually performed on a top-down basis, starting 344 with TAs and recursively descending the RPKI 345 hierarchy. Thus there may be no impact on the 346 ability of clients to acquire and validate 347 certificates if the AIA is modified. 349 A-1.4.4 If the Subject Public Key Info (and Subject Key 350 Identifier extension) in a CA certificate is 351 modified to contain a public key corresponding to 352 a private key held by the parent, the parent could 353 sign objects as children of the affected CA 354 certificate. With this capability, the parent 355 could replace the INR holder, issuing new signed 356 objects that would be accepted by RPs (as long as 357 they do not violate the path validation criteria). 358 This would enable the parent to effect 359 modification, revocation, and injection actions 360 against all of the objects under the affected CA 361 certificate, including subordinate CA 362 certificates. (Note that key rollover also yields 363 a new CA certificate. However, the new 364 certificate will co-exist with the old one for a 365 while, which may help distinguish this legitimate 366 activity from an adverse action.) 368 A-1.5 Revocation 370 A-1.5.1 If a CA certificate is revoked an RP will treat as 371 invalid all subordinate signed objects, both 372 immediate and transitively. The effects are 373 essentially the same as described in A-3.4.2. 375 A-1.6 Injection 377 A-1.6.1 If a CA certificate is injected the impact will 378 depend on the data contained in the injected 379 certificate. Changes will generally be equivalent 380 to modification actions as described in A-1.4. 382 2.2. Manifest 384 Each repository publication point contains a manifest [RFC6486]. The 385 RPKI incorporates manifests to enable RPs to detect suppression and/ 386 or substitution of (more recent) publication point objects, as the 387 result of a mistake or attack. A manifest enumerates (by filename) 388 all of the other signed objects at the publication point. The 389 manifest also contains a hash of each enumerated file, to enable an 390 RP to determine if the named file content matches what the INR holder 391 identified in the manifest. 393 A manifest is an RPKI signed object, so it is validated as per 394 [RFC6488]. If a manifest is modified in a way that causes any of 395 these checks to fail, the manifest will be considered invalid. 396 Suppression of a manifest itself (indicated by a stale manifest) also 397 can cause an RP to not detect suppression of other signed objects at 398 the publication point. (Note that if a Manifest's EE certificate 399 expires at the time that the Manifest is scheduled to be replaced, a 400 delay in publication will cause the Manifest to become invalid, not 401 merely stale. This very serious outcome should be avoided, e.g., by 402 making the Manifest EE certificate's notAfter value the same as that 403 of the CA certificate under which it was issued). If a signed object 404 at a publication point can be validated (using the rules applicable 405 for that object type), then an RP MAY accept that object, even if 406 there is no matching entry for it on the manifest. However, it 407 appears that most RP software ignores publication point data that 408 fails to match Manifest entries (at the time this document was 409 written). 411 Corruption, suppression, modification, or deletion of a manifest 412 might not affect RP processing of other publication point objects, as 413 specified in [RFC6486]. However, as noted above, many RP 414 implementations ignore objects that are present at a publication 415 point but not listed in a valid Manifest. Thus the following actions 416 against a manifest can impact RP processing: 418 A-2.1 Deletion 420 A-2.1.1 A Manifest may be deleted from the indicated 421 publication point. In this circumstance an RP may 422 elect to use the previous Manifest (if available), 423 and may ignore any new/changed objects at the 424 publication point. The implications of this 425 action are equivalent to suppression of 426 publication of the objects that are not recognized 427 by RPs because the new objects are not present in 428 the old Manifest. For example, a new ROA could be 429 ignored (A-1.2). A newly issued CA certificate 430 might be ignored (A-1.1). A subordinate CA 431 certificate that was revoked might still be viewed 432 as valid by RPs (A-4.1). A new or changed router 433 certificate might be ignored (A-6.2) as would a 434 revised Ghostbusters record (A-4.1). 436 A-2.2 Suppression 438 A-2.2.1 Publication of a newer Manifest may be suppressed. 439 Suppression of a newer Manifest probably will 440 cause an RP to rely on a cached Manifest (if 441 available). The older Manifest would not 442 enumerate newly added objects, and thus those 443 objects might be ignored by an RP, equivalent to 444 deletion of those objects (A-1.1, A-3.1, A-4.1, 445 A-5.1, A-6.1). 447 A-2.3 Corruption 449 A-2.3.1 A Manifest may be corrupted. A corrupted Manifest 450 will be rejected by RPs. This may cause RPs to 451 rely on a previous manifest, with the same impact 452 as A-2.2. If an RP does not revert to using a 453 cached Manifest, the impact of this action is very 454 severe, i.e., all publication point objects 455 probably will be viewed as invalid, including 456 subordinate tree objects. This is equivalent to 457 revoking or deleting an entire subtree (see 458 A-4.4.2). 460 A-2.4 Modification 462 A-2.4.1 A Manifest may be modified to remove one or more 463 objects. Because the modified Manifest is viewed 464 as valid by RPs, any objects that were removed may 465 be ignored by RPs. This is equivalent to deleting 466 these objects from the repository. The impact of 467 this action will vary, depending on which objects 468 are (effectively) removed. However, the impact is 469 equivalent to deletion of the object in question, 470 (A-1.1, A-3.1, A-4.1, A-5.1, A-6.1). 472 A-2.4.2 A Manifest may be modified to add one or more 473 objects. If an added object has a valid signature 474 (and is non-expired), it will be accepted by RPs 475 and processed accordingly. If the added object 476 was previously deleted by the INR holder, this 477 action is equivalent to suppressing deletion of 478 that object. If the object is newly created, or 479 modified, it is equivalent to a modification or 480 injection action for the type of object in 481 question, and thus is discussed in the relevant 482 section for those actions for the object type. 484 A-2.4.3 A Manifest may be modified to list an incorrect 485 hash for one or more objects. An object with an 486 incorrect hash may be ignored by an RP. Thus the 487 effect may be equivalent to corrupting the object 488 in question, although the error reported by RP 489 software would differ from that reported for a 490 corrupted object. (The Manifest specifications do 491 not require an RP to ignore an object that has a 492 valid signature and that is not revoked or 493 expired, but for which the hash doesn't match the 494 object. However, an RP may elect to do so.) 496 A-2.5 Revocation 498 A-2.5.1 A Manifest may be revoked (by including its EE 499 certificate on the CRL for the publication point). 500 A revoked Manifest will be ignored by an RP, which 501 probably would revert to an older (cached) 502 Manifest. The implications for RPs are equivalent 503 to A-2.1, with regard to new/changed objects. 505 A-2.6 Injection 507 A-2.6.1 A Manifest representing different objects may be 508 injected into a publication point. The effects 509 are the same as for a modified Manifest (see 510 above). The impact will depend on the type of the 511 affected object(s), and thus is discussed in the 512 relevant section(s) for each object type. 514 2.3. Certificate Revocation List 516 Each publication point contains a CRL that enumerates revoked (not 517 yet expired) certificates issued by the CA associated with the 518 publication point [RFC6481]. 520 Adverse actions against a CRL can cause the following errors: 522 A-3.1 Deletion 524 A-3.1.1 If a CRL is deleted, RPs will continue to use an 525 older, previously fetched Certificate Revocation 526 List. As a result, they will not be informed of 527 any changes in revocation status of subordinate CA 528 or router certificates or the EE certificates of 529 signed objects, e.g., ROAs. This action is 530 equivalent to corruption of a CRL, since a 531 corrupted CRL will not be accepted by an RP. 533 A-3.1.2 Deletion of a CRL could cause an RP to continue to 534 accept a ROA that no longer expresses the intent 535 of an INR holder. As a result, an announcement 536 for the affected prefixes would be viewed as 537 Valid, instead of NotFound or Invalid. In this 538 case, the effect is analogous to A-5.2. 540 A-3.1.3 If a router certificate were revoked, and the CRL 541 were deleted, RPs would not be aware of the 542 revocation. They might continue to accept the 543 old, revoked, router certificate. If the 544 certificate had been revoked due to a compromise 545 of the router's private key, RPs would be 546 vulnerable to accepting routes signed by an 547 unauthorized entity. 549 A-3.1.4 If a subordinate CA certificate were revoked on 550 the deleted CRL, the revocation would not take 551 effect. This could interfere with a transfer of 552 address space from the subordinate CA, adversely 553 affecting routing to the new holder of the space. 555 A-3.2 Suppression 557 A-3.2.1 If publication of the most recent CRL is 558 suppressed, an RP will not be informed of the most 559 recent revocation status of subordinate CA or 560 router certificates or the EE certificates of 561 signed objects. If an EE certificate has been 562 revoked and the associated signed object is still 563 present in the publication point, an RP might 564 mistakenly treat that object as valid. (This 565 would happen if the object is still in the 566 manifest or the RP is configured to process valid 567 objects that are not on the manifest.) This type 568 of action is of special concern if the affected 569 object is a ROA, a router certificate, or a 570 subordinate CA certificate. The effects here are 571 equivalent to CRL deletion (A-3.1), but 572 suppression of a new CRL may not even be reported 573 as an error, i.e., if the suppressed CRL were 574 issued before the NextUpdate time (of the previous 575 CRL). 577 A-3.3 Corruption 579 A-3.3.1 If a CRL is corrupted, an RP will reject it. If a 580 prior CRL has not yet exceeded its NextUpdate 581 time, an RP will continue to use the prior CRL. 582 Even if the prior CRL has passed the NextUpdate 583 time, an RP may choose to continue to rely on the 584 prior CRL. The effects are essentially equivalent 585 to suppression or deletion of a CRL (A-3.1, 586 A-3.2). 588 A-3.4 Modification 590 A-3.4.1 If a CRL is modified to erroneously list a signed 591 object's EE certificate as revoked, the 592 corresponding object will be treated as invalid by 593 RPs, even if it is present in a publication point. 594 If this object is a ROA, the (legitimate) binding 595 expressed by the ROA will be ignored by an RP (see 596 A-5.5). If a CRL is modified to erroneously list 597 a router certificate as revoked, a path signature 598 associated with that certificate will be treated 599 as Not Valid by RPs (see A-6.5). 601 A-3.4.2 If a CRL is modified to erroneously list a CA 602 certificate as revoked, that CA and all 603 subordinate signed objects will be treated as 604 invalid by RPs. Depending on the location of the 605 affected CA in the hierarchy, these effects could 606 be very substantial, causing routes that should be 607 Valid to be treated as NotFound. 609 A-3.4.3 If a CRL is modified to omit a revoked EE, router, 610 or CA certificate, RPs likely will continue to 611 accept the revoked, signed object as valid. This 612 contravenes the intent of the INR holder. If an 613 RP continues to accept a revoked ROA, it may make 614 routing decisions on now-invalid data. This could 615 cause valid routes to be de-preferenced and 616 invalid routes to continue to be accepted. 618 A-3.5 Revocation 620 A-3.5.1 A CRL cannot be revoked, per se, but it will fail 621 validation if the CA certificate under which it 622 was issued is revoked. See A-1.5 for a discussion 623 of that action. 625 A-3.6 Injection 627 A-3.6.1 Insertion of a bogus CRL can have the same effects 628 as listed above for a modified CRL, depending on 629 how the inserted CRL differs from the correct CRL. 631 2.4. ROA 633 In addition to the generic RPKI object syntax checks, ROA validation 634 requires that the signature on the ROA can be validated using the 635 public key from the EE certificate embedded in the ROA [RFC6482]. It 636 also requires that the EE certificate be validated consistently with 637 the procedures described in [RFC6482] and [RFC6487]. Adverse actions 638 against a ROA can cause the following errors: 640 A-4.1 Deletion 642 A-4.1.1 A ROA may be deleted from the indicated 643 publication point. The result is to void the 644 binding between the prefix(es) and the AS number 645 in the ROA. An RP that previously viewed this 646 binding as authentic will now not have any 647 evidence about its validity. For origin 648 validation, this means that a legitimate route 649 will be treated as NotFound (if there are no other 650 ROAs for the same prefix) or Invalid (if there is 651 another ROA for the same prefix, but with a 652 different AS number). 654 A-4.2 Suppression 656 A-4.2.1 Publication of a newer ROA may be suppressed. If 657 the INR holder intended to change the binding 658 between the prefix(es) and the AS number in the 659 ROA, this change will not be effected. As a 660 result, RPs may continue to believe an old prefix/ 661 ASN binding that is no longer what the INR holder 662 intended. 664 A-4.2.2 If an INR holder intends to issue and publish two 665 (or more) new ROAs for the same address space, one 666 (or more) of the new ROAs may be suppressed while 667 the other is published. In this case, RPs will 668 de-preference the suppressed prefix/ASN binding. 669 Suppression of the new ROA might cause traffic to 670 flow to an ASN other than the one(s) intended by 671 the INR holder. 673 A-4.2.3 If an INR holder intends to delete all ROAs for 674 the same address space, some of them may be 675 retained while the others are deleted. Preventing 676 the deletion of some ROAs can cause traffic to 677 continue to be delivered to the ASNs that were 678 advertised by these ROAs. Deletion of all ROAs is 679 consistent with a transfer of address space to a 680 different INR holder, in a phased fashion. Thus 681 this sort of attack could interfere with the 682 successful transfer of the affected address space 683 (until such time as the prefixes are removed from 684 the previous INR holder's CA certificate). 686 A-4.3 Corruption 688 A-4.3.1 A ROA may be corrupted. A corrupted ROA will be 689 ignored by an RP, so the effect is essentially the 690 same as for A-4.1 and 4.5. A possible difference 691 is that an RP may be alerted to the fact that the 692 ROA was corrupted, which might attract attention 693 to the attack. 695 A-4.4 Modification 697 A-4.4.1 A ROA may be modified so that the Autonomous 698 System Number (ASN) or one or more of the address 699 blocks in a ROA is different from the values the 700 INR holder intended for this ROA. (This action 701 assumes that the modified ROA's ASN and address 702 ranges are authorized for use by the INR holder.) 703 This attack will cause RPs to de-preference the 704 legitimate prefix/ASN binding intended by the INR 705 holder. 707 A-4.5 Revocation 708 A-4.5.1 A ROA may be revoked (by placing its EE 709 certificate on the CRL for the publication point). 710 This has the same effect as A-4.1. 712 A-4.6 Injection 714 A-4.6.1 A ROA expressing different bindings than those 715 published by the INR holder may be injected into a 716 publication point. This action could authorize an 717 additional ASN to advertise the specified prefix, 718 allowing that ASN to originate routes for the 719 prefix, thus enabling route origin spoofing. In 720 this case, the injected ROA is considered to be in 721 competition with any existing authorized ROAs for 722 the specified prefix. 724 A-4.6.2 An injected ROA might express a different prefix 725 for an ASN already authorized to originate a 726 route, e.g., a longer prefix, which could enable 727 that ASN to override other advertisements using 728 shorter prefixes. If there are other ROAs that 729 authorize different ASNs to advertise routes to 730 the injected ROA's prefix, then the injected ROA 731 is in competition with these ROAs. 733 2.5. Ghostbusters Record 735 The Ghostbusters record [RFC6493] is a signed object that MAY be 736 included at a publication point, at the discretion of the INR holder 737 or publication point operator. The record is validated according to 738 [RFC6488]. Additionally, the syntax of the record is verified based 739 on the vCard profile from Section 5 of [RFC6493]. Errors in this 740 record do not affect RP processing. However, if an RP encounters a 741 problem with objects at a publication point, the RP may use 742 information from the record to contact the publication point 743 operator. 745 Adverse actions against a Ghostbusters record can cause the following 746 error: 748 A-5.1 Deletion, suppression, corruption, or revocation of a 749 Ghostbusters record could prevent an RP from contacting the 750 appropriate entity when a problem is detected by the RP. 751 Modification or injection of a Ghostbusters record could 752 cause an RP to contact the wrong entity, thus delaying 753 remediation of a detected anomaly. All of these actions 754 are viewed as equivalent from an RP processing perspective; 755 they do not alter RP validation of ROAs or router 756 certificates. However, these actions can interfere with 757 remediation of a problem when detected by an RP. 759 2.6. Router Certificates 761 Router certificates are used by RPs to verify signatures on 762 BGPsec_Path attributes carried in Update messages. 764 Each AS is free to determine the granularity at which router 765 certificates are managed [I-D.ietf-sidr-bgpsec-pki-profiles]. Each 766 participating AS is represented by one or more router certificates. 767 During key or algorithm rollover, multiple router certificates will 768 be present in a publication point, even if the AS is normally 769 represented by just one such certificate. 771 Adverse actions against router certificates can cause the following 772 errors: 774 A-6.1 Deletion 776 A-6.1.1 Deletion of a router certificate would cause an RP 777 to not be able to verify signatures applied to 778 BGPsec_Path attributes on behalf of the AS in 779 question. In turn, this would cause the route to 780 be treated with lower preference than competing 781 routes that have valid BGPsec_Path attribute 782 signatures. (However, if another router 783 certificate for the affected AS is valid and 784 contains the same AS number and public key, and is 785 in use by that AS, there would be no effect on 786 routing. This scenario will arise if a router 787 certificate is renewed, i.e., issued with a new 788 validity interval.) 790 A-6.2 Suppression 792 A-6.2.1 Suppression of a router certificate could have the 793 same impact as deletion of a certificate of this 794 type, i.e., if no router certificate was 795 available, BGPsec attributes that should be 796 verified using the certificate would fail 797 validation. If an older certificate existed, and 798 had not expired, it would be used by RPs. If the 799 older certificate contained a different ASN, the 800 impact would be the same as in A-6.4. 802 A-6.3 Corruption 804 A-6.3.1 Corruption of a router certificate will result in 805 the certificate being rejected by RPs. Absent a 806 valid router certificate, BGPsec_Path attributes 807 associated with that certificate will be 808 unverifiable. In turn, this would cause the route 809 to be treated with lower preference than competing 810 routes that have valid BGPsec_Path attribute 811 signatures. 813 A-6.4 Modification 815 A-6.4.1 If a router certificate is modified to represent a 816 different ASN, but it still passes syntax checks, 817 then this action could cause signatures on 818 BGPsec_Path attributes to be associated with the 819 wrong AS. This could cause signed routes to be 820 inconsistent with the intent of the INR holder, 821 e.g., traffic might be routed via a different AS 822 than intended. 824 A-6.5 Revocation 826 A-6.5.1 If a router certificate were revoked, BGPsec_Path 827 attributes verifiable using that certificate would 828 not longer be considered valid. The impact would 829 be the same as for a deleted certificate, as 830 described in A-6.1. 832 A-6.6 Injection 834 A-6.6.1 Insertion of a router certificate could authorize 835 additional routers to sign BGPsec traffic for the 836 targeted ASN, and thus undermine fundamental 837 BGPsec security guarantees. If there are 838 existing, authorized router certificates for the 839 same ASN, then the injected router certificate is 840 in competition with these existing certificates. 842 3. Analysis of Actions Relative to Scenarios 844 This section examines the types of problems that can arise in four 845 scenarios described below. We consider mistakes, (successful) 846 attacks against a CA or a publication point, and situations in which 847 a CA or publication point manager is compelled to take action by a 848 law enforcement authority. 850 We explore the following four scenarios: 852 A. An INR holder operates its own CA and manages its own 853 repository publication point. 855 B. An INR holder operates its own CA, but outsources management 856 of its repository publication point to its parent or another 857 entity. 859 C. An INR holder outsources management of its CA to its parent, 860 but manages its own repository publication point. 862 D. An INR holder outsources management of its CA and its 863 publication point to its parent. 865 Note that these scenarios focus on the affected INR holder as the 866 party directly affected by an adverse action. The most serious cases 867 arise when the INR holder appears as a high-tier CA in the RPKI 868 hierarchy; in such situations subordinate INR holders may be affected 869 as a result of an action. A mistake by or an attack against a "leaf" 870 has more limited impact because all of the affected INRs belong to 871 the INR holder itself. 873 In Scenario A, actions by the INR holder can adversely affect all of 874 its resources and, transitively, resources of any subordinate CAs. 875 (If the CA is a "leaf" in the RPKI, then it has no subordinate CAs 876 and the damage is limited to its own INRs.) 878 In Scenario B, actions by the (outsourced) repository operator also 879 can adversely affect the resources of the INR holder, and those of 880 any subordinates CAs. (If the CA is a "leaf" in the RPKI, then it 881 has no subordinate CAs and the damage is limited, as in Scenario A.) 882 The range of adverse effects here includes those in Scenario A, and 883 adds a new potential source of adverse actions, i.e., the outsourced 884 repository operator. 886 In Scenario C, all signed objects associated with the INR holder are 887 generated by the parent CA but are self-hosted. (We expect this 888 scenario to be rare, because an INR holder that elects to outsource 889 CA operation seems unlikely to manage its own repository publication 890 point.) Because that CA has the private key used to sign them, it 891 can generate alternative signed objects---ones not authorized by the 892 INR holder. However, erroneous objects created by the parent CA will 893 not be published by the INR holder IF the holder checks them first. 894 Because the parent CA is acting on behalf of the INR holder, mistakes 895 by or attacks against that entity are equivalent to ones effected by 896 the INR holder in Scenario A. 898 The INR holder is most vulnerable in Scenario D. Actions by the 899 parent CA, acting on behalf of the INR holder, can adversely affect 900 all signed objects associated with that INR holder, including any 901 subordinate CA certificates. These actions will presumably translate 902 directly into publication point changes, because the parent CA is 903 managing the publication point for the INR holder. The range of 904 adverse effects here includes those in Scenarios A, B, and C. 906 3.1. Scenario A 908 In this scenario, the INR holder acts as its own CA and it manages 909 its own publication point. Actions by the INR holder can adversely 910 affect all of its resources and, transitively, resources of any 911 subordinate CAs. (If the CA is a "leaf" in the RPKI, then it has no 912 subordinate CAs and the damage is limited to its own INRs.) Mistakes 913 by the INR holder can cause any of the actions noted in Section 2. A 914 successful attack against this CA can effect all of the modification, 915 revocation, or injection actions noted in that section. (We assume 916 that objects generated by the CA are automatically published). An 917 attack against the publication point can effect all of the deletion, 918 suppression, or corruption actions noted in that section. 920 3.2. Scenario B 922 In this scenario, the INR holder acts as its own CA and but it 923 delegates management of it own publication point to a third party. 924 Mistakes by the INR holder can cause any of the modification, 925 revocation, or injection actions described in Section 2. Actions by 926 the repository operator can adversely affect the resources of the INR 927 holder, and those of any subordinate CAs. (If the CA is a "leaf" in 928 the RPKI, then it has no subordinate CAs and the damage is limited, 929 as in Scenario A.) The range of adverse effects here includes those 930 in Scenario A, and adds a new potential source of adverse actions, 931 i.e., the third party repository operator. A successful attack 932 against the CA can effect all of the modification, revocation, or 933 injection actions noted in that section (assuming that objects 934 generated by the CA are automatically published). Here, actions by 935 the publication point manager (or attacks against that entity) can 936 effect all of the deletion, suppression, or corruption actions noted 937 in Section 2. 939 3.3. Scenario C 941 In this scenario, the INR holder outsources management of its CA to 942 its parent, but manages its own repository publication point. All 943 signed objects associated with the INR holder are generated by the 944 parent CA but are self-hosted. (We expect this scenario to be rare, 945 because an INR holder that elects to outsource CA operation seems 946 unlikely to manage its own repository publication point.) Because 947 that CA has the private key used to sign them, it can generate 948 alternative signed objects -- ones not authorized by the INR holder. 949 However, erroneous objects created by the parent CA will not be 950 published by the INR holder IF the holder checks them first. Because 951 the parent CA is acting on behalf of the INR holder, mistakes by or 952 attacks against that entity are equivalent to ones effected by the 953 INR holder in Scenario A. Mistakes by the INR holder, acted upon by 954 the parent CA, can cause any of the actions noted in Section 2. 955 Actions unilaterally undertaken by the parent CA also can have the 956 same effect, unless the INR holder checks the signed objects before 957 publishing them. A successful attack against the parent CA can 958 effect all of the modification, revocation, or injection actions 959 noted in Section 2, unless the INR holder checks the signed objects 960 before publishing them. An attack against the INR holder (in its 961 role as repository operator) can effect all of the deletion, 962 suppression, or corruption actions noted in Section 2 (because the 963 INR holder is managing its publication point), unless the INR holder 964 checks the signed objects before publishing them. (An attack against 965 the INR holder implies that the path it uses to direct the parent CA 966 to issue and publish objects has been compromised.) 968 3.4. Scenario D 970 In this scenario an INR holder outsources management of both its CA 971 and its publication point to its parent. The INR holder is most 972 vulnerable in this scenario. Actions by the parent CA, acting on 973 behalf of the INR holder, can adversely affect all signed objects 974 associated with that INR holder, including any subordinate CA 975 certificates. These actions will presumably translate directly into 976 publication point changes, because the parent CA is managing the 977 publication point for the INR holder. The range of adverse effects 978 here includes those in Scenarios A, B, and C. Mistakes by the INR 979 holder, acted upon by the parent CA, can cause any of the actions 980 noted in Section 2. Actions unilaterally undertaken by the parent CA 981 also can have the same effect. A successful attack against the 982 parent CA can effect all of the modification, revocation, or 983 injection actions noted in Section 2. An attack against the parent 984 CA can also effect all of the deletion, suppression, or corruption 985 actions noted in Section 2 (because the parent CA is managing the INR 986 holder's publication point). 988 4. Security Considerations 990 This informational document describes a threat model for the RPKI, 991 focusing on mistakes by or attacks against CAs and independent 992 repository managers. It is intended to provide a basis for the 993 design of future RPKI security mechanisms that seek to address the 994 concerns associated with such actions. 996 The analysis in this document identifies a number of circumstances in 997 which attacks or errors can have significant impacts on routing. One 998 ought not interpret this as a condemnation of the RPKI. It is only 999 an attempt to document the implications of a wide range of attacks 1000 and errors, in the context of the RPKI. The primary alternative 1001 mechanism for disseminating routing information is Internet Routing 1002 Registry (IRR) technology ([RFC2650], [RFC2725]), which uses the 1003 Routing Policy Specification Language (RPSL) [RFC2622]. IRR 1004 technology exhibits its own set of security problems, which are 1005 discussed in [RFC7682]. 1007 5. IANA Considerations 1009 This document has no actions for IANA. 1011 6. Acknowledgements 1013 The authors thank Richard Hansen and David Mandelberg for their 1014 extensive review, feedback and editorial assistance. Thanks also go 1015 to Daiming Li for her editorial assistance. 1017 7. References 1019 7.1. Normative References 1021 [I-D.ietf-sidr-bgpsec-overview] 1022 Lepinski, M. and S. Turner, "An Overview of BGPsec", 1023 draft-ietf-sidr-bgpsec-overview-08 (work in progress), 1024 June 2016. 1026 [I-D.ietf-sidr-bgpsec-pki-profiles] 1027 Reynolds, M., Turner, S., and S. Kent, "A Profile for 1028 BGPsec Router Certificates, Certificate Revocation Lists, 1029 and Certification Requests", draft-ietf-sidr-bgpsec-pki- 1030 profiles-18 (work in progress), July 2016. 1032 [I-D.ietf-sidr-bgpsec-protocol] 1033 Lepinski, M. and K. Sriram, "BGPsec Protocol 1034 Specification", draft-ietf-sidr-bgpsec-protocol-18 (work 1035 in progress), August 2016. 1037 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1038 Requirement Levels", BCP 14, RFC 2119, 1039 DOI 10.17487/RFC2119, March 1997, 1040 . 1042 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 1043 Addresses and AS Identifiers", RFC 3779, 1044 DOI 10.17487/RFC3779, June 2004, 1045 . 1047 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1048 RFC 5652, DOI 10.17487/RFC5652, September 2009, 1049 . 1051 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 1052 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 1053 February 2012, . 1055 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 1056 Resource Certificate Repository Structure", RFC 6481, 1057 DOI 10.17487/RFC6481, February 2012, 1058 . 1060 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 1061 Origin Authorizations (ROAs)", RFC 6482, 1062 DOI 10.17487/RFC6482, February 2012, 1063 . 1065 [RFC6483] Huston, G. and G. Michaelson, "Validation of Route 1066 Origination Using the Resource Certificate Public Key 1067 Infrastructure (PKI) and Route Origin Authorizations 1068 (ROAs)", RFC 6483, DOI 10.17487/RFC6483, February 2012, 1069 . 1071 [RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for 1072 Use in the Resource Public Key Infrastructure (RPKI)", 1073 RFC 6485, DOI 10.17487/RFC6485, February 2012, 1074 . 1076 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 1077 "Manifests for the Resource Public Key Infrastructure 1078 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, 1079 . 1081 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 1082 X.509 PKIX Resource Certificates", RFC 6487, 1083 DOI 10.17487/RFC6487, February 2012, 1084 . 1086 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object 1087 Template for the Resource Public Key Infrastructure 1088 (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, 1089 . 1091 [RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification 1092 Authority (CA) Key Rollover in the Resource Public Key 1093 Infrastructure (RPKI)", BCP 174, RFC 6489, 1094 DOI 10.17487/RFC6489, February 2012, 1095 . 1097 [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) 1098 Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493, 1099 February 2012, . 1101 [RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility 1102 Procedure for the Resource Public Key Infrastructure 1103 (RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April 1104 2013, . 1106 [RFC7132] Kent, S. and A. Chi, "Threat Model for BGP Path Security", 1107 RFC 7132, DOI 10.17487/RFC7132, February 2014, 1108 . 1110 7.2. Informative References 1112 [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., 1113 Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, 1114 "Routing Policy Specification Language (RPSL)", RFC 2622, 1115 DOI 10.17487/RFC2622, June 1999, 1116 . 1118 [RFC2650] Meyer, D., Schmitz, J., Orange, C., Prior, M., and C. 1119 Alaettinoglu, "Using RPSL in Practice", RFC 2650, 1120 DOI 10.17487/RFC2650, August 1999, 1121 . 1123 [RFC2725] Villamizar, C., Alaettinoglu, C., Meyer, D., and S. 1124 Murphy, "Routing Policy System Security", RFC 2725, 1125 DOI 10.17487/RFC2725, December 1999, 1126 . 1128 [RFC7682] McPherson, D., Amante, S., Osterweil, E., Blunk, L., and 1129 D. Mitchell, "Considerations for Internet Routing 1130 Registries (IRRs) and Routing Policy Configuration", 1131 RFC 7682, DOI 10.17487/RFC7682, December 2015, 1132 . 1134 Authors' Addresses 1136 Stephen Kent 1137 BBN Technologies 1138 10 Moulton St 1139 Cambridge, MA 02138-1119 1140 USA 1142 Email: kent@bbn.com 1144 Di Ma 1145 ZDNS 1146 4 South 4th St. Zhongguancun 1147 Haidian, Beijing 100190 1148 China 1150 Email: madi@zdns.cn