idnits 2.17.1 draft-ietf-sidr-adverse-actions-02.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 (August 4, 2016) is 2821 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-17 ** 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: February 5, 2017 ZDNS 6 August 4, 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-02 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 based on examination of the data items in the 18 RPKI repository, as controlled by a CA (or independent repository 19 manager) and fetched by Relying Parties (RPs). The analysis is 20 performed from the perspective of an affected INR holder. The 21 analysis does not purport to be comprehensive; it does represent an 22 orderly way to analyze a number of ways that errors by or attacks 23 against a CA or repository manager can affect the RPKI and routing 24 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 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 February 5, 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 . . . . . . . . . . . . . . . . . . . . . . . 20 73 3.4. Scenario D . . . . . . . . . . . . . . . . . . . . . . . 21 74 4. Security Considerations . . . . . . . . . . . . . . . . . . . 21 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 . . . . . . . . . . . . . . . . . . . . . . . 24 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". 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, and thus the change may be contractually 93 justified, even though viewed as adverse by the INR holder. This 94 document examines the implications of adverse actions with respect to 95 INRs irrespective of the cause of the actions. 97 Additionally, when a ROA or router certificate is created that 98 "competes" with an existing ROA or router certificate (respectively), 99 the creation of the new ROA or router certificate may be adverse. (A 100 newer ROA competes with an older ROA if the newer ROA points to a 101 different ASN, contains the same or a more specific prefix, and is 102 issued by a different CA. A newer router certificate competes with 103 an older router certificate if the newer one contains the same ASN a 104 different public key, and is issued by a different CA.) Note that 105 transferring resources, or changing of upstream providers may yield 106 competing ROAs and/or router certificates, under some circumstances. 107 Thus not all instances of competition are adverse actions. 109 As noted above, adverse changes to RPKI data may arise due to several 110 types of causes. A CA may make a mistake in managing the RPKI 111 objects it signs, or it may be subject to an attack. If an attack 112 allows an adversary to use the private key of that CA to sign RPKI 113 objects, then the effect is analogous to the CA making mistakes. 114 There is also the possibility that a CA or repository operator may be 115 subject to legal measures that compel them to make adverse changes to 116 RPKI data. In many cases, such actions may be hard to distinguish 117 from mistakes or attacks, other than with respect to the time 118 required to remedy the adverse action. (Presumably the CA will take 119 remedial action when a mistake or an attack is detected, so the 120 effects are similar in these cases. If a CA has been legally 121 compelled to effect an adverse change, remediation will likely not be 122 swift.) 124 This document analyzes the various types of actions by a CA (or 125 independent repository operator) that can adversely affect the INRs 126 associated with that CA, as well as the INRs of subordinate CAs. The 127 analysis is based on examination of the data items in the RPKI 128 repository, as controlled by a CA (or independent repository 129 operator) and fetched by Relying Parties (RPs). The analysis is done 130 from the perspective of an affected INR holder. 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. 283 If the 3779 extensions in the suppressed 284 certificate changed, the impact would be the same 285 as in 1.4.1. If the AIA extension changed in the 286 suppressed certificate, the impact would be the 287 same as in 1.4.4. 289 A-1.3 Corruption 291 A-1.3.1 Corruption of a CA certificate will cause it to be 292 rejected by RPs. In turn, this may cause 293 subordinate signed objects to become invalid. An 294 RP that has cached the subtree under the affected 295 CA certificate may continue to view it as valid, 296 until objects expire. But changed or new objects 297 might not be retrieved, depending on details of 298 the design of the RP software. Thus this action 299 may be equivalent to suppressing changes to the 300 affected subtree. 302 A-1.4 Modification 304 A-1.4.1 If a CA certificate is modified, but still 305 conforms to the RPKI certificate profile 306 [RFC6485], it will be accepted by RPs. If an 307 [RFC3779] extension in this certificate is changed 308 to exclude INRs that were previously present, then 309 subordinate signed objects will become invalid if 310 they rely on the excised INRs. If these objects 311 are CA certificates, their subordinate signed 312 objects will be treated as invalid. If the 313 objects are ROAs, the binding expressed by the 314 affected ROAs will be ignored by RPs. If the 315 objects are router certificates, BGPsec_Path 316 attributes [I-D.ietf-sidr-bgpsec-protocol] 317 verifiable under these certificates will be 318 considered invalid. 320 A-1.4.2 If the SIA extension of a CA certificate is 321 modified to refer to another publication point, 322 this will cause an RP to look at another location 323 for subordinate objects. This could cause RPs to 324 not acquire the objects that the INR holder 325 intended to be retrieved - manifests, ROAs, router 326 certificates, Ghostbuster records, or any 327 subordinate CA certificates associated with that 328 CA. If the objects at this new location contain 329 invalid signatures or appear to be corrupted, they 330 may be rejected. In this case, cached versions of 331 the objects may be viewed as valid by an RP, until 332 they expire. If the objects at the new location 333 have valid signatures and pass path validation 334 checks, they will replace the cached objects, 335 effectively replacing the INR holder's objects. 337 A-1.4.3 If the AIA extension in a CA certificate is 338 modified, it would point to a different CA 339 certificate, not the parent CA certificate. This 340 extension is used only for path discovery, not 341 path validation. Path discovery in the RPKI is 342 usually performed on a top-down basis, starting 343 with TAs and recursively descending the RPKI 344 hierarchy. Thus there may be no impact on the 345 ability of clients to acquire and validate 346 certificates if the AIA is modified. 348 A-1.4.4 If the Subject Public Key Info (and Subject Key 349 Identifier extension) in a CA certificate is 350 modified to contain a public key corresponding to 351 a private key held by the parent, the parent could 352 sign objects as children of the affected CA 353 certificate. With this capability, the parent 354 could replace the INR holder, issuing new signed 355 objects that would be accepted by RPs (as long as 356 they do not violate the path validation criteria). 357 This would enable the parent to effect 358 modification, revocation, and injection actions 359 against all of the objects under the affected CA 360 certificate, including subordinate CA 361 certificates. (Note that key rollover also yields 362 a new CA certificate. However, the new 363 certificate will co-exist with the old one for a 364 while, which may help distinguish this legitimate 365 activity from an adverse action.) 367 A-1.5 Revocation 369 A-1.5.1 If a CA certificate is revoked an RP will treat as 370 invalid all subordinate signed objects, both 371 immediate and transitively. The effects are 372 essentially the same as described in A-3.4.2. 374 A-1.6 Injection 376 A-1.6.1 If a CA certificate is injected the impact will 377 depend on the data contained in the injected 378 certificate. Changes will generally be equivalent 379 to modification actions as described in A-1.4. 381 2.2. Manifest 383 Each repository publication point contains a manifest [RFC6486]. The 384 RPKI incorporates manifests to enable RPs to detect suppression and/ 385 or substitution of (more recent) publication point objects, as the 386 result of a mistake or attack. A manifest enumerates (by filename) 387 all of the other signed objects at the publication point. The 388 manifest also contains a hash of each enumerated file, to enable an 389 RP to determine if the named file content matches what the INR holder 390 identified in the manifest. 392 A manifest is an RPKI signed object, so it is validated as per 393 [RFC6488]. If a manifest is modified in a way that causes any of 394 these checks to fail, the manifest will be considered invalid. 395 Suppression of a manifest itself (indicated by a stale manifest) also 396 can cause an RP to not detect suppression of other signed objects at 397 the publication point. (Note that if a Manifest's EE certificate 398 expires at the time that the Manifest is scheduled to be replaced, a 399 delay in publication will cause the Manifest to become invalid, not 400 merely stale. This very serious outcome should be avoided, e.g., by 401 making the Manifest EE certificate's notAfter value the same as that 402 of the CA certificate under which it was issued). If a signed object 403 at a publication point can be validated (using the rules applicable 404 for that object type), then an RP MAY accept that object, even if 405 there is no matching entry for it on the manifest. However, it 406 appears that most RP software ignores publication point data that 407 fails to match Manifest entries (at the time this document was 408 written). 410 Corruption, suppression, modification, or deletion of a manifest 411 might not affect RP processing of other publication point objects, as 412 specified in [RFC6486]. However, as noted above, many RP 413 implementations ignore objects that are present at a publication 414 point but not listed in a valid Manifest. Thus the following actions 415 against a manifest can impact RP processing: 417 A-2.1 Deletion 419 A-2.1.1 A Manifest may be deleted from the indicated 420 publication point. In this circumstance an RP may 421 elect to use the previous Manifest (if available), 422 and may ignore any new/changed objects at the 423 publication point. The implications of this 424 action are equivalent to suppression of 425 publication of the objects that are not recognized 426 by RPs because the new objects are not present in 427 the old Manifest. For example, a new ROA could be 428 ignored (A-1.2). A newly issued CA certificate 429 might be ignored (A-1.1). A subordinate CA 430 certificate that was revoked might still be viewed 431 as valid by RPs (A-4.1). A new or changed router 432 certificate might be ignored (A-6.2) as would a 433 revised Ghostbusters record (A-4.1). 435 A-2.2 Suppression 437 A-2.2.1 Publication of a newer Manifest may be suppressed. 438 Suppression of a newer Manifest probably will 439 cause an RP to rely on a cached Manifest (if 440 available). The older Manifest would not 441 enumerate newly added objects, and thus those 442 objects might be ignored by an RP, equivalent to 443 deletion of those objects (A-1.1, A-3.1, A-4.1, 444 A-5.1, A-6.1). 446 A-2.3 Corruption 448 A-2.3.1 A Manifest may be corrupted. A corrupted Manifest 449 will be rejected by RPs. This may cause RPs to 450 rely on a previous manifest, with the same impact 451 as A-2.2. If an RP does not revert to using a 452 cached Manifest, the impact of this action is very 453 severe, i.e., all publication point objects 454 probably will be viewed as invalid, including 455 subordinate tree objects. This is equivalent to 456 revoking or deleting an entire subtree (see 457 A-4.4.2). 459 A-2.4 Modification 461 A-2.4.1 A Manifest may be modified to remove one or more 462 objects. Because the modified Manifest is viewed 463 as valid by RPs, any objects that were removed may 464 be ignored by RPs. This is equivalent to deleting 465 these objects from the repository. The impact of 466 this action will vary, depending on which objects 467 are (effectively) removed. However, the impact is 468 equivalent to deletion of the object in question, 469 (A-1.1, A-3.1, A-4.1, A-5.1, A-6.1). 471 A-2.4.2 A Manifest may be modified to add one or more 472 objects. If an added object has a valid signature 473 (and is non-expired), it will be accepted by RPs 474 and processed accordingly. If the added object 475 was previously deleted by the INR holder, this 476 action is equivalent to suppressing deletion of 477 that object. If the object is newly created, or 478 modified, it is equivalent to a modification or 479 injection action for the type of object in 480 question, and thus is discussed in the relevant 481 section for those actions for the object type. 483 A-2.4.3 A Manifest may be modified to list an incorrect 484 hash for one or more objects. An object with an 485 incorrect hash may be ignored by an RP. Thus the 486 effect may be equivalent to corrupting the object 487 in question, although the error reported by RP 488 software would differ from that reported for a 489 corrupted object. (The Manifest specifications do 490 not require an RP to ignore an object that has a 491 valid signature and that is not revoked or 492 expired, but for which the hash doesn't match the 493 object. However, an RP may elect to do so.) 495 A-2.5 Revocation 497 A-2.5.1 A Manifest may be revoked (by including its EE 498 certificate on the CRL for the publication point). 499 A revoked Manifest will be ignored by an RP, which 500 probably would revert to an older (cached) 501 Manifest. The implications for RPs are equivalent 502 to A-2.1, with regard to new/changed objects. 504 A-2.6 Injection 506 A-2.6.1 A Manifest representing different objects may be 507 injected into a publication point. The effects 508 are the same as for a modified Manifest (see 509 above). The impact will depend on the type of the 510 affected object(s), and thus is discussed in the 511 relevant section(s) for each object type. 513 2.3. Certificate Revocation List 515 Each publication point contains a CRL that enumerates revoked (not 516 yet expired) certificates issued by the CA associated with the 517 publication point [RFC6481]. 519 Adverse actions against a CRL can cause the following errors: 521 A-3.1 Deletion 523 A-3.1.1 If a CRL is deleted, RPs will continue to use an 524 older, previously fetched Certificate Revocation 525 List. As a result, they will not be informed of 526 any changes in revocation status of subordinate CA 527 or router certificates or the EE certificates of 528 signed objects, e.g., ROAs. This action is 529 equivalent to corruption of a CRL, since a 530 corrupted CRL will not be accepted by an RP. 532 A-3.1.2 Deletion of a CRL could cause an RP to continue to 533 accept a ROA that no longer expresses the intent 534 of an INR holder. As a result, an announcement 535 for the affected prefixes would be viewed as 536 Valid, instead of NotFound or Invalid. In this 537 case, the effect is analogous to A-5.2. 539 A-3.1.3 If a router certificate were revoked, and the CRL 540 were deleted, RPs would not be aware of the 541 revocation. They might continue to accept the 542 old, revoked, router certificate. If the 543 certificate had been revoked due to a compromise 544 of the router's private key, RPs would be 545 vulnerable to accepting routes signed by an 546 unauthorized entity. 548 A-3.1.4 If a subordinate CA certificate were revoked on 549 the deleted CRL, the revocation would not take 550 effect. This could interfere with a transfer of 551 address space from the subordinate CA, adversely 552 affecting routing to the new holder of the space. 554 A-3.2 Suppression 556 A-3.2.1 If publication of the most recent CRL is 557 suppressed, an RP will not be informed of the most 558 recent revocation status of subordinate CA or 559 router certificates or the EE certificates of 560 signed objects. If an EE certificate has been 561 revoked and the associated signed object is still 562 present in the publication point, an RP might 563 mistakenly treat that object as valid. (This 564 would happen if the object is still in the 565 manifest or the RP is configured to process valid 566 objects that are not on the manifest.) This type 567 of action is of special concern if the affected 568 object is a ROA, a router certificate, or a 569 subordinate CA certificate. The effects here are 570 equivalent to CRL deletion (A-3.1), but 571 suppression of a new CRL may not even be reported 572 as an error, i.e., if the suppressed CRL were 573 issued before the NextUpdate time (of the previous 574 CRL). 576 A-3.3 Corruption 578 A-3.3.1 If a CRL is corrupted, an RP will reject it. If a 579 prior CRL has not yet exceeded its NextUpdate 580 time, an RP will continue to use the prior CRL. 581 Even if the prior CRL has passed the NextUpdate 582 time, an RP may choose to continue to rely on the 583 prior CRL. The effects are essentially equivalent 584 to suppression or deletion of a CRL (A-3.1, 585 A-3.2). 587 A-3.4 Modification 589 A-3.4.1 If a CRL is modified to erroneously list a signed 590 object's EE certificate as revoked, the 591 corresponding object will be treated as invalid by 592 RPs, even if it is present in a publication point. 593 If this object is a ROA, the (legitimate) binding 594 expressed by the ROA will be ignored by an RP (see 595 A-5.5). If a CRL is modified to erroneously list 596 a router certificate as revoked, a path signature 597 associated with that certificate will be treated 598 as Not Valid by RPs (see A-6.5). 600 A-3.4.2 If a CRL is modified to erroneously list a CA 601 certificate as revoked, that CA and all 602 subordinate signed objects will be treated as 603 invalid by RPs. Depending on the location of the 604 affected CA in the hierarchy, these effects could 605 be very substantial, causing routes that should be 606 Valid to be treated as NotFound. 608 A-3.4.3 If a CRL is modified to omit a revoked EE, router, 609 or CA certificate, RPs likely will continue to 610 accept the revoked, signed object as valid. This 611 contravenes the intent of the INR holder. If an 612 RP continues to accept a revoked ROA, it may make 613 routing decisions on now-invalid data. This could 614 cause valid routes to be de-preferenced and 615 invalid routes to continue to be accepted. 617 A-3.5 Revocation 619 A-3.5.1 A CRL cannot be revoked, per se, but it will fail 620 validation if the CA certificate under which it 621 was issued is revoked. See A-1.5 for a discussion 622 of that action. 624 A-3.6 Injection 626 A-3.6.1 Insertion of a bogus CRL can have the same effects 627 as listed above for a modified CRL, depending on 628 how the inserted CRL differs from the correct CRL. 630 2.4. ROA 632 In addition to the generic RPKI object syntax checks, ROA validation 633 requires that the signature on the ROA can be validated using the 634 public key from the EE certificate embedded in the ROA [RFC6482]. It 635 also requires that the EE certificate be validated consistently with 636 the procedures described in [RFC6482] and [RFC6487]. Adverse actions 637 against a ROA can cause the following errors: 639 A-4.1 Deletion 641 A-4.1.1 A ROA may be deleted from the indicated 642 publication point. The result is to void the 643 binding between the prefix(es) and the AS number 644 in the ROA. An RP that previously viewed this 645 binding as authentic will now not have any 646 evidence about its validity. For origin 647 validation, this means that a legitimate route 648 will be treated as NotFound (if there are no other 649 ROAs for the same prefix) or Invalid (if there is 650 another ROA for the same prefix, but with a 651 different AS number). 653 A-4.2 Suppression 655 A-4.2.1 Publication of a newer ROA may be suppressed. If 656 the INR holder intended to change the binding 657 between the prefix(es) and the AS number in the 658 ROA, this change will not be effected. As a 659 result, RPs may continue to believe an old prefix/ 660 ASN binding that is no longer what the INR holder 661 intended. 663 A-4.2.2 If an INR holder intends to issue and publish two 664 (or more) new ROAs for the same address space, one 665 (or more) of the new ROAs may be suppressed while 666 the other is published. In this case, RPs will 667 de-preference the suppressed prefix/ASN binding. 668 Suppression of the new ROA might cause traffic to 669 flow to an ASN other than the one(s) intended by 670 the INR holder. 672 A-4.2.3 If an INR holder intends to delete all ROAs for 673 the same address space, some of them may be 674 retained while the others are deleted. Preventing 675 the deletion of some ROAs can cause traffic to 676 continue to be delivered to the ASNs that were 677 advertised by these ROAs. Deletion of all ROAs is 678 consistent with a transfer of address space to a 679 different INR holder, in a phased fashion. Thus 680 this sort of attack could interfere with the 681 successful transfer of the affected address space 682 (until such time as the prefixes are removed from 683 the previous INR holder's CA certificate). 685 A-4.3 Corruption 687 A-4.3.1 A ROA may be corrupted. A corrupted ROA will be 688 ignored by an RP, so the effect is essentially the 689 same as for A-4.1 and 4.5. A possible difference 690 is that an RP may be alerted to the fact that the 691 ROA was corrupted, which might attract attention 692 to the attack. 694 A-4.4 Modification 696 A-4.4.1 A ROA may be modified so that the Autonomous 697 System Number (ASN) or one or more of the address 698 blocks in a ROA is different from the values the 699 INR holder intended for this ROA. (This action 700 assumes that the modified ROA's ASN and address 701 ranges are authorized for use by the INR holder.) 702 This attack will cause RPs to de-preference the 703 legitimate prefix/ASN binding intended by the INR 704 holder. 706 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 803 A-6.3.1 Corruption of a router certificate will result in 804 the certificate being rejected by RPs. Absent a 805 valid router certificate, BGPsec_Path attributes 806 associated with that certificate will be 807 unverifiable. In turn, this would cause the route 808 to be treated with lower preference than competing 809 routes that have valid BGPsec_Path attribute 810 signatures. 812 A-6.4 Modification 814 A-6.4.1 If a router certificate is modified to represent a 815 different ASN, but it still passes syntax checks, 816 then this action could cause signatures on 817 BGPsec_Path attributes to be associated with the 818 wrong AS. This could cause signed routes to be 819 inconsistent with the intent of the INR holder, 820 e.g., traffic might be routed via a different AS 821 than intended. 823 A-6.5 Revocation 825 A-6.5.1 If a router certificate were revoked, BGPsec_Path 826 attributes verifiable using that certificate would 827 not longer be considered valid. The impact would 828 be the same as for a deleted certificate, as 829 described in A-6.1. 831 A-6.6 Injection 833 A-6.6.1 Insertion of a router certificate could authorize 834 additional routers to sign BGPsec traffic for the 835 targeted ASN, and thus undermine fundamental 836 BGPsec security guarantees. If there are 837 existing, authorized router certificates for the 838 same ASN, then the injected router certificate is 839 in competition with these existing certificates. 841 3. Analysis of Actions Relative to Scenarios 843 This section examines the types of problems that can arise in four 844 scenarios described below. We consider mistakes, (successful) 845 attacks against a CA or a publication point, and situations in which 846 a CA or publication point manager is compelled to take action by a 847 law enforcement authority. 849 We explore the following four scenarios: 851 A. An INR holder operates its own CA and manages its own 852 repository publication point. 854 B. An INR holder operates its own CA, but outsources management 855 of its repository publication point to its parent or another 856 entity. 858 C. An INR holder outsources management of its CA to its parent, 859 but manages its own repository publication point. 861 D. An INR holder outsources management of its CA and its 862 publication point to its parent. 864 Note that these scenarios focus on the affected INR holder as the 865 party directly affected by an adverse action. The most serious cases 866 arise when the INR holder appears as a high-tier CA in the RPKI 867 hierarchy; in such situations subordinate INR holders may be affected 868 as a result of an action. A mistake by or an attack against a "leaf" 869 has more limited impact because all of the affected INRs belong to 870 the INR holder itself. 872 In Scenario A, actions by the INR holder can adversely affect all of 873 its resources and, transitively, resources of any subordinate CAs. 874 (If the CA is a "leaf" in the RPKI, then it has no subordinate CAs 875 and the damage is limited to its own INRs.) 877 In Scenario B, actions by the (outsourced) repository operator also 878 can adversely affect the resources of the INR holder, and those of 879 any subordinates CAs. (If the CA is a "leaf" in the RPKI, then it 880 has no subordinate CAs and the damage is limited, as in Scenario A.) 881 The range of adverse effects here includes those in Scenario A, and 882 adds a new potential source of adverse actions, i.e., the outsourced 883 repository operator. 885 In Scenario C, all signed objects associated with the INR holder are 886 generated by the parent CA but are self-hosted. (We expect this 887 scenario to be rare, because an INR holder that elects to outsource 888 CA operation seems unlikely to manage its own repository publication 889 point.) Because that CA has the private key used to sign them, it 890 can generate alternative signed objects---ones not authorized by the 891 INR holder. However, erroneous objects created by the parent CA will 892 not be published by the INR holder IF the holder checks them first. 893 Because the parent CA is acting on behalf of the INR holder, mistakes 894 by or attacks against that entity are equivalent to ones effected by 895 the INR holder in Scenario A. 897 The INR holder is most vulnerable in Scenario D. Actions by the 898 parent CA, acting on behalf of the INR holder, can adversely affect 899 all signed objects associated with that INR holder, including any 900 subordinate CA certificates. These actions will presumably translate 901 directly into publication point changes, because the parent CA is 902 managing the publication point for the INR holder. The range of 903 adverse effects here includes those in Scenarios A, B, and C. 905 3.1. Scenario A 907 In this scenario, the INR holder acts as its own CA and it manages 908 its own publication point. Actions by the INR holder can adversely 909 affect all of its resources and, transitively, resources of any 910 subordinate CAs. (If the CA is a "leaf" in the RPKI, then it has no 911 subordinate CAs and the damage is limited to its own INRs.) Mistakes 912 by the INR holder can cause any of the actions noted in Section 2. A 913 successful attack against this CA can effect all of the modification, 914 revocation, or injection actions noted in that section. (We assume 915 that objects generated by the CA are automatically published). An 916 attack against the publication point can effect all of the deletion, 917 suppression, or corruption actions noted in that section. 919 3.2. Scenario B 921 In this scenario, the INR holder acts as its own CA and but it 922 delegates management of it own publication point to a third party. 923 Mistakes by the INR holder can cause any of the modification, 924 revocation, or injection actions described in Section 2. Actions by 925 the repository operator can adversely affect the resources of the INR 926 holder, and those of any subordinate CAs. (If the CA is a "leaf" in 927 the RPKI, then it has no subordinate CAs and the damage is limited, 928 as in Scenario A.) The range of adverse effects here includes those 929 in Scenario A, and adds a new potential source of adverse actions, 930 i.e., the third party repository operator. A successful attack 931 against the CA can effect all of the modification, revocation, or 932 injection actions noted in that section (assuming that objects 933 generated by the CA are automatically published). Here, actions by 934 the publication point manager (or attacks against that entity) can 935 effect all of the deletion, suppression, or corruption actions noted 936 in Section 2. 938 3.3. Scenario C 940 In this scenario, the INR holder outsources management of its CA to 941 its parent, but manages its own repository publication point. All 942 signed objects associated with the INR holder are generated by the 943 parent CA but are self-hosted. (We expect this scenario to be rare, 944 because an INR holder that elects to outsource CA operation seems 945 unlikely to manage its own repository publication point.) Because 946 that CA has the private key used to sign them, it can generate 947 alternative signed objects -- ones not authorized by the INR holder. 948 However, erroneous objects created by the parent CA will not be 949 published by the INR holder IF the holder checks them first. Because 950 the parent CA is acting on behalf of the INR holder, mistakes by or 951 attacks against that entity are equivalent to ones effected by the 952 INR holder in Scenario A. Mistakes by the INR holder, acted upon by 953 the parent CA, can cause any of the actions noted in Section 2. 954 Actions unilaterally undertaken by the parent CA also can have the 955 same effect, unless the INR holder checks the signed objects before 956 publishing them. A successful attack against the parent CA can 957 effect all of the modification, revocation, or injection actions 958 noted in Section 2, unless the INR holder checks the signed objects 959 before publishing them. An attack against the INR holder (in its 960 role as repository operator) can effect all of the deletion, 961 suppression, or corruption actions noted in Section 2 (because the 962 INR holder is managing its publication point), unless the INR holder 963 checks the signed objects before publishing them. (An attack against 964 the INR holder implies that the path it uses to direct the parent CA 965 to issue and publish objects has been compromised.) 967 3.4. Scenario D 969 In this scenario an INR holder outsources management of both its CA 970 and its publication point to its parent. The INR holder is most 971 vulnerable in this scenario. Actions by the parent CA, acting on 972 behalf of the INR holder, can adversely affect all signed objects 973 associated with that INR holder, including any subordinate CA 974 certificates. These actions will presumably translate directly into 975 publication point changes, because the parent CA is managing the 976 publication point for the INR holder. The range of adverse effects 977 here includes those in Scenarios A, B, and C. Mistakes by the INR 978 holder, acted upon by the parent CA, can cause any of the actions 979 noted in Section 2. Actions unilaterally undertaken by the parent CA 980 also can have the same effect. A successful attack against the 981 parent CA can effect all of the modification, revocation, or 982 injection actions noted in Section 2. An attack against the parent 983 CA can also effect all of the deletion, suppression, or corruption 984 actions noted in Section 2 (because the parent CA is managing the INR 985 holder's publication point). 987 4. Security Considerations 989 This informational document describes a threat model for the RPKI, 990 focusing on mistakes by or attacks against CAs and independent 991 repository managers. It is intended to provide a basis for the 992 design of future RPKI security mechanisms that seek to address the 993 concerns associated with such actions. 995 The analysis in this document identifies a number of circumstances in 996 which attacks or errors can have significant impacts on routing. One 997 ought not interpret this as a condemnation of the RPKI. It is only 998 an attempt to document the implications of a wide range of attacks 999 and errors, in the context of the RPKI. The primary alternative 1000 mechanism for disseminating routing information is Internet Routing 1001 Registry (IRR) technology ([RFC2650], [RFC2725]), which uses the 1002 Routing Policy Specification Language (RPSL) [RFC2622]. IRR 1003 technology exhibits its own set of security problems, which are 1004 discussed in [RFC7682]. 1006 5. IANA Considerations 1008 This document has no actions for IANA. 1010 6. Acknowledgements 1012 The authors thank Richard Hansen and David Mandelberg for their 1013 extensive review, feedback and editorial assistance. Thanks also go 1014 to Daiming Li for her editorial assistance. 1016 7. References 1018 7.1. Normative References 1020 [I-D.ietf-sidr-bgpsec-overview] 1021 Lepinski, M. and S. Turner, "An Overview of BGPsec", 1022 draft-ietf-sidr-bgpsec-overview-08 (work in progress), 1023 June 2016. 1025 [I-D.ietf-sidr-bgpsec-pki-profiles] 1026 Reynolds, M., Turner, S., and S. Kent, "A Profile for 1027 BGPsec Router Certificates, Certificate Revocation Lists, 1028 and Certification Requests", draft-ietf-sidr-bgpsec-pki- 1029 profiles-18 (work in progress), July 2016. 1031 [I-D.ietf-sidr-bgpsec-protocol] 1032 Lepinski, M. and K. Sriram, "BGPsec Protocol 1033 Specification", draft-ietf-sidr-bgpsec-protocol-17 (work 1034 in progress), June 2016. 1036 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1037 Requirement Levels", BCP 14, RFC 2119, 1038 DOI 10.17487/RFC2119, March 1997, 1039 . 1041 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 1042 Addresses and AS Identifiers", RFC 3779, 1043 DOI 10.17487/RFC3779, June 2004, 1044 . 1046 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1047 RFC 5652, DOI 10.17487/RFC5652, September 2009, 1048 . 1050 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 1051 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 1052 February 2012, . 1054 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 1055 Resource Certificate Repository Structure", RFC 6481, 1056 DOI 10.17487/RFC6481, February 2012, 1057 . 1059 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 1060 Origin Authorizations (ROAs)", RFC 6482, 1061 DOI 10.17487/RFC6482, February 2012, 1062 . 1064 [RFC6483] Huston, G. and G. Michaelson, "Validation of Route 1065 Origination Using the Resource Certificate Public Key 1066 Infrastructure (PKI) and Route Origin Authorizations 1067 (ROAs)", RFC 6483, DOI 10.17487/RFC6483, February 2012, 1068 . 1070 [RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for 1071 Use in the Resource Public Key Infrastructure (RPKI)", 1072 RFC 6485, DOI 10.17487/RFC6485, February 2012, 1073 . 1075 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 1076 "Manifests for the Resource Public Key Infrastructure 1077 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, 1078 . 1080 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 1081 X.509 PKIX Resource Certificates", RFC 6487, 1082 DOI 10.17487/RFC6487, February 2012, 1083 . 1085 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object 1086 Template for the Resource Public Key Infrastructure 1087 (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, 1088 . 1090 [RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification 1091 Authority (CA) Key Rollover in the Resource Public Key 1092 Infrastructure (RPKI)", BCP 174, RFC 6489, 1093 DOI 10.17487/RFC6489, February 2012, 1094 . 1096 [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) 1097 Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493, 1098 February 2012, . 1100 [RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility 1101 Procedure for the Resource Public Key Infrastructure 1102 (RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April 1103 2013, . 1105 [RFC7132] Kent, S. and A. Chi, "Threat Model for BGP Path Security", 1106 RFC 7132, DOI 10.17487/RFC7132, February 2014, 1107 . 1109 7.2. Informative References 1111 [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., 1112 Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, 1113 "Routing Policy Specification Language (RPSL)", RFC 2622, 1114 DOI 10.17487/RFC2622, June 1999, 1115 . 1117 [RFC2650] Meyer, D., Schmitz, J., Orange, C., Prior, M., and C. 1118 Alaettinoglu, "Using RPSL in Practice", RFC 2650, 1119 DOI 10.17487/RFC2650, August 1999, 1120 . 1122 [RFC2725] Villamizar, C., Alaettinoglu, C., Meyer, D., and S. 1123 Murphy, "Routing Policy System Security", RFC 2725, 1124 DOI 10.17487/RFC2725, December 1999, 1125 . 1127 [RFC7682] McPherson, D., Amante, S., Osterweil, E., Blunk, L., and 1128 D. Mitchell, "Considerations for Internet Routing 1129 Registries (IRRs) and Routing Policy Configuration", 1130 RFC 7682, DOI 10.17487/RFC7682, December 2015, 1131 . 1133 Authors' Addresses 1134 Stephen Kent 1135 BBN Technologies 1136 10 Moulton St 1137 Cambridge, MA 02138-1119 1138 USA 1140 Email: kent@bbn.com 1142 Di Ma 1143 ZDNS 1144 4 South 4th St. Zhongguancun 1145 Haidian, Beijing 100190 1146 China 1148 Email: madi@zdns.cn