idnits 2.17.1 draft-ietf-sidr-bgpsec-threats-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 22, 2012) is 4447 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) -- Obsolete informational reference (is this intentional?): RFC 6486 (Obsoleted by RFC 9286) -- Obsolete informational reference (is this intentional?): RFC 2385 (ref. 'TCPMD5') (Obsoleted by RFC 5925) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Secure Inter-Domain Routing S. Kent 3 Internet-Draft A. Chi 4 Intended status: Standards Track BBN 5 Expires: August 25, 2012 February 22, 2012 7 Threat Model for BGP Path Security 8 draft-ietf-sidr-bgpsec-threats-02 10 Abstract 12 This document describes a threat model for BGP path security 13 (BGPSEC). It assumes the context established by the SIDR WG charter, 14 as of April 19, 2011. The charter established two goals for the SIDR 15 work: 17 o Enabling an AS to verify the authorization of an origin AS to 18 originate a specified set of prefixes 20 o Enabling an AS to verify that the AS-PATH represented in a route 21 matches the path travelled by the NLRI for the route 23 The charter further mandates that SIDR build upon the Resource Public 24 Key Infrastructure (RPKI), the first product of the WG. Consistent 25 with the charter, this threat model includes an analysis of the RPKI, 26 and focuses on the ability of an AS to verify the authenticity of the 27 AS path info received in a BGP update. 29 The model assumes that BGP path security is achieved through the 30 application of digital signatures to AS_Path Info. The document 31 characterizes classes of potential adversaries that are considered to 32 be threats, and examines classes of attacks that might be launched 33 against BGPSEC. It concludes with brief discussion of residual 34 vulnerabilities. 36 Status of this Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on August 25, 2012. 53 Copyright Notice 55 Copyright (c) 2012 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 3. Threat Characterization . . . . . . . . . . . . . . . . . . . 9 73 4. Attack Characterization . . . . . . . . . . . . . . . . . . . 11 74 4.1. Active wiretapping of links between routers . . . . . . . 11 75 4.2. Attacks on a BGP router . . . . . . . . . . . . . . . . . 11 76 4.3. Attacks on network operator management computers 77 (non-CA computers) . . . . . . . . . . . . . . . . . . . . 13 78 4.4. Attacks on a repository publication point . . . . . . . . 14 79 4.5. Attacks on an RPKI CA . . . . . . . . . . . . . . . . . . 16 80 5. Residual Vulnerabilities . . . . . . . . . . . . . . . . . . . 19 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 83 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 85 9.1. Normative References . . . . . . . . . . . . . . . . . . . 24 86 9.2. Informative References . . . . . . . . . . . . . . . . . . 24 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 89 1. Introduction 91 This document describes the security context in which BGPSEC is 92 intended to operate. It discusses classes of potential adversaries 93 that are considered to be threats, and classes of attacks that might 94 be launched against BGPSEC. Because BGPSEC depends on the Resource 95 Public Key Infrastructure (RPKI) [RFC6480], threats and attacks 96 against the RPKI are included. This model also takes into 97 consideration classes of attacks that are enabled by the use of 98 BGPSEC (based on the current BGPSEC design.) 100 The motivation for developing BGPSEC, i.e., residual security 101 concerns for BGP, is well described in several documents, including 102 "BGP Security Vulnerabilities Analysis" [RFC4272] and "Design and 103 Analysis of the Secure Border Gateway Protocol (S-BGP)" [Kent2000]. 104 All of these papers note that BGP does not include mechanisms that 105 allow an Autonomous System (AS) to verify the legitimacy and 106 authenticity of BGP route advertisements. (BGP now mandates support 107 for mechanisms to secure peer-peer communication, i.e., for the links 108 that connect BGP routers. There are several secure protocol options 109 to addresses this security concern, e.g., IPsec [RFC4301] and TCP-AO 110 [RFC5925]. This document briefly notes the need to address this 111 aspect of BGP security, but focuses on application layer BGP security 112 issues that are addressed by BGPSEC.) 114 RFC 4272 [RFC4272] succinctly notes: 116 BGP speakers themselves can inject bogus routing information, 117 either by masquerading as any other legitimate BGP speaker, or by 118 distributing unauthorized routing information as themselves. 119 Historically, misconfigured and faulty routers have been 120 responsible for widespread disruptions in the Internet. The 121 legitimate BGP peers have the context and information to produce 122 believable, yet bogus, routing information, and therefore have the 123 opportunity to cause great damage. The cryptographic protections 124 of [TCPMD5] and operational protections cannot exclude the bogus 125 information arising from a legitimate peer. The risk of 126 disruptions caused by legitimate BGP speakers is real and cannot 127 be ignored. 129 BGPSEC is intended to address the concerns cited above, to provide 130 significantly improved path security, building upon the secure route 131 origination foundation offered by use of the RPKI. Specifically, the 132 RPKI enables relying parties (RPs) to determine if the origin AS for 133 a path was authorized to advertise the prefix contained in a BGP 134 update message. This security feature is enabled by the use of two 135 types of digitally signed data: a PKI [RFC6487] that associates one 136 or more prefixes with the public key(s) of an address space holder, 137 and Route Origination Authorizations (ROAs) [RFC6482] that allows a 138 prefix holder to specify the AS(es) that are authorized to originate 139 routes for a prefix. 141 The security model adopted for BGPSEC does not assume an "oracle" 142 that can see all of the BGP inputs and outputs associated with every 143 AS or every BGP router. Instead, the model is based on a local 144 notion of what constitutes legitimate, authorized behavior by the BGP 145 routers associated with an AS. This is an AS-centric model of secure 146 operation, consistent with the AS-centric model that BGP employs for 147 routing. This model forms the basis for the discussion that follows. 149 This document begins with a brief set of definitions relevant to the 150 subsequent sections. It then discusses classes of adversaries that 151 are perceived as viable threats against routing in the public 152 Internet. It continues to explore a range of attacks that might be 153 effected by these adversaries, against both path security and the 154 infrastructure upon which BGPSEC relies. It concludes with a brief 155 review of residual vulnerabilities. 157 2. Terminology 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in [RFC2119]. 163 The following security and routing terminology definitions are 164 employed in this document. 166 Adversary - An adversary is an entity (e.g., a person or an 167 organization) perceived as malicious, relative to the security policy 168 of a system. The decision to characterize an entity as an adversary 169 is made by those responsible for the security of a system. Often one 170 describes classes of adversaries with similar capabilities or 171 motivations, rather than specific individuals or organizations. 173 Attack - An attack is an action that attempts to violate the security 174 policy of a system, e.g., by exploiting a vulnerability. There is 175 often a many to one mapping of attacks to vulnerabilities, because 176 many different attacks may be used to exploit a vulnerability. 178 Autonomous System (AS) - An AS is a set of one or more IP networks 179 operated by a single administrative entity. 181 AS Number (ASN) - An ASN is a 2 or 4 byte number issued by a registry 182 to identify an AS in BGP. 184 Certification Authority (CA) - An entity that issues digital 185 certificates (e.g., X.509 certificates) and vouches for the binding 186 between the data items in a certificate. 188 Countermeasure - A countermeasure is a procedure or technique that 189 thwarts an attack, preventing it from being successful. Often 190 countermeasures are specific to attacks or classes of attacks. 192 Border Gateway Protocol (BGP) - A path vector protocol used to convey 193 "reachability" information among autonomous systems, in support of 194 inter-domain routing. 196 False (Route) Origination - If a network operator originates a route 197 for a prefix that the network operator does not hold (and that it has 198 not been authorized to originate by the prefix holder, this is termed 199 false route origination. 201 Internet Service Provider (ISP) - An organization managing (and, 202 typically, selling,) Internet services to other organizations or 203 individuals. 205 Internet Number Resources (INRs) - IPv4 or IPv6 address space and 206 ASNs 208 Internet Registry - An organization that manages the allocation or 209 distribution of INRs. This encompasses the Internet Assigned Number 210 Authority (IANA), Regional Internet Registries (RIRs), National 211 Internet Registries (NIRs), and Local Internet Registries (LIRs, 212 network operators). 214 Man in the Middle (MITM) - A MITM is an entity that is able to 215 examine and modify traffic between two (or more) parties on a 216 communication path. 218 NOC (Network Operations Center) - A network operator employs a set 219 equipment and a staff to manage a network, typically on a 24/7 basis. 220 The equipment and staff are often referred to as the NOC for the 221 network. 223 Prefix - A prefix is an IP address and a mask used to specify a set 224 of addresses that are grouped together for purposes of routing. 226 Public Key Infrastructure (PKI) - A PKI is a collection of hardware, 227 software, people, policies, and procedures used to create, manage, 228 distribute, store, and revoke digital certificates. 230 Relying Parties (RPs) - An RP is an entity that makes use of signed 231 products from a PKI, i.e., relies on signed data that is verified 232 using certificates, and CRLs from a PKI. 234 RPKI Repository System - The RPKI repository system consists of a 235 distributed set of loosely synchronized databases. 237 Resource PKI (RPKI) - A PKI operated by the entities that manage 238 INRs, and that issues X509 certificates (and CRLs) that attest to the 239 holdings of INRs. 241 RPKI Signed Object - An RPKI signed object is a Cryptographic Message 242 Syntax (CMS)-encapsulated data object complying with the format and 243 semantics defined in [RFC6488]. 245 Route - In the Internet, a route is a prefix and an associated 246 sequence of ASNs that indicates a path via which traffic destined for 247 the prefix can be directed. (The route includes the origin AS.) 249 Route leak - A route leak is said to occur when AS-A advertises 250 routes that it has received from an AS-B to AS-A's neighbors, but 251 AS-A is not viewed as a transit provider for the prefixes in the 252 route. 254 Threat - A threat is a motivated, capable adversary. An adversary 255 that is not motivated to launch an attack is not a threat. An 256 adversary that is motivated but not capable of launching an attack 257 also is not a threat. 259 Vulnerability - A vulnerability is a flaw or weakness in a system's 260 design, implementation, or operation and management that could be 261 exploited to violate the security policy of a system. 263 3. Threat Characterization 265 The following classes of threats are addressed in this document. 267 Network Operators - A network operator may be a threat. A network 268 operator may be motivated to cause BGP routers it controls to emit 269 update messages with inaccurate routing info, e.g. to cause traffic 270 to flow via paths that are economically advantageous for the 271 operator. Such updates might cause traffic to flow via paths that 272 would otherwise be rejected as less advantageous by other network 273 operators. Because a network operator controls the BGP routers in 274 its network, it is in a position to modify their operation in 275 arbitrary ways. Routers managed by a network operator are vehicles 276 for mounting MITM attacks on both control and data plane traffic. If 277 a network operator participates in the RPKI, it will have at least CA 278 resource certificate and may be able to generate an arbitrary number 279 of subordinate CA certificates and ROAs. It will be authorized to 280 populate (and may even host) its own repository publication point. 281 If it implements BGPSEC, it will have the ability to issue 282 certificates for its routers, and to sign updates in a fashion that 283 will be recognized by BGPSEC-enabled neighbors. 285 Hackers - Hackers are considered a threat. A hacker might assume 286 control of network management computers and routers controlled by 287 network operators, including network operators that implement BGPSEC. 288 In such cases, hackers would be able to act as a rogue network 289 operators (see above). It is assumed that hackers generally do not 290 have the capability to effect MITM attacks on most links between 291 networks (links used to transmit BGP and subscriber traffic). A 292 hacker might be recruited, without his/her knowledge, by criminals or 293 by nations, to act on their behalf. Hackers may be motivated by a 294 desire for "bragging rights" or for profit. 296 Criminals - Criminals may be a threat. Criminals might persuade (via 297 threats or extortion) a network operator to act as a rogue network 298 operator (see above), and thus be able to effect a wide range of 299 attacks. Criminals might persuade the staff of a telecommunications 300 provider to enable MITM attacks on links between routers. 301 Motivations for criminals may include the ability to extort money 302 from network operators or network operator clients, e.g., by 303 adversely affecting routing for these network operators or their 304 clients. Criminals also may wish to manipulate routing to conceal 305 the sources of spam, DoS attacks, or other criminal activities. 307 Registries - Any registry in the RPKI could be a threat. Staff at 308 the registry are capable of manipulating repository content or 309 mismanaging the RPKI certificates that they issue. These actions 310 could adversely affect a network operator or a client of a network 311 operator. The staff could be motivated to do this based on political 312 pressure from the nation in which the registry operates (see below) 313 or due to criminal influence (see above). 315 Nations - A nation may be a threat. A nation may control one or more 316 network operators that operate in the nation, and thus can cause them 317 to act as rogue network operators. A nation may have a technical 318 active wiretapping capability (e.g., within its territory) that 319 enables it to effect MITM attacks on inter-network traffic. (This 320 capability may be facilitated by control or influence over a 321 telecommunications provider operating within the nation.) It may 322 have an ability to attack and take control of routers or management 323 network computers of network operators in other countries. A nation 324 may control a registry (e.g., an RIR) that operates within its 325 territory, and might force that registry to act in a rogue capacity. 326 National threat motivations include the desire to control the flow of 327 traffic to/from the nation or to divert traffic destined for other 328 nations (for passive or active wiretapping, including DoS). 330 4. Attack Characterization 332 This section describes classes of attacks that may be effected 333 against Internet routing (relative to the context described in 334 Section 1). Attacks are classified based on the target of the 335 attack, as an element of the routing system, or the routing security 336 infrastructure on which BGPSEC relies. In general, attacks of 337 interest are ones that attempt to violate the integrity or 338 authenticity of BGP traffic, or which violate the authorizations 339 associated with entities participating in the RPKI. Attacks that 340 violate the implied confidentiality of routing traffic are not 341 considered significant (see Section 4.1 below). 343 4.1. Active wiretapping of links between routers 345 An adversary may attack the links that connect BGP routers. Passive 346 attacks are not considered, because it is assumed that most of the 347 info carried by BGP will otherwise be accessible to adversaries. 348 Several classes of adversaries are assumed to be capable of MITM 349 effecting attacks against the control plane traffic. MITM attacks 350 may be directed against BGP, BGPSEC, or against TCP or IP. Such 351 attacks include replay of selected BGP messages, selective 352 modification of BGP messages, and DoS attacks against BGP routers. 354 4.2. Attacks on a BGP router 356 An adversary may attack a BGP router, whether it implements BGPSEC or 357 not. Any adversary that controls routers legitimately, or that can 358 assume control of a router, is assumed to be able to effect the types 359 of attacks described below. Note that any router behavior that can 360 be ascribed to a local routing policy decision is not considered to 361 be an attack. This is because such behavior could be explained as a 362 result of local policy settings, and thus is beyond the scope of what 363 BGPSEC can detect as unauthorized behavior. Thus, for example, a 364 router may fail to propagate some or all route withdrawals or effect 365 "route leaks". (These behaviors are not precluded by the 366 specification for BGP, and might be the result of a local policy that 367 is not publicly disclosed. As a result, they are not considered 368 attacks. See Section 5 for additional discussion.) 370 Attacks on a router are active wiretapping attacks (in the most 371 general sense) that manipulate (forge, tamper with, or suppress) data 372 contained in BGP updates. The list below illustrates attacks of this 373 type. 375 AS Insertion: A router might insert one or more ASNs, other than 376 its own ASN, into an update message. This violates the BGP spec 377 and thus is considered an attack. 379 False (Route) Origination: A router might originate a route for a 380 prefix, when the AS that the router represents is not authorized 381 to originate routes for that prefix. This is an attack. 383 Secure Path Downgrade: A router might remove signatures from a 384 BGPSEC update that it receives, when forwarding this update to a 385 BGPSEC-enabled neighbor. This behavior violates the BGPSEC spec 386 and thus is considered an attack. 388 Invalid Signature Insertion: A router might emit a signed update 389 with a "bad" signature, i.e., a signature that cannot be validated 390 by other BGPSEC routers. This might be an intentional act, or it 391 might occur due to use of a revoked or expired certificate, a 392 computational error, or a syntactic error. Such behavior violates 393 the BGPSEC spec and thus is considered an attack. 395 Stale Path Announcement: An announcement may be propagated with an 396 origination signature segment that has expired. This behavior 397 violates the BGPSEC spec and is considered a possible replay 398 attack. 400 Premature Path Announcement Expiration: A router might emit a 401 signed update with an origin expiry time that is very short. 402 Unless the BGPSEC protocol specification mandates a minimum expiry 403 time, this is not an attack. However, if such a time is mandates, 404 this behavior becomes an attack. BGP speakers along a path 405 generally cannot determine if an expiry time is "suspiciously 406 short" since they cannot know how long a route may have been held 407 by an earlier AS, prior to being released. Thus only an immediate 408 neighbor of a route originator could be expected to detect this 409 type of attack. 411 MITM Attack: A cryptographic key used for point-to-point security 412 (e.g., TCP-AO, TLS, or IPsec) between two BGP routers might be 413 compromised (e.g., by extraction from a router). This would 414 enable an adversary to effect MITM attacks on the link(s) where 415 the key is used. Use of specific security mechanisms to protect 416 inter-router links between ASes is outside the scope of BGPSEC. 418 Compromised Router Private Key: The private key associated with an 419 RPKI EE certificate issued to a router might be compromised by an 420 attack against the router. An adversary with access to this key 421 would be able to generate updates that appear to have passed 422 through the AS that this router represents. Such updates might be 423 in injected on a link between the compromised router and its 424 neighbors, if that link is accessible to the adversary. If the 425 adversary controls another network, it could use this key to forge 426 signatures that appear to come from the AS or router(s) in 427 question, with some contraints. So, for example, an adversary 428 that controls another AS could use a compromised router key to 429 issue signed routes that include the targeted AS/router, with 430 limits. (Neighbors of the adversary's AS ought not accept a route 431 that purports to emanate directly from the targeted AS. So, an 432 adversary can take a legitimate route that passes through the 433 compromised AS, add itself as the next hop, and then forward the 434 resulting route to neighbors.) 436 Replay Attack: A BGPSEC-protected update may be signed and 437 announced, and later withdrawn. An adversary controlling 438 intermediate routers could fail to propagate the withdrawal, and 439 instead re-announce (i.e., replay) a previous announcement (that 440 has not yet expired). BGP is already vulnerable to behavior of 441 this sort; re-announcement cannot be characterized as an attack, 442 under the assumptions upon which this mode is based (i.e., no 443 oracle). 445 4.3. Attacks on network operator management computers (non-CA 446 computers) 448 An adversary may choose to attack computers used by a network 449 operator to manage its network, especially its routers. Such attacks 450 might be effected by an adversary that has compromised the security 451 of these computers. This might be effected via remote attacks, 452 extortion of selected network operations staff, etc. If an adversary 453 compromises NOC computers, it can execute any management function 454 that authorized network operations staff would have performed. Thus 455 the adversary could modify local routing policy to change 456 preferences, to black-hole certain routes, etc. This type of 457 behavior cannot be externally detected as an attack. Externally, 458 this appears as a form of rogue network operator behavior. 460 If a network operator participates in the RPKI, an adversary could 461 manipulate the RP tools that extract data from the RPKI, causing the 462 output of these tools to be corrupted in various ways. For example, 463 an attack of this sort could cause the network operator to view valid 464 routes as not validated, which could alter its routing behavior. 466 If an adversary invoked the tool used to manage the repository 467 publication point for this network operator, it could delete any 468 objects stored there (certificates, CRLs, manifests, ROAs, or 469 subordinate CA certificates). This could affect the routing status 470 of entities that have allocations/assignments from this network 471 operator (e.g., by deleting their CA certificates). 473 An adversary could invoke the tool used to request certificate 474 revocation, causing router certificates, ROAs, or subordinate CA 475 certificates to be revoked. An attack of this sort could affect not 476 only this network operator, but also any network operators that 477 receive allocations/assignments from it, e.g., because their CA 478 certificates were revoked. 480 If a network operator is BGPSEC-enabled, an attack of this sort could 481 cause the affected network operator to be viewed as not BGPSEC- 482 enabled, possibly making routes it emits be less preferred by other 483 network operators. 485 If an adversary invoked a tool used to request ROAs, it could 486 effectively re-allocate some of the prefixes allocated/assigned to 487 the network operator (e.g., by modifying the origin AS in ROAs). 488 This might cause other BGPSEC-enabled networks to view the affected 489 network as no longer originating routes for these prefixes. Multi- 490 homed subscribers of this network operator who received an allocation 491 from the network operator might find their traffic was now routed via 492 other connections. 494 If the network operator is BGPSEC-enabled, and the adversary invoked 495 a tool used to request certificates, it could replace valid 496 certificates for routers with ones that might be rejected by BGPSEC- 497 enabled neighbors. 499 4.4. Attacks on a repository publication point 501 A critical element of the RPKI is the repository system. An 502 adversary might attack a repository, or a publication point within a 503 repository, to adversely affect routing. 505 This section considers only those attacks that can be launched by any 506 adversary who controls a computer hosting one or more repository 507 publication points, without access to the cryptographic keys needed 508 to generate valid RPKI signed products. Such attacks might be 509 effected by an inside or an external threat. Because all repository 510 objects are digitally signed, attacks of this sort translate into DoS 511 attacks against the RPKI RPs. There are a few distinct forms of such 512 attacks, as described below. 514 Note first that the RPKI calls for RPs to cache the data they acquire 515 and verify from the repository system. Attacks that delete signed 516 products, that insert products with "bad" signatures, that tamper 517 with object signatures, or that replace newer objects with older 518 (valid) ones, can be detected by RPs (with a few exceptions). RPs 519 are expected to make use of local caches. If repository publication 520 points are unavailable or the retrieved data is corrupted, an RP can 521 revert to using the cached data. This behavior helps insulate RPs 522 from the immediate effects of DoS attacks on publication points. 524 Each RPKI data object has an associated date at which it expires, or 525 is considered stale. (Certificates expire, CRLs become stale.) When 526 an RP uses cached data it is a local decision how to deal with stale 527 or expired data. It is common in PKIs to make use of stale 528 certificate revocation status data, when fresher data is not 529 available. Use of expired certificates is less common, although not 530 unknown. Each RP will decide, locally, whether to continue to make 531 use of or ignore cached RPKI objects that are stale or expired. 533 If an adversary inserts an object into a publication point, and the 534 object has a "bad" signature, the object will not be accepted and 535 used by RPs. 537 If an adversary modifies any signed product at a publication point, 538 the signature on the product will fail, causing RPs to not accept it. 539 This is equivalent to deleting the object, in many respects. 541 If an adversary deletes one or more CA certificates, ROAs or the CRL 542 for a publication point, the manifest for that publication point will 543 allow an RP to detect this attack. (The RP would be very unhappy if 544 there is no CRL for the CA instance anyway.) An RP can continue to 545 use the last valid instance of the deleted object as a local policy 546 option), thus minimizing the impact of such an attack. 548 If an adversary deletes a manifest (and does not replace it with an 549 older instance), that is detectable by RPs. Such behavior should 550 result in the CA (or publication point maintainer) being notified of 551 the problem. An RP can continue to use the last valid instance of 552 the deleted manifest (a local policy option), thus minimizing the 553 impact of such an attack. 555 If an adversary deletes newly added CA certificates or ROAs, and 556 replaces the current manifest with the previous manifest, the 557 manifest (and the CRL that it matches) will be "stale" (see 558 [RFC6486]). This alerts an RP that there may be a problem, and, 559 hopefully, the entity responsible for the publication point will be 560 asked to remedy the problem (e.g., republish the missing CA 561 certificates and/or ROAs). An RP cannot know the content of the new 562 certificates or ROAs that are not present, but it can continue to use 563 what it has cached. An attack of this sort will, at least 564 temporarily, cause RPs to be un aware of the newly published objects. 565 INRs associated with these objects will be treated as 566 unauthenticated. 568 If a CA revokes a CA certificate or a ROA (via deleting the 569 corresponding EE certificate), and the adversary tries to reinstate 570 that CA certificate or ROA, the adversary would have to rollback the 571 CRL and the manifest to undo this action by the CA. As above, this 572 would make the CRL and manifest stale, and this is detectable by RPs. 573 An RP cannot know which CA certificates or ROAs were deleted. 574 Depending on local policy, the RP might use the cached instances of 575 the affected objects, and thus be tricked into making decisions based 576 on these revoked objects. Here too the hope is that the CA will be 577 notified of the problem (by RPs) and will remedy the error. 579 In the attack scenarios above, when a CRL or manifest is described as 580 stale, this means that the next issue date for the CRL or manifest 581 has passed. Until the next issue date, an RP will not be detect the 582 attack. Thus it behooves CAs to select CRL/manifest lifetimes (the 583 two are linked) that represent an acceptable tradeoff between risk 584 and operational burdens. 586 Attacks effected by adversaries that are legitimate managers of 587 publication points can have much greater effects, and are discussed 588 below under attacks on or by CAs. 590 4.5. Attacks on an RPKI CA 592 Every entity to which INRs have been allocated/assigned is a CA in 593 the RPKI. Each CA is nominally responsible for managing the 594 repository publication point for the set of signed products that it 595 generates. (An INR holder may choose to outsource the operation of 596 the RPKI CA function, and the associated publication point. In such 597 cases, the organization operating on behalf of the INR holder becomes 598 the CA, from an operational and security perspective. The following 599 discussion does not distinguish such outsourced CA operations.) 601 Note that attacks attributable to a CA may be the result of malice by 602 the CA (i.e., the CA is the adversary) or they may result from a 603 compromise of the CA. 605 All of adversaries listed in Section 2 are presumed to be capable of 606 launching attacks against the computers used to perform CA functions. 607 Some adversaries might effect an attack on a CA by violating 608 personnel or physical security controls as well. The distinction 609 between CA as adversary vs. CA as an attack victim is important. 610 Only in the latter case should one expect the CA to remedy problems 611 caused by a attack once the attack has been detected. (If a CA does 612 not take such action, the effects are the same as if the CA is an 613 adversary.) 615 Note that most of the attacks described below do not require 616 disclosure of a CA's private key to an adversary. If the adversary 617 can gain control of the computer used to issue certificates, it can 618 effect these attacks, even though the private key for the CA remains 619 "secure" (i.e., not disclosed to unauthorized parties). However, if 620 the CA is not the adversary, and if the CA's private key is not 621 compromised, then recovery from these attacks is much easier. This 622 motivates use of hardware security modules to protect CA keys, at 623 least for higher tiers in the RPKI. 625 An attack by a CA can result in revocation or replacement of any of 626 the certificates that the CA has issued. Revocation of a certificate 627 should cause RPs to delete the (formerly) valid certificate (and 628 associated signed object, in the case of a revoked EE certificate) 629 that they have cached. This would cause repository objects (e.g., CA 630 certificates and ROAs) that are verified under that certificate to be 631 considered invalid, transitively. As a result, RPs would not 632 consider as valid any ROAs or BGPSEC-signed updates based on these 633 certificates, which would make routes dependent on them to be less 634 preferred. Because a CA that revokes a certificate is authorized to 635 do so, this sort of attack cannot be detected, intrinsically, by most 636 RPs. However, the entities affected by the revocation or replacement 637 of CA certificates can be expected to detect the attack and contact 638 the CA to effect remediation. If the CA was not the adversary, it 639 should be able to issue new certificates and restore the publication 640 point. 642 An adversary that controls the CA for a publication point can publish 643 signed products that create more subtle types of DoS attacks against 644 RPs. For example, such an attacker could create subordinate CA 645 certificates with Subject Information Access (SIA) pointers that lead 646 RPs on a "wild goose chase" looking for additional publication points 647 and signed products. An attacker could publish certificates with 648 very brief validity intervals, or CRLs and manifests that become 649 "stale" very quickly. This sort of attack would cause RPs to access 650 repositories more frequently, and that might interfere with 651 legitimate accesses by other RPs. 653 An attacker with this capability could create very large numbers of 654 ROAs to be processed (with prefixes that are consistent with the 655 allocation for the CA), and correspondingly large manifests. An 656 attacker could create very deep subtrees with many ROAs per 657 publication point, etc. All of these types of DoS attacks against 658 RPs are feasible within the syntactic and semantic constraints 659 established for RPKI certificates, CRLs, and signed objects. 661 An attack that results in revocation and replacement (e.g., key 662 rollover or certificate renewal) of a CA certificate would cause RPs 663 to replace the old, valid certificate with the new one. This new 664 certificate might contain a public key that does not correspond to 665 the private key held by the certificate subject. That would cause 666 objects signed by that subject to be rejected as invalid, and prevent 667 the affected subject from being able to sign new objects. As above, 668 RPs would not consider as valid any ROAs issued under the affected CA 669 certificate, and updates based on router certificates issued by the 670 affected CA would be rejected. This would make routes dependent on 671 these signed products to be less preferred. However, the constraints 672 imposed by the use of RFC 3779 [RFC3779] extensions do prevent a 673 compromised CA from issuing (valid) certificates with INRs outside 674 the scope of the CA, thus limiting the impact of the attack. 676 An adversary that controls a CA could issue CA certificates with 677 overlapping INRs to different entities, when no transfer of INRs is 678 intended. This could cause confusion for RPs as conflicting ROAs 679 could be issued by the distinct (subordinate) CAs. 681 An adversary could replace a CA certificate, use the corresponding 682 private key to issue new signed products, and then publish them at a 683 publication point controlled by the attacker. This would effectively 684 transfer the affected INRs to the adversary, or to a third party of 685 his choosing. The result would be to cause RPs to view the entity 686 that controls the private key in question as the legitimate INR 687 holder. Again the constraints imposed by the use of RFC 3779 688 extensions prevent a compromised CA from issuing (valid) certificates 689 with INRs outside the scope of the CA, thus limiting the impact of 690 the attack. 692 Finally, an entity that manages a repository publication point can 693 inadvertently act as an attacker (as first noted by Pogo). For 694 example, a CA might fail to replace its own certificate in a timely 695 fashion (well before it expires). If might fail to issue its CRL and 696 manifest prior to expiration, creating stale instances of these 697 products that cause concern for RPs. A CA with many subordinate CAs 698 (e.g., an RIR or NIR) might fail to distribute the expiration times 699 for the CA certificates that it issues. A network with many ROAs 700 might do the same for the EE certificates associated with the ROAs it 701 generates. A CA could rollover its key, but fail to reissue 702 subordinate CA certificates under its new key. Poor planning with 703 regard to rekey intervals for managed CAs could impose undue burdens 704 for RPs, despite a lack of malicious intent. All of these example of 705 mismanagement could adversely affect RPs, despite the absence of 706 malicious intent. 708 5. Residual Vulnerabilities 710 The RPKI, upon which BGPSEC relies, has several residual 711 vulnerabilities that were discussed in the preceding text 712 (Section 4.4 and Section 4.5). These vulnerabilities are of two 713 principle forms: 715 o the RPKI repository system may be attacked in ways that make its 716 contents unavailable, not current, or inconsistent. The principle 717 defense against most forms of DoS attacks is the use of a local 718 cache by each RP. The local cache ensures availability of 719 previously-acquired RPKI data, in the event that a repository is 720 inaccessible or if repository contents are deleted (maliciously). 721 Nonetheless, the system cannot ensure that every RP will always 722 have access to up-to-date RPKI data. An RP, when it detects a 723 problem with acquired repository data has two options: 725 1. The RP may choose to make use of its local cache, employing 726 local configuration settings that tolerate expired or stale 727 objects. (Such behavior is, nominally, always within the 728 purview of an RP in PKI.) Using cached, expired or stale data 729 subjects the RP to attacks that take advantage of the RP's 730 ignorance of changes to this data. 732 2. The RP may chose to purge expired objects. Purging expired 733 objects removes the security info associated with the real 734 world INRs to which the objects refer. This is equivalent to 735 the affected INRs not having been afforded protection via the 736 RPKI. Since use of the RPKI (and BGPSEC) is voluntary, there 737 may always be set of INRs that are not protected by these 738 mechanisms. Thus purging moves the affected INRs to the set 739 of non-participating INR holders. This more conservative 740 response enables an attacker to move INRs from the protected 741 to the unprotected set. 743 o any CA in the RPKI may misbehave within the bounds of the INRs 744 allocated to it, e.g., it may issue certificates with duplicate 745 resource allocations or revoke certificates inappropriately. This 746 vulnerability is intrinsic in any PKI, but its impact is limited 747 in the RPKI because of the use or RFC 3779 extensions. It is 748 anticipated that RPs will deal with such misbehavior through 749 administrative means, once it is detected. 751 BGPSEC has a separate set of residual vulnerabilities: 753 o "Route leaks" are viewed as a routing security problem by many 754 network operators, even though there is no IETF-codified 755 definition of a route leak. BGP itself does not include semantics 756 that preclude what many perceive as route leaks. Moreover, route 757 leaks are outside the scope of BGPSEC, at this time, based on the 758 SIDR charter. Thus route leaks are not addressed in this threat 759 model. 761 o BGPSEC signatures do not protect all attributes associated with an 762 AS_path. Some of these attributes are employed as inputs to 763 routing decisions. Thus attacks that modify (or strip) these 764 other attributes are not detected by BGPSEC. The SIDR charter 765 calls for protecting only the info needed to verify that a 766 received route traversed the ASes on question, and that the NLRI 767 in the route is what was advertised. Thus, protection of other 768 attributes is outside the scope of the charter, at the time this 769 document was prepared. 771 o BGPSEC cannot ensure that an AS will withdraw a route when the AS 772 no longer has a route for a prefix, as noted in Section 4.2. 773 BGPSEC may incorporate features to limit the lifetime of an 774 advertisement. Such lifetime limits provide an upper bound on the 775 time that the failure to withdraw a route will remain effective. 777 6. Security Considerations 779 A threat model is, by definition, a security-centric document. 780 Unlike a protocol description, a threat model does not create 781 security problems nor purport to address security problems. This 782 model postulates a set of threats (i.e., motivated, capable 783 adversaries) and examines classes of attacks that these threats are 784 capable of effecting, based on the motivations ascribed to the 785 threats. It describes the impact of these types of attacks on 786 BGPSEC, including on the RPKI on which BGPSEC relies. It describes 787 how the design of the RPKI (and the current BGPSEC design) address 788 classes of attacks, where applicable. It also notes residual 789 vulnerabilities. 791 7. IANA Considerations 793 [Note to IANA, to be removed prior to publication: there are no IANA 794 considerations stated in this version of the document.] 796 8. Acknowledgements 798 The author wishes to thank... 800 9. References 802 9.1. Normative References 804 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 805 Requirement Levels", BCP 14, RFC 2119, March 1997. 807 9.2. Informative References 809 [Kent2000] 810 Kent, S., Lynn, C., and K. Seo, "Design and Analysis of 811 the Secure Border Gateway Protocol (S-BGP)", IEEE DISCEX 812 Conference, June 2000. 814 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 815 Addresses and AS Identifiers", RFC 3779, June 2004. 817 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 818 RFC 4272, January 2006. 820 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 821 Internet Protocol", RFC 4301, December 2005. 823 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 824 Authentication Option", RFC 5925, June 2010. 826 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 827 Secure Internet Routing", RFC 6480, February 2012. 829 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 830 Origin Authorizations (ROAs)", RFC 6482, February 2012. 832 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 833 "Manifests for the Resource Public Key Infrastructure 834 (RPKI)", RFC 6486, February 2012. 836 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 837 X.509 PKIX Resource Certificates", RFC 6487, 838 February 2012. 840 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object 841 Template for the Resource Public Key Infrastructure 842 (RPKI)", RFC 6488, February 2012. 844 [TCPMD5] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 845 Signature Option", RFC 2385, August 1998. 847 Authors' Addresses 849 Stephen Kent 850 BBN Technologies 851 10 Moulton St. 852 Cambridge, MA 02138 853 US 855 Email: kent@bbn.com 857 Andrew Chi 858 BBN Technologies 859 10 Moulton St. 860 Cambridge, MA 02138 861 US 863 Email: achi@bbn.com