idnits 2.17.1 draft-ietf-sidr-bgpsec-threats-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 18 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-sidr-arch]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 24, 2011) is 4688 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TCPMD5' is mentioned on line 109, but not defined == Unused Reference: 'RFC2119' is defined on line 690, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sidr-arch' is defined on line 716, but no explicit reference was found in the text == Unused Reference: 'I-D.sidr-res-certs' is defined on line 726, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-sidr-arch-11 == Outdated reference: A later version (-22) exists of draft-ietf-sidr-res-certs-21 == Outdated reference: A later version (-12) exists of draft-ietf-sidr-roa-format-09 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Secure Inter-Domain Routing S. Kent 3 Internet-Draft BBN 4 Intended status: Standards Track 5 Expires: December 24, 2011 6 June 24, 2011 8 Threat Model for BGP Path Security 9 draft-ietf-sidr-bgpsec-threats-00.txt 11 Abstract 13 This document describes a threat model for BGP path security 14 (BGPSEC). BGPSEC is assumed to make use of the Resource Public Key 15 Infrastructure (RPKI) already developed in the SIDR WG [I-D.ietf- 16 sidr-arch], and thus threats and attacks against the RPKI are part of 17 this model. The model assumes that BGP path security is achieved 18 through the application of digital signatures to AS_Path Info. The 19 document characterizes classes of potential adversaries that are 20 considered to be threats, and examines classes of attacks that might 21 be launched against BGPSEC. It concludes with brief discussion of 22 residual vulnerabilities. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on December 24, 2011. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Threat Characterization . . . . . . . . . . . . . . . . . . . 4 61 4. Attack Characterization . . . . . . . . . . . . . . . . . . . 5 62 4.1. Active wiretapping of links between routers . . . . . . . . 5 63 4.2. Attacks on a BGP router . . . . . . . . . . . . . . . . . . 5 64 4.3. Attacks on ISP management computers (non-CA computers) . . 7 65 4.4. Attacks on a repository publication point . . . . . . . . . 7 66 4.5 Attacks on an RPKI CA . . . . . . . . . . . . . . . . . . . 8 67 5. Residual Vulnerabilities . . . . . . . . . . . . . . . . . . . 7 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 70 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 72 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 73 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 76 1. Introduction 78 This document describes the security context in which BGPSEC is 79 intended to operate. It discusses classes of potential adversaries 80 that are considered to be threats, and classes of attacks that might 81 be launched against BGPSEC. Because BGPSEC depends on the Resource 82 Public Key Infrastructure (RPKI), threats and attacks against the 83 RPKI also are discussed. 85 The motivation for developing BGPSEC, i.e., residual security 86 concerns for BGP, is well described in several documents, including 87 "BGP Security Vulnerabilities Analysis" [RFC4272] and "Design and 88 Analysis of the Secure Border Gateway Protocol (S-BGP)" [Kent2000]. 89 All of these papers note that BGP does not include mechanisms that 90 allow an Autonomous System (AS) to verify the legitimacy and 91 authenticity of BGP route advertisements. (BGP now mandates support 92 for mechanisms to secure peer-peer communication, i.e., for the links 93 that connect BGP routers. There are several secure protocol options 94 to addresses this security concern, e.g., IPsec [RFC4301] and TCP-AO 95 [RFC5925]. This document briefly notes the need to address this 96 aspect of BGP security, but focuses on application layer BGP security 97 issues that are addressed by BGPSEC.) 99 RFC 4272 succinctly notes: 101 BGP speakers themselves can inject bogus routing information, 102 either by masquerading as any other legitimate BGP speaker, or by 103 distributing unauthorized routing information as themselves. 104 Historically, misconfigured and faulty routers have been 105 responsible for widespread disruptions in the Internet. The 106 legitimate BGP peers have the context and information to produce 107 believable, yet bogus, routing information, and therefore have the 108 opportunity to cause great damage. The cryptographic protections 109 of [TCPMD5] and operational protections cannot exclude the bogus 110 information arising from a legitimate peer. The risk of 111 disruptions caused by legitimate BGP speakers is real and cannot be 112 ignored. 114 BGPSEC is intended to address the concerns cited above, to provide 115 significantly improved path security, and to build upon the secure 116 route origination foundation offered by use of the RPKI. 117 Specifically, the RPKI enables relying parties (RPs) to determine of 118 the origin AS for a path was authorized to advertise the prefix 119 contained in a BGP update message. This security feature is enabled 120 by the use of two types of digitally signed data: a PKI [I-D.sidr- 121 res-certs] that associates one or more prefixes with the public 122 key(s) of an address space holder, and Route Origination 123 Authorizations (ROAs) [I-D.roa-format] that allows a prefix holder to 124 specify the AS(es) that are authorized to originate routes for a 125 prefix. 127 The security model adopted for BGPSEC does not assume an "oracle" 128 that can see all of the BGP inputs and outputs associated with every 129 AS or every BGP router. Instead, the model is based on a local notion 130 of what constitutes legitimate, authorized behavior by the BGP 131 routers associated with an AS. This is an AS-centric model of secure 132 operation, consistent with the AS-centric model that BGP employs for 133 routing. This model forms the basis for the discussion that follows. 135 This document begins with a brief set of definitions relevant to the 136 subsequent sections. It then discusses classes of adversaries that 137 are perceived as viable threats against routing in the public 138 Internet. It continues to explore a range of attacks that might be 139 effected by these adversaries, against both path security and the 140 infrastructure upon which BGPSEC relies. It concludes with a brief 141 review of residual vulnerabilities. 143 2. Terminology 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in RFC 2119. 149 The following security and routing terminology definitions are 150 employed in this document. 152 Adversary - An adversary is an entity (e.g., a person or an 153 organization) perceived as malicious, relative to the security policy 154 of a system. The decision to characterize an entity as an adversary 155 is made by those responsible for the security of a system. Often one 156 describes classes of adversaries with similar capabilities or 157 motivations, rather than specific individuals or organizations. 159 Attack - An attack is an action that attempts to violate the security 160 policy of a system, e.g., by exploiting a vulnerability. There is 161 often a many to one mapping of attacks to vulnerabilities, because 162 many different attacks may be used to exploit a vulnerability. 164 Autonomous System - An AS is a set of one or more IP networks 165 operated by a single administrative entity. 167 AS Number (ANS) - An ASN is a 2 or 4 byte number issued by a registry 168 to identify an AS in BGP. 170 Certification Authority (CA) - An entity that issues digital 171 certificates (e.g., X.509 certificates) and vouches for the binding 172 between the data items in a certificate. 174 Countermeasure - A countermeasure is a procedure or technique that 175 thwarts an attack, preventing it from being successful. Often 176 countermeasures are specific to attacks or classes of attacks. 178 Border Gateway Protocol (BGP) - A path vector protocol used to convey 179 "reachability" information among autonomous systems, in support of 180 inter-domain routing. 182 False (Route) Origination - If an ISP originates a route for a prefix 183 that the ISP does not hold (and that it has not been authorized to 184 originate by the prefix holder, this is termed false route 185 origination. 187 Internet Service Provider (ISP) - An organization managing (and, 188 typically, selling,) Internet services to other organizations or 189 individuals. 191 Internet Number Resources (INRs) - IPv4 or IPv6 address space and 192 ASNs 194 Internet Registry - An organization that manages the allocation or 195 distribution of INRs. This encompasses the Internet Assigned Number 196 Authority (IANA), Regional Internet Registries (RIRs), National 197 Internet Registries (NIRs), and Local Internet registries (LIRs, 198 ISPs). 200 Man in the Middle (MITM) - A MITM is an entity that is able to 201 examine and modify traffic between two (or more) parties on a 202 communication path 204 Prefix - A prefix is an IP address and a mask used to specify a set 205 of addresses that are grouped together for purposes of routing. 207 Public Key Infrastructure (PKI) - A PKI is a collection of hardware, 208 software, people, policies, and procedures used to create, manage, 209 distribute, store, and revoke digital certificates. 211 Relying Parties (RPs) - An RP is an entity that makes use of signed 212 products from a PKI, i.e., relies on signed data that is verified 213 using certificates, and CRLs from a PKI. 215 RPKI Repository System - The RPKI repository system consists of a 216 distributed set of loosely synchronized databases 217 Resource PKI (RPKI) - A PKI operated by the entities that manage 218 INRs, and that issues X509 certificates (and CRLs) that attest to the 219 holdings of INRs. 221 RPKI Signed Object - An RPKI signed object is a Cryptographic Message 222 Syntax (CMS)-encapsulated data object complying with the format and 223 semantics defined in [draft-ietf-sidr-signed-object-02.txt]. 225 Route - In the Internet, a route is a prefix and an associated 226 sequence of ASNs that indicates a path via which traffic destined for 227 the prefix can be directed. 229 Route leak - A route leak is said to occur when AS-A advertises 230 routes that it has received from an AS-B to AS-A's neighbors, but AS- 231 A is not viewed as a transit provider for the prefixes in the route. 233 Threat - A threat is a motivated, capable adversary. An adversary 234 that is not motivated to launch an attack is not a threat. An 235 adversary that is motivated but not capable of launching an attack 236 also is not a threat. 238 Vulnerability - A vulnerability is a flaw or weakness in a system's 239 design, implementation, or operation and management that could be 240 exploited to violate the security policy of a system. 242 3. Threat Characterization 244 The following classes of threats are addressed in this document. 246 BGP speakers - A BGP speaker, e.g., an ISP or a multi-homed non-ISP 247 subscriber, may be a threat. (For simplicity, the remainder of this 248 document refers to BGP speakers as ISPs.) An ISP may be motivated to 249 cause BGP routers controlled by the ISP to emit update messages with 250 inaccurate routing info. Such updates might cause traffic to flow via 251 paths that would otherwise be rejected as less advantageous by other 252 ISPs. Because the ISP controls the BGP routers that it operates, it 253 is in a position to modify their operation. Routers operated by the 254 ISP are vehicles for mounting MITM attacks on both control and data 255 plane traffic. If the ISP participates in the RPKI, it will have at 256 least CA resource certificate and may be able to generate an 257 arbitrary number of subordinate CA certificates and ROAs. It will be 258 authorized to populate (and may even host) its own repository 259 publication point. If it implements BGPSEC, it will have the ability 260 to issue certificates for its routers, and to sign updates in a 261 fashion that will be recognized by BGPSEC-enabled ISP neighbors. 263 Hackers - Hackers are considered a threat. Hackers might assume 264 control of network management computers and routers operated by ISPs, 265 including ISPs that implement BGPSEC. In such cases, hackers would be 266 able to act as a rogue ISP (see above). It is assumed that hackers 267 generally do not have the capability to effect MITM attacks on most 268 links between ISPs. Hackers might be recruited, without their 269 knowledge, by criminals or by nations, to act on their behalf. 271 Criminals - Criminals may be a threat. Criminals might persuade (via 272 threats or extortion) an ISP to act as rogue ISP (see above), and 273 thus be able to effect a wide range of attacks. Criminals might 274 persuade telecom staff to enable MITM attacks on links between 275 routers. The motivation for criminals may include the ability to 276 extort money from other ISPs or ISP clients, e.g., by adversely 277 affecting routing for these ISPs or clients. They may wish to 278 manipulate routing to conceal the sources of spam or of DoS attacks. 280 Registries - Any registry in the RPKI could be a threat. Staff at the 281 registry are capable of manipulating repository content or 282 mismanaging RPKI certificates. These actions could adversely affect 283 the operation of an ISP or a client of an ISP. The staff could be 284 motivated to do this based on political pressure from the nation in 285 which it operates (see below). 287 Nations - A nation may be a threat. A nation may control one or more 288 ISPs that operate in the nation, and thus can cause them to act as 289 rogue ISPs. A nation may have a technical active wiretapping 290 capability (e.g., within its territory) that enables it to effect 291 MITM attacks on inter-ISP traffic. It may have an ability to attack 292 and take control of routers or management network computers of ISPs 293 in other countries. A nation may control a registry that operates 294 within its territory, and might force the registry to act as a rogue 295 capacity. National threat motivations include the desire to control 296 the flow of traffic to/from the nation or to divert traffic destined 297 for other nations (for passive or active wiretapping, including DoS). 298 A manifest associated with a CA's repository publication point 299 contains a list of: 301 4. Attacks 303 This section describes classes of attacks that may be effected 304 against Internet routing. Attacks are classified based on the target 305 of the attack, as an element of the routing system, or the routing 306 security infrastructure on which BGPSEC relies. In general, attacks 307 of interest are ones that attempt to violate the integrity or 308 authenticity of BGP traffic, or which violate the authorizations 309 associated with entities participating in the RPKI. Attacks that 310 violate the implied confidentiality of routing traffic are not 311 considered significant (see 4.1 below). 313 4.1. Active wiretapping of links between routers 315 An adversary may attack the links that connect BGP routers. Passive 316 attacks are not considered, because it is assumed that most of the 317 info carried by BGP will otherwise be accessible to adversaries. 318 Several classes of adversaries are assumed to be capable of MITM 319 effecting attacks against the control plane traffic. MITM attacks may 320 be directed against BGP, BGPSEC, or against TCP or IP. Such attacks 321 include replay of selected BGP messages, selective modification of 322 BGP messages, and DoS attacks against BGP routers. 324 4.2. Attacks on a BGP router 326 An adversary may attack a BGP router, whether it implements BGPSEC or 327 not. Any adversary that controls routers legitimately, or that can 328 assume control of a router, is assumed to be able to effect the types 329 of attacks described below. Note that any router behavior that can be 330 ascribed to a local routing policy decision is not considered to be 331 an attack. This is because such behavior could be explained as a 332 result of local policy settings, and thus is beyond the scope of what 333 BGPSEC can detect as unauthorized behavior. Thus, for example, a 334 router may fail to propagate some or all route withdrawals or effect 335 "route leaks". (These behaviors are not precluded by the 336 specification for BGP, and might be the result of a local policy that 337 is not publicly disclosed. As a result, they are not considered 338 attacks.) 340 AS Insertion: A router might insert one or more ASNs, other than 341 its own ASN, into an update message. This violates the BGP spec 342 and thus is considered an attack. 344 False (route) Origination: A router might originate a route for 345 a prefix, when the AS that the router represents is not 346 authorized to originate routes for that prefix. This is an 347 attack. 349 Secure Path Downgrade: A router might remove signatures from a 350 BGPSEC update that it receives, when forwarding this update to a 351 BGPSEC-enabled neighbor. This behavior violates the BGPSEC spec 352 and thus is considered an attack. 354 Invalid Signature Insertion: A router might emit a signed update 355 with a "bad" signature, i.e., a signature that cannot be 356 validated by other BGPSEC routers. (This might occur due to use 357 of a revoked or expired certificate, a computational error, or a 358 syntactic error.) This behavior violates the BGPSEC spec and 359 thus is considered an attack. 361 Stale Path Announcement: An announcement may be propagated with 362 an origination signature segment expiry value that is not 363 current. This behavior violates the BGPSEC spec and is 364 considered a possible replay attack. 366 Premature Path Announcement Expiration: A router might emit a 367 signed update with an origin expiry time that is very short. The 368 BGPSEC protocol specification does not mandate a minimum expiry 369 time. However, an immediate neighbor of a route originator 370 should expect to see an expiry time that not substantially less 371 than XX in the future. Later routers along a path generally 372 cannot determine if a shorter expiry time is "suspicious" since 373 they cannot know how long a route may have been held by an 374 earlier AS, prior to being released. Thus this consideration 375 applies only to an immediate neighbor of a route originator. 377 MITM Attack: A cryptographic key used for point-to-point 378 security (e.g., TCP-AO or IPsec) between two BGP routers might 379 be compromised (e.g., by extraction from a router). This would 380 enable an adversary to effect MITM attacks on the link(s) where 381 the key is used. 383 Compromised Private Key: The private key associated with an RPKI 384 EE certificate issued to a router might be compromised by an 385 attack against the router. An adversary with access to this key 386 would be able to generate updates that appear to be from this 387 router (or from any routers that share this key and 388 certificate). If the adversary controlled another ISP, it could 389 use this key to forge signatures that appear to come from the 390 router(s) in question, thus making it appear that those routers 391 were misbehaving. 393 Replay Attack: An update may be signed and announced, and later 394 withdrawn. The adversary controlling intermediate routers does 395 not propagate the withdrawal but instead re-announces (i.e., 396 replays) the previous announcement within its expiry time if it 397 has not yet expired. 399 4.3. Attacks on ISP management computers (non-CA computers) 401 An adversary may choose to attack computers used by an ISP to manage 402 its network, especially its routers. Such attacks might be effected 403 by an adversary that has compromised the security of these computers. 404 This might be effected via remote attacks, extortion of selected ISP 405 staff, etc. If an adversary compromises NOC computers, it can execute 406 any management function that authorized ISP staff would have 407 performed. Thus the adversary could modify local routing policy to 408 change preferences, to black-hole certain routes, etc. This type of 409 behavior cannot be externally detected as an attack. 411 If the ISP participates in the RPKI, the adversary could manipulate 412 the RP tools that extract data from the RPKI, causing the output of 413 these tools to be corrupted in various ways. For example, an attack 414 of this sort could cause the ISP to view valid routes as not 415 validated, which could alter its routing behavior. 417 If the adversary invoked the tool used to manage the repository 418 publication point for this ISP, it could delete any objects stored 419 there (certificates, CRLs, manifests, ROAs, or subordinate CA 420 certificates). This could affect the routing status of entities that 421 have allocations/assignments from this ISP (e.g., by deleting their 422 CA certificates). 424 An attacker could invoke the tool used to request certificate 425 revocation, causing router certificates, ROAs, or subordinate CA 426 certificates to be revoked. An attack of this sort could affect not 427 only this ISP, but also any ISPs that receive allocations/assignments 428 from it, e.g., because their CA certificates were revoked. 430 It the ISP is BGPSEC-enabled, an attack of this sort could cause the 431 affected ISP to be viewed as not BGPSEC-enabled, possibly making 432 routes it emits be less preferred. 434 If an adversary invoked a tool used to request ROAs, it could 435 effectively re-allocate some of the prefixes allocated/assigned to 436 the ISP (e.g., by modifying the origin AS in ROAs). This might cause 437 other BGPSEC-enabled ISPs, and other RPKI-enabled ISPs, to view the 438 ISP as no longer originating routes for these prefixes. Multi-homed 439 subscribers of this ISP who received a PA allocation from the ISP 440 might find their traffic was now routed via other connections. 442 If the ISP is BGPSEC-enabled, and the adversary invoked a tool used 443 to request certificates, it could replace valid certificates for 444 routers with ones that might be rejected by BGPSEC-enabled 445 neighbors. 447 4.4. Attacks on a repository publication point 449 A critical element of the RPKI is the repository system. An adversary 450 might attack a repository, or a publication point within a 451 repository, to adversely affect routing. 453 This section considers only those attacks that can be launched by any 454 adversary who controls a computer hosting one or more repository 455 publication points, without access to the cryptographic keys needed 456 to generate valid RPKI signed products. Such attacks might be 457 effected by an inside or an external threat. Because all repository 458 objects are digitally signed, attacks of this sort translate into DoS 459 attacks against the RPKI RPs. There are a few distinct forms of such 460 attacks, as described below. 462 Note first that the RPKI calls for RPs to cache the data they acquire 463 and verify from the repository system. Attacks that delete signed 464 products, that insert products with "bad" signatures, that tamper 465 with object signatures, or that replace newer objects with older 466 (valid) ones, can be detected by RPs (with a few exceptions). RPs are 467 expected to make use of the cached repository data until attacks that 468 violate the integrity of publication points (and which are detected) 469 are resolved. Thus the impact of such attacks is mitigated in part by 470 the design of the repository system. 472 If an adversary inserts an object into a publication point, and the 473 object has a "bad" signature, the object will not be accepted and 474 used by RPs. 476 If an adversary modifies any signed product at a publication point, 477 the signature on the product will fail, and cause RPs to not accept 478 it. This is equivalent to deleting the object, on many respects. 480 If an adversary deletes one or more CA certificates, ROAs or the CA's 481 CRL at a publication point, the manifest for that publication point 482 will allow an RP to detect this attack. (The RP would be very unhappy 483 if there is no CRL for the CA instance anyway.) An RP can continue to 484 use the last valid instance of the deleted object as a local policy 485 option), thus minimizing the impact of such an attack. 487 If an adversary deletes a manifest (and does not replace it with an 488 older instance), that is detectable by an RP, and should result in 489 the CA being notified of the problem. An RP can continue to use the 490 last valid instance of the deleted object as a local policy option), 491 thus minimizing the impact of such an attack. 493 If an adversary deletes newly added CA certificates or ROAs, and 494 replaces the current manifest with the previous manifest, the 495 manifest (and the CRL that it matches) will be "stale" (see [ietf- 496 sidr-manifest]). This alerts an RP that there may be a problem, and, 497 hopefully, the CA responsible for the publication point will be asked 498 to remedy the problem (republish the missing CA certificates and/or 499 ROAs). An RP cannot know the content of the new certificates or ROAs 500 that are not present, but it can continue to use what it has cached. 502 If a CA revokes a CA certificate or a ROA (via deleting the 503 corresponding EE certificate), and the adversary tries to reinstate 504 that CA certificate or ROA, the adversary would have to rollback the 505 CRL and the manifest to undo this action by the CA. As above, this 506 would make the CRL and manifest stale, and this is detectable by RPs. 507 An RP cannot know which CA certificates or ROAs were deleted, and so 508 it would use the cached instances of the affected objects. Here too 509 one hopes that the CA will be notified of the problem and will 510 attempt to remedy the error. 512 In the attack scenarios above, when a CRL or manifest is described as 513 stale, this means that the next issue date for the CRL or manifest 514 has passed. Until the next issue date, an RP will not be detect the 515 attack. Thus it behooves CAs to select CRL/manifest lifetimes (the 516 two are linked) that represent an acceptable tradeoff between risk 517 and operational burdens. 519 Attacks effected by adversaries that are legitimate managers of 520 publication points can have much greater effects, and are discussed 521 below under attacks on or by CAs. 523 4.5. Attacks on an RPKI CA 525 Every entity to which INRs have been allocated/assigned is a CA in 526 the RPKI. Each CA is nominally responsible for managing the 527 repository publication point for the set of signed products that it 528 generates. (An INR holder may choose to outsource the operation of 529 the RPKI CA function, and the associated publication point. In such 530 cases, the organization operating on behalf of the INR holder becomes 531 the CA, from an operational and security perspective. The following 532 discussion does not distinguish outsourced CA operations.) 534 Note that attacks attributable to a CA may be the result of malice by 535 the CA (i.e., the CA is the adversary) or they may result from a 536 compromise of the CA. 538 All of adversaries listed in Section 2 are presumed to be capable of 539 launching attacks against the computers used to perform CA functions. 540 Some adversaries might effect an attack on a CA by violating 541 personnel or physical security controls as well. The distinction 542 between CA as adversary vs. CA as an attack victim is important. Only 543 in the latter case should one expect the CA to remedy problems caused 544 by a attack once the attack has been detected. Note that most of the 545 attacks described below do not require disclosure of a CA's private 546 key to an adversary. If the adversary can gain control of the 547 computer used to issue certificates, it can effect these attacks, 548 even though the private key for the CA remains "secure" (i.e., not 549 disclosed to unauthorized parties). However, if the CA is not the 550 adversary, and if the CA's private key is not compromised, then 551 recovery from these attacks is much easier. This motivates use of 552 hardware security modules to protect CA keys, at least for higher 553 tiers in the RPKI. 555 An attack by a CA can result in revocation or replacement of any of 556 the certificates that the CA issued. Revocation of a certificate 557 should cause RPs to delete the (formerly) valid certificate (and 558 associated signed object, in the case of a revoked EE certificate) 559 that they have cached. This would cause repository objects (e.g., CA 560 certificates and ROAs) that are verified under that certificate to be 561 considered invalid, transitively. As a result, RPs would not consider 562 as valid any ROAs or signed updates based on these certificates, 563 which would make routes dependent on them to be less preferred. 564 Because a CA that revokes a certificate is authorized to do so, this 565 sort of attack cannot be detected, intrinsically, by most RPs. 566 However, the entities affected by the revocation or replacement of CA 567 certificates can be expected to detect the attack and contact the CA 568 to effect remediation. If the CA was not the adversary, it should be 569 able to issue new certificates and restore the publication point. 571 An adversary that controls the CA for a publication point can publish 572 signed products that create more subtle types of DoS attacks against 573 RPs. For example, such an attacker could create subordinate CA 574 certificates with Subject Information Access (SIA) pointers that lead 575 RPs on a "wild goose chase" looking for additional publication points 576 and signed products. An attacker could publish certificates with very 577 brief validity intervals, or CRLs and manifests that become "stale" 578 very quickly. This sort of attack would cause RPs to have to access 579 repositories more frequently, and that might interfere with 580 legitimate accesses by other RPs. 582 An attacker with this capability could create very large numbers of 583 ROAs to be processed (with prefixes that are consistent with the 584 allocation for the CA), and correspondingly large manifests. An 585 attacker could create very deep subtrees with many ROAs per 586 publication point, etc. All of these types of DoS attacks against RPs 587 are feasible within the syntactic and semantic constraints 588 established for RPKI certificates, CRLs, and signed objects. 590 An attack that results in revocation and replacement (e.g., key 591 rollover or certificate renewal) of a CA certificate would cause RPs 592 to replace the old, valid certificate with the new one. This new 593 certificate might contain a public key that does not correspond to 594 the private key held by the certificate subject. That would cause 595 objects signed by that subject to be rejected as invalid, and prevent 596 the affected subject from being able to sign new objects. As above, 597 RPs would not consider as valid any ROAs issued under the affected CA 598 certificate, and updates based on router certificates issued by the 599 affected CA would be rejected. This would make routes dependent on 600 these signed products to be less preferred. However, the constraints 601 imposed by the use of RFC 3779 [RFC3779] extensions do prevent a 602 compromised CA from issuing (valid) certificates with INRs outside 603 the scope of the CA, thus limiting the impact of the attack. 605 An adversary that controls a CA could issue CA certificates with 606 overlapping INRs to different entities, when no transfer of INRs is 607 intended. This could cause confusion for RPs as conflicting ROAs 608 could be issued by the distinct CAs. 610 An adversary could replace a CA certificate, use the corresponding 611 private key to issue new signed products, and then publish them at a 612 publication point controlled by the attacker. This would effectively 613 transfer the affected INRs to the adversary, or to a third party of 614 his choosing. The result would be to cause RPs to view the entity 615 that controls the private key in question as the legitimate INR 616 holder. Again the constraints imposed by the use of RFC 3779 617 extensions do prevent a compromised CA from issuing (valid) 618 certificates with INRs outside the scope of the CA, thus limiting the 619 impact of the attack. 621 Finally, an entity that manages a repository publication point can 622 inadvertently act as an attacker (as first noted by Pogo). For 623 example, a CA might fail to replace its own certificate in a timely 624 fashion (well before it expires). If might fail to issue its CRL and 625 manifest prior to expiration, creating stale instances of these 626 products that cause concern for RPs. A CA with many subordinate CAs 627 (e.g., an RIR or NIR) might fail to distribute the expiration times 628 for the CA certificates that it issues. An ISP with many ROAs might 629 do the same for the EE certificates associated with the ROAs it 630 generates. A CA could rollover its key, but fail to reissue 631 subordinate CA certificates under its new key. Poor planning with 632 regard to rekey intervals for managed CAs could impose undue burdens 633 for RPs, despite a lack of malicious intent. All of these example of 634 mismanagement could adversely affect RPs, despite the absence of 635 malicious intent. 637 5. Residual Vulnerabilities 639 The RPKI, upon which BGPSEC relies, has several residual 640 vulnerabilities that were been discussed in the preceding text 641 (Sections 4.4 and 4.5). These vulnerabilities are of two principle 642 forms: 644 - the RPKI repository system may be attacked in ways that make 645 its contents unavailable, or not current. It is anticipated that 646 RPs will cope with this vulnerability through local caching of 647 repository data, and through local settings that tolerate 648 expired or stale repository data. 650 - any CA in the RPKI may misbehave within the bounds of the 651 resources allocated to it, e.g., it may issue certificates with 652 duplicate resource allocations or revoke certificates 653 inappropriately. This vulnerability is intrinsic in any PKI. It 654 is anticipated that RPs will deal with this through 656 BGPSEC has a separate set of residual vulnerabilities: 658 - BGPSEC is not able to prevent what is usually referred to as 659 route leaks, because BGP itself does not distinguish between 660 transit and non-transit ASes- BGPSEC signatures do not protect 661 all attributes associated with an AS_path. Some of these 662 attributes are employed as inputs to routing decisions. Thus 663 attacks that modify (or strip) these other attributes are not 664 detected by BGPSEC. 666 6. Security Considerations 668 A threat model is, by definition, a security-centric document. Unlike 669 a protocol description, a threat model does not create security 670 problems nor purport to address security problems. This model 671 postulates a set of threats (i.e., motivated, capable adversaries) 672 and examines classes of attacks that these threats are capable of 673 effecting, based on the motivations ascribed to the threats. It 674 describes the impact of these types of attacks on BGPSEC, including 675 on the RPKI on which BGPSEC relies. 677 7. IANA Considerations 679 [Note to IANA, to be removed prior to publication: there are no IANA 680 considerations stated in this version of the document.] 682 8. Acknowledgements 684 The author wishes to thank . . . 686 9. References 688 9.1. Normative References 690 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 691 Requirement Levels", BCP 14, RFC 2119, March 1997. 693 9.2. Informative References 695 [RFC4272] 696 Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, 697 June 2006 699 [RFC4301] 700 Kent, S. and Seo, K., "Security Architecture for the Internet 701 Protocol", RFC 4301, December, 2005. 703 [RFC3779] 704 Lynn, C., Kent, S., Seo, K., X.509 Extensions for IP Addresses 705 and AS Identifiers, RFC 3779, June 2004. 707 [Kent2000] 708 Kent, S., Lynn, C., and Seo, K., "Design and Analysis of the 709 Secure Border Gateway Protocol (S-BGP)", IEEE DISCEX Conference, 710 June, 2000. 712 [RFC5925] 713 Touch, J., et al., "The TCP Authentication Option", 714 RFC 5925, June 2010. 716 [I-D.ietf-sidr-arch] 717 Lepinski, M. and S. Kent, "An Infrastructure to Support 718 Secure Internet Routing", draft-ietf-sidr-arch-11.txt 719 (work in progress), September 2010. 721 [I-D.sidr.signed-object] 722 Lepinski, M, Chi, A., and Kent, S., "Signed Object Template for 723 the Resource Public Key Infrastructure", draft-ietf-sidr-signed- 724 object-01.txt, (work in progress), December 2010. 726 [I-D.sidr-res-certs] 727 Huston, G., Michaelson, G., and Loomans, R. "A Profile for X.509 728 PKIX Resource Certificates", draft-ietf-sidr-res-certs-21.txt 729 (work in progress), December 2010. 731 [I-D.roa-format] 732 Lepinski, M., Kent, S., and Kong, D., "A Profile for Route Origin 733 Authorizations (ROAs)", draft-ietf-sidr-roa-format-09.txt, 734 (work in progress), November 2010. 736 Author's Address 738 Stephen Kent BBN Technologies 10 Moulton St. Cambridge, MA 02138 USA 740 Email: kent@bbn.com