idnits 2.17.1 draft-ietf-sidr-bgpsec-threats-09.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 (December 11, 2013) is 3788 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TCPMD5' is mentioned on line 132, but not defined -- Obsolete informational reference (is this intentional?): RFC 6486 (Obsoleted by RFC 9286) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 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 BBN 4 Intended status: Informational A. Chi 5 Expires: June 14, 2014 UNC-CH 6 December 11, 2013 8 Threat Model for BGP Path Security 9 draft-ietf-sidr-bgpsec-threats-09 11 Abstract 13 This document describes a threat model for the context in which 14 Exterior Border Gateway Protocol (EBGP) path security mechanisms will 15 be developed. The threat model includes an analysis of the Resource 16 Public Key Infrastructure (RPKI), and focuses on the ability of an 17 autonomous system (AS) to verify the authenticity of the AS path info 18 received in a BGP update. We use the term PATHSEC to refer to any 19 BGP path security technology that makes use of the RPKI. PATHSEC 20 will secure BGP, consistent with the inter-AS security focus of the 21 RPKI. 23 The document characterizes classes of potential adversaries that are 24 considered to be threats, and examines classes of attacks that might 25 be launched against PATHSEC. It does not revisit attacks against 26 unprotected BGP, as that topic has already been addressed in the 27 BGP-4 standard. It concludes with brief discussion of residual 28 vulnerabilities. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on June 14, 2014. 47 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Threat Characterization . . . . . . . . . . . . . . . . . . . 6 66 4. Attack Characterization . . . . . . . . . . . . . . . . . . . 8 67 4.1. Active wiretapping of sessions between routers . . . . . 8 68 4.2. Attacks on a BGP router . . . . . . . . . . . . . . . . . 9 69 4.3. Attacks on network operator management computers (non-CA 70 computers) . . . . . . . . . . . . . . . . . . . . . . . 10 71 4.4. Attacks on a repository publication point . . . . . . . . 12 72 4.5. Attacks on an RPKI CA . . . . . . . . . . . . . . . . . . 14 73 5. Residual Vulnerabilities . . . . . . . . . . . . . . . . . . 16 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 76 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 77 9. Informative References . . . . . . . . . . . . . . . . . . . 18 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 80 1. Introduction 82 This document describes the security context in which PATHSEC is 83 intended to operate. The term "PATHSEC" (for path security) refers 84 to any design used to preserve the integrity and authenticity of the 85 AS_PATH attribute carried in a BGP update message [RFC4271]. The 86 security context used throughout this document is established by the 87 SIDR charter [SIDR-CH]. The charter requires that solutions that 88 afford PATHSEC make use of the Resource Public Key Infrastructure 89 (RPKI) [RFC6480]. It also calls for protecting only the information 90 required to verify that a received route traversed the Autonomous 91 Systems (ASes) in question, and that the Network Layer Reachability 92 Information (NLRI) in the route is what was advertised. 94 Thus the goal of PATHSEC is to enable a BGP speaker to verify that 95 the ASes enumerated in this path attribute represent the sequence of 96 ASes that the NLRI traversed. The term PATHSEC is thus consistent 97 with the goal described above. (Other SIDR documents use the term 98 "BGPSEC" to refer to a specific design, thus we avoid use of that 99 term here.) 101 This document discusses classes of potential adversaries that are 102 considered to be threats, and classes of attacks that might be 103 launched against PATHSEC. Because PATHSEC will rely on the RPKI, 104 threats and attacks against the RPKI are included. This model also 105 takes into consideration classes of attacks that are enabled by the 106 use of PATHSEC (e.g., based on use of the RPKI). 108 The motivation for developing PATHSEC, i.e., residual security 109 concerns for BGP, is well described in several documents, including 110 "BGP Security Vulnerabilities Analysis" [RFC4272] and "Design and 111 Analysis of the Secure Border Gateway Protocol (S-BGP)" [Kent2000]. 112 All of these documents note that BGP does not include mechanisms that 113 allow an Autonomous System (AS) to verify the legitimacy and 114 authenticity of BGP route advertisements. (BGP now mandates support 115 for mechanisms to secure peer-peer communication, i.e., for the links 116 that connect BGP routers. There are several secure protocol options 117 to addresses this security concern, e.g., IPsec [RFC4301] and TCP-AO 118 [RFC5925]. This document briefly notes the need to address this 119 aspect of BGP security, but focuses on application layer BGP security 120 issues that must be addressed by PATHSEC.) 122 RFC 4272 [RFC4272] succinctly notes: 124 "BGP speakers themselves can inject bogus routing information, 125 either by masquerading as any other legitimate BGP speaker, or by 126 distributing unauthorized routing information as themselves. 127 Historically, misconfigured and faulty routers have been 128 responsible for widespread disruptions in the Internet. The 129 legitimate BGP peers have the context and information to produce 130 believable, yet bogus, routing information, and therefore have the 131 opportunity to cause great damage. The cryptographic protections 132 of [TCPMD5] and operational protections cannot exclude the bogus 133 information arising from a legitimate peer. The risk of 134 disruptions caused by legitimate BGP speakers is real and cannot 135 be ignored." 137 PATHSEC is intended to address the concerns cited above, to provide 138 significantly improved path security, building upon the route 139 origination validation capability offered by use of the RPKI 140 [RFC6810]. Specifically, the RPKI enables relying parties (RPs) to 141 determine if the origin AS for a path was authorized to advertise the 142 prefix contained in a BGP update message. This security feature is 143 enabled by the use of two types of digitally signed data: a PKI 145 [RFC6487] that associates one or more prefixes with the public key(s) 146 of an address space holder, and Route Origination Authorizations 147 (ROAs) [RFC6482] that allows a prefix holder to specify the AS(es) 148 that are authorized to originate routes for a prefix. 150 The security model adopted for PATHSEC does not assume an "oracle" 151 that can see all of the BGP inputs and outputs associated with every 152 AS or every BGP router. Instead, the model is based on a local 153 notion of what constitutes legitimate, authorized behavior by the BGP 154 routers associated with an AS. This is an AS-centric model of secure 155 operation, consistent with the AS-centric model that BGP employs for 156 routing. This model forms the basis for the discussion that follows. 158 This document begins with a brief set of definitions relevant to the 159 subsequent sections. It then discusses classes of adversaries that 160 are perceived as viable threats against routing in the public 161 Internet. It continues to explore a range of attacks that might be 162 effected by these adversaries, against both path security and the 163 infrastructure upon which PATHSEC relies. It concludes with a brief 164 review of residual vulnerabilities, i.e., vulnerabilities that are 165 not addressed by use of the RPKI and that appear likely to be outside 166 the scope of PATHSEC mechanisms. 168 2. Terminology 170 The following security and routing terminology definitions are 171 employed in this document. 173 Adversary - An adversary is an entity (e.g., a person or an 174 organization) perceived as malicious, relative to the security policy 175 of a system. The decision to characterize an entity as an adversary 176 is made by those responsible for the security of a system. Often one 177 describes classes of adversaries with similar capabilities or 178 motivations, rather than specific individuals or organizations. 180 Attack - An attack is an action that attempts to violate the security 181 policy of a system, e.g., by exploiting a vulnerability. There is 182 often a many to one mapping of attacks to vulnerabilities, because 183 many different attacks may be used to exploit a vulnerability. 185 Autonomous System (AS) - An AS is a set of one or more IP networks 186 operated by a single administrative entity. 188 AS Number (ASN) - An ASN is a 2 or 4 byte number issued by a registry 189 to identify an AS in BGP. 191 Certification Authority (CA) - An entity that issues digital 192 certificates (e.g., X.509 certificates) and vouches for the binding 193 between the data items in a certificate. 195 Countermeasure - A countermeasure is a procedure or technique that 196 thwarts an attack, preventing it from being successful. Often 197 countermeasures are specific to attacks or classes of attacks. 199 Border Gateway Protocol (BGP) - A path vector protocol used to convey 200 "reachability" information among autonomous systems, in support of 201 inter-domain routing. 203 False (Route) Origination - If a network operator originates a route 204 for a prefix that the operator does not hold (and that it has not 205 been authorized to originate by the prefix holder, this is termed 206 false route origination. 208 Internet Service Provider (ISP) - An organization managing (and, 209 typically, selling,) Internet services to other organizations or 210 individuals. 212 Internet Number Resources (INRs) - IPv4 or IPv6 address space and 213 ASNs 215 Internet Registry - An organization that manages the allocation or 216 distribution of INRs. This encompasses the Internet Assigned Number 217 Authority (IANA), Regional Internet Registries (RIRs), National 218 Internet Registries (NIRs), and Local Internet Registries (LIRs, 219 network operators). 221 Man in the Middle (MITM) - A MITM is an entity that is able to 222 examine and modify traffic between two (or more) parties on a 223 communication path. 225 Network Operator - An entity that manages an AS and thus emits (E)BGP 226 updates, e.g., an ISP. 228 NOC (Network Operations Center) - A network operator employs a set 229 equipment and a staff to manage a network, typically on a 24/7 basis. 230 The equipment and staff are often referred to as the NOC for the 231 network. 233 Prefix - A prefix is an IP address and a mask used to specify a set 234 of addresses that are grouped together for purposes of routing. 236 Public Key Infrastructure (PKI) - A PKI is a collection of hardware, 237 software, people, policies, and procedures used to create, manage, 238 distribute, store, and revoke digital certificates. 240 Relying Parties (RPs) - An RP is an entity that makes use of signed 241 products from a PKI, i.e., relies on signed data that is verified 242 using certificates and Certificate Revocation Lists (CRLs) from a 243 PKI. 245 RPKI Repository System - The RPKI repository system consists of a 246 distributed set of loosely synchronized databases. 248 Resource PKI (RPKI) - A PKI operated by the entities that manage 249 INRs, and that issues X.509 certificates (and CRLs) that attest to 250 the holdings of INRs. 252 RPKI Signed Object - An RPKI signed object is a Cryptographic Message 253 Syntax (CMS)-encapsulated data object complying with the format and 254 semantics defined in [RFC6488]. 256 Route - In the Internet, a route is a prefix and an associated 257 sequence of ASNs that indicates a path via which traffic destined for 258 the prefix can be directed. (The route includes the origin AS.) 260 Route leak - A route leak is said to occur when AS-A advertises 261 routes that it has received from an AS-B to AS-A's neighbors, but 262 AS-A is not viewed as a transit provider for the prefixes in the 263 route. 265 Threat - A threat is a motivated, capable adversary. An adversary 266 that is not motivated to launch an attack is not a threat. An 267 adversary that is motivated but not capable of launching an attack 268 also is not a threat. 270 Vulnerability - A vulnerability is a flaw or weakness in a system's 271 design, implementation, or operation and management that could be 272 exploited to violate the security policy of a system. 274 3. Threat Characterization 276 As noted in Section 2 above, a threat is defined as a motivated, 277 capable, adversary. The following classes of threats represent 278 classes of adversaries viewed as relevant to this environment. 280 Network Operators - A network operator may be a threat. An operator 281 may be motivated to cause BGP routers it controls to emit update 282 messages with inaccurate routing info, e.g., to cause traffic to flow 283 via paths that are economically advantageous for the operator. Such 284 updates might cause traffic to flow via paths that would otherwise be 285 rejected as less advantageous by other network operators. Because an 286 operator controls the BGP routers in its network, it is in a position 287 to modify their operation in arbitrary ways. Routers managed by a 288 network operator are vehicles for mounting MITM attacks on both 289 control and data plane traffic. If an operator participates in the 290 RPKI, it will have at least one CA resource certificate and may be 291 able to generate an arbitrary number of subordinate CA certificates 292 and ROAs. It will be authorized to populate (and may even host) its 293 own repository publication point. If it implements PATHSEC, and if 294 PATHSEC makes use of certificates associated with routers or ASes, it 295 will have the ability to issue such certificates for itself. If 296 PATHSEC digitally signs updates, it will be able to do so in a 297 fashion that will be accepted by PATHSEC-enabled neighbors. 299 Hackers - Hackers are considered a threat. A hacker might assume 300 control of network management computers and routers controlled by 301 operators, including operators that implement PATHSEC. In such 302 cases, hackers would be able to act as rogue network operators (see 303 above). It is assumed that hackers generally do not have the 304 capability to effect MITM attacks on most links between networks 305 (links used to transmit BGP and subscriber traffic). A hacker might 306 be recruited, without his/her knowledge, by criminals or by nations, 307 to act on their behalf. Hackers may be motivated by a desire for 308 "bragging rights" or for profit or to express support for a cause 309 ("hacktivists" [Sam04]). We view hackers as possibly distinct from 310 criminals in that the former are presumed to effect attacks only 311 remotely (not via a physical presence associated with a target) and 312 not necessarily for monetary gain. Some hackers may commit criminal 313 acts (depending on the jurisdiction), and thus there is a potential 314 for overlap between this adversary group and criminals. 316 Criminals - Criminals may be a threat. Criminals might persuade (via 317 threats or extortion) a network operator to act as a rogue operator 318 (see above), and thus be able to effect a wide range of attacks. 319 Criminals might persuade the staff of a telecommunications provider 320 to enable MITM attacks on links between routers. Motivations for 321 criminals may include the ability to extort money from network 322 operators or network operator clients, e.g., by adversely affecting 323 routing for these network operators or their clients. Criminals also 324 may wish to manipulate routing to conceal the sources of spam, DoS 325 attacks, or other criminal activities. 327 Registries - Any registry in the RPKI could be a threat. Staff at 328 the registry are capable of manipulating repository content or 329 mismanaging the RPKI certificates that they issue. These actions 330 could adversely affect a network operator or a client of a network 331 operator. The staff could be motivated to do this based on political 332 pressure from the nation in which the registry operates (see below) 333 or due to criminal influence (see above). 335 Nations - A nation may be a threat. A nation may control one or more 336 network operators that operate in the nation, and thus can cause them 337 to act as rogue network operators. A nation may have a technical 338 active wiretapping capability (e.g., within its territory) that 339 enables it to effect MITM attacks on inter-network traffic. (This 340 capability may be facilitated by control or influence over a 341 telecommunications provider operating within the nation.) It may 342 have an ability to attack and take control of routers or management 343 network computers of network operators in other countries. A nation 344 may control a registry (e.g., an RIR) that operates within its 345 territory, and might force that registry to act in a rogue capacity. 346 National threat motivations include the desire to control the flow of 347 traffic to/from the nation or to divert traffic destined for other 348 nations (for passive or active wiretapping, including DoS). 350 4. Attack Characterization 352 This section describes classes of attacks that may be effected 353 against Internet routing (relative to the context described in 354 Section 1). Attacks are classified based on the target of the 355 attack, as an element of the routing system, or the routing security 356 infrastructure on which PATHSEC relies. In general, attacks of 357 interest are ones that attempt to violate the integrity or 358 authenticity of BGP traffic, or which violate the authorizations 359 associated with entities participating in the RPKI. Attacks that 360 violate the implied confidentiality of routing traffic, e.g., passive 361 wiretapping attacks, are not considered a requirement for BGP 362 security (see [RFC4272]). 364 4.1. Active wiretapping of sessions between routers 366 An adversary may attack the BGP (TCP) session that connects a pair of 367 BGP speakers. An active attack against a BGP (TCP) session can be 368 effected by directing traffic to a BGP speaker from some remote 369 point, or by being positioned as a MITM on the link that carries BGP 370 session traffic. Remote attacks can be effected by any adversary. A 371 MITM attack requires access to the link. Modern transport networks 372 may be as complex as the packet networks that utilize them for inter- 373 AS links. Thus these transport networks may present significant 374 attack surfaces. Nonetheless, only some classes of adversaries are 375 assumed to be capable of MITM attacks against a BGP session. MITM 376 attacks may be directed against BGP, PATHSEC-protected BGP, or 377 against TCP or IP. Such attacks include replay of selected BGP 378 messages, selective modification of BGP messages, and DoS attacks 379 against BGP routers. [RFC4272] describes several countermeasures for 380 such attacks, and thus this document does not further address such 381 attacks. 383 4.2. Attacks on a BGP router 385 An adversary may attack a BGP router, whether it implements PATHSEC 386 or not. Any adversary that controls routers legitimately, or that 387 can assume control of a router, is assumed to be able to effect the 388 types of attacks described below. Note that any router behavior that 389 can be ascribed to a local routing policy decision is not considered 390 to be an attack. This is because such behavior could be explained as 391 a result of local policy settings, and thus is beyond the scope of 392 what PATHSEC can detect as unauthorized behavior. Thus, for example, 393 a router may fail to propagate some or all route withdrawals or 394 effect "route leaks". (These behaviors are not precluded by the 395 specification for BGP, and might be the result of a local policy that 396 is not publicly disclosed. As a result, they are not considered 397 attacks. See Section 5 for additional discussion.) 399 Attacks on a router are equivalent to active wiretapping attacks (in 400 the most general sense) that manipulate (forge, tamper with, or 401 suppress) data contained in BGP updates. The list below illustrates 402 attacks of this type. 404 AS Insertion: A router might insert one or more ASNs, other than 405 its own ASN, into an update message. This violates the BGP spec 406 and thus is considered an attack. 408 False (Route) Origination: A router might originate a route for a 409 prefix, when the AS that the router represents is not authorized 410 to originate routes for that prefix. This is an attack, but it is 411 addressed by the use of the RPKI [RFC6480]. 413 Secure Path Downgrade: A router might remove AS_PATH data from a 414 PATHSEC-protected update that it receives, when forwarding this 415 update to a PATHSEC-enabled neighbor. This behavior violates the 416 PATHSEC security goals and thus is considered an attack. 418 Invalid AS_PATH Data Insertion: A router might emit a PATHSEC- 419 protected update with "bad" data (such as a signature), i.e., 420 PATHSEC data that cannot be validated by other PATHSEC routers. 421 Such behavior is assumed to violate the PATHSEC goals and thus is 422 considered an attack. 424 Stale Path Announcement: If PATHSEC-secured announcements can 425 expire, such an announcement may be propagated with PATHSEC data 426 that is "expired". This behavior would violate the PATHSEC goals 427 and is considered a type of replay attack. 429 Premature Path Announcement Expiration: If a PATHSEC-secured 430 announcement has an associated expiration time, a router might 431 emit a PATHSEC-secured announcement with an expiry time that is 432 very short. Unless the PATHSEC protocol specification mandates a 433 minimum expiry time, this is not an attack. However, if such a 434 time is mandated, this behavior becomes an attack. BGP speakers 435 along a path generally cannot determine if an expiry time is 436 "suspiciously short" since they cannot know how long a route may 437 have been held by an earlier AS, prior to being released. 439 MITM Attack: A cryptographic key used for point-to-point security 440 (e.g., TCP-AO, TLS, or IPsec) between two BGP routers might be 441 compromised (e.g., by extraction from a router). This would 442 enable an adversary to effect MITM attacks on the link(s) where 443 the key is used. Use of specific security mechanisms to protect 444 inter-router links between ASes is outside the scope of PATHSEC. 446 Compromised Router Private Key: If PATHSEC mechanisms employ 447 public key cryptography, e.g., to digitally sign data in an 448 update, then a private key associated with a router or an AS might 449 be compromised by an attack against the router. An adversary with 450 access to this key would be able to generate updates that appear 451 to have passed through the AS that this router represents. Such 452 updates might be in injected on a link between the compromised 453 router and its neighbors, if that link is accessible to the 454 adversary. If the adversary controls another network, it could 455 use this key to forge signatures that appear to come from the AS 456 or router(s) in question, with some constraints. So, for example, 457 an adversary that controls another AS could use a compromised 458 router/AS key to issue PATHSEC-signed data that include the 459 targeted AS/router. (Neighbors of the adversary's AS ought not 460 accept a route that purports to emanate directly from the targeted 461 AS. So, an adversary could take a legitimate, protected route 462 that passes through the compromised AS, add itself as the next 463 hop, and then forward the resulting route to neighbors.) 465 Withdrawal Suppression Attack: A PATHSEC-protected update may be 466 signed and announced, and later withdrawn. An adversary 467 controlling intermediate routers could fail to propagate the 468 withdrawal. BGP is already vulnerable to behavior of this sort, 469 so withdrawal suppression is not characterized as an attack, under 470 the assumptions upon which this mode is based (i.e., no oracle). 472 4.3. Attacks on network operator management computers (non-CA 473 computers) 475 An adversary may choose to attack computers used by a network 476 operator to manage its network, especially its routers. Such attacks 477 might be effected by an adversary who has compromised the security of 478 these computers. This might be effected via remote attacks, 479 extortion of network operations staff, etc. If an adversary 480 compromises NOC computers, he can execute any management function 481 that authorized network operations staff would have performed. Thus 482 the adversary could modify local routing policy to change 483 preferences, to black-hole certain routes, etc. This type of 484 behavior cannot be externally detected as an attack. Externally, 485 this appears as a form of rogue operator behavior. (Such behavior 486 might be perceived as accidental or malicious by other operators.) 488 If a network operator participates in the RPKI, an adversary could 489 manipulate the RP tools that extract data from the RPKI, causing the 490 output of these tools to be corrupted in various ways. For example, 491 an attack of this sort could cause the operator to view valid routes 492 as not validated, which could alter its routing behavior. 494 If an adversary invoked the tool used to manage the repository 495 publication point for this operator, it could delete any objects 496 stored there (certificates, CRLs, manifests, ROAs, or subordinate CA 497 certificates). This could affect the routing status of entities that 498 have allocations/assignments from this network operator (e.g., by 499 deleting their CA certificates). 501 An adversary could invoke the tool used to request certificate 502 revocation, causing router certificates, ROAs, or subordinate CA 503 certificates to be revoked. An attack of this sort could affect not 504 only this operator, but also any operators that receive allocations/ 505 assignments from it, e.g., because their CA certificates were 506 revoked. 508 If an operator is PATHSEC-enabled, an attack of this sort could cause 509 the affected operator to be viewed as not PATHSEC-enabled, possibly 510 making routes it emits be less preferred by other operators. 512 If an adversary invoked a tool used to request ROAs, it could 513 effectively re-allocate some of the prefixes allocated/assigned to 514 the network operator (e.g., by modifying the origin AS in ROAs). 515 This might cause other PATHSEC-enabled networks to view the affected 516 network as no longer originating routes for these prefixes. Multi- 517 homed subscribers of this operator who received an allocation from 518 the operator might find their traffic was now routed via other 519 connections. 521 If the network operator is PATHSEC-enabled, and make use of 522 certificates associated with routers/ASes, an adversary could invoke 523 a tool used to request such certificates. The adversary could then 524 replace valid certificates for routers/ASes with ones that might be 525 rejected by PATHSEC-enabled neighbors. 527 4.4. Attacks on a repository publication point 529 A critical element of the RPKI is the repository system. An 530 adversary might attack a repository, or a publication point within a 531 repository, to adversely affect routing. 533 This section considers only those attacks that can be launched by any 534 adversary who controls a computer hosting one or more repository 535 publication points, without access to the cryptographic keys needed 536 to generate valid RPKI signed products. Such attacks might be 537 effected by an insider or an external threat. Because all repository 538 objects are digitally signed, attacks of this sort translate into DoS 539 attacks against the RPKI RPs. There are a few distinct forms of such 540 attacks, as described below. 542 Note first that the RPKI calls for RPs to cache the data they acquire 543 and verify from the repository system [RFC6480][RFC6481]. Attacks 544 that delete signed products, that insert products with "bad" 545 signatures, that tamper with object signatures, or that replace newer 546 objects with older (valid) ones, can be detected by RPs (with a few 547 exceptions). RPs are expected to make use of local caches. If 548 repository publication points are unavailable or the retrieved data 549 is corrupted, an RP can revert to using the cached data. This 550 behavior helps insulate RPs from the immediate effects of DoS attacks 551 on publication points. 553 Each RPKI data object has an associated date at which it expires, or 554 is considered stale. (Certificates expire, CRLs become stale.) When 555 an RP uses cached data it is a local decision how to deal with stale 556 or expired data. It is common in PKIs to make use of stale 557 certificate revocation status data, when fresher data is not 558 available. Use of expired certificates is less common, although not 559 unknown. Each RP will decide, locally, whether to continue to make 560 use of or ignore cached RPKI objects that are stale or expired. 562 If an adversary inserts an object into a publication point, and the 563 object has a "bad" signature, the object will not be accepted and 564 used by RPs. 566 If an adversary modifies any signed product at a publication point, 567 the signature on the product will fail, causing RPs to not accept it. 568 This is equivalent to deleting the object, in many respects. 570 If an adversary deletes one or more CA certificates, ROAs or the CRL 571 for a publication point, the manifest for that publication point will 572 allow an RP to detect this attack. An RP can continue to use the 573 last valid instance of the deleted object (as a local policy option), 574 thus minimizing the impact of such an attack. 576 If an adversary deletes a manifest (and does not replace it with an 577 older instance), that is detectable by RPs. Such behavior should 578 result in the CA (or publication point maintainer) being notified of 579 the problem. An RP can continue to use the last valid instance of 580 the deleted manifest (a local policy option), thus minimizing the 581 impact of such an attack. 583 If an adversary deletes newly added CA certificates or ROAs, and 584 replaces the current manifest with the previous manifest, the 585 manifest (and the CRL that it matches) will be "stale" (see 586 [RFC6486]). This alerts an RP that there may be a problem. The RP 587 should use the information from a Ghostbuster record [RFC6493] to 588 contact the entity responsible for the publication point, requesting 589 that entity to remedy the problem (e.g., republish the missing CA 590 certificates and/or ROAs). An RP cannot know the content of the new 591 certificates or ROAs that are not present, but it can continue to use 592 what it has cached. An attack of this sort will, at least 593 temporarily, cause RPs to be unaware of the newly published objects. 594 INRs associated with these objects will be treated as 595 unauthenticated. 597 If a CA revokes a CA certificate or a ROA (via deleting the 598 corresponding EE certificate), and the adversary tries to reinstate 599 that CA certificate or ROA, the adversary would have to rollback the 600 CRL and the manifest to undo this action by the CA. As above, this 601 would make the CRL and manifest stale, and this is detectable by RPs. 602 An RP cannot know which CA certificates or ROAs were deleted. 603 Depending on local policy, the RP might use the cached instances of 604 the affected objects, and thus be tricked into making decisions based 605 on these revoked objects. Here too the goal is that the CA will be 606 notified of the problem (by RPs) and will remedy the error. 608 In the attack scenarios above, when a CRL or manifest is described as 609 stale, this means that the next issue date for the CRL or manifest 610 has passed. Until the next issue date, an RP will not detect the 611 attack. Thus it behooves CAs to select CRL/manifest lifetimes (the 612 two are linked) that represent an acceptable trade-off between risk 613 and operational burdens. 615 Attacks effected by adversaries that are legitimate managers of 616 publication points can have much greater effects, and are discussed 617 below under attacks on or by CAs. 619 4.5. Attacks on an RPKI CA 621 Every entity to which INRs have been allocated/assigned is a CA in 622 the RPKI. Each CA is nominally responsible for managing the 623 repository publication point for the set of signed products that it 624 generates. (An INR holder may choose to outsource the operation of 625 the RPKI CA function, and the associated publication point. In such 626 cases, the organization operating on behalf of the INR holder becomes 627 the CA, from an operational and security perspective. The following 628 discussion does not distinguish such outsourced CA operations.) 630 Note that attacks attributable to a CA may be the result of malice by 631 the CA (i.e., the CA is the adversary) or they may result from a 632 compromise of the CA. 634 All of adversaries listed in Section 2 are presumed to be capable of 635 launching attacks against the computers used to perform CA functions. 636 Some adversaries might effect an attack on a CA by violating 637 personnel or physical security controls as well. The distinction 638 between CA as adversary vs. CA as an attack victim is important. 639 Only in the latter case should one expect the CA to remedy problems 640 caused by a attack once the attack has been detected. (If a CA does 641 not take such action, the effects are the same as if the CA is an 642 adversary.) 644 Note that most of the attacks described below do not require 645 disclosure of a CA's private key to an adversary. If the adversary 646 can gain control of the computer used to issue certificates, it can 647 effect these attacks, even though the private key for the CA remains 648 "secure" (i.e., not disclosed to unauthorized parties). However, if 649 the CA is not the adversary, and if the CA's private key is not 650 compromised, then recovery from these attacks is much easier. This 651 motivates use of hardware security modules to protect CA keys, at 652 least for higher tiers in the RPKI. 654 An attack by a CA can result in revocation or replacement of any of 655 the certificates that the CA has issued. Revocation of a certificate 656 should cause RPs to delete the (formerly) valid certificate (and 657 associated signed object, in the case of a revoked EE certificate) 658 that they have cached. This would cause repository objects (e.g., CA 659 certificates and ROAs) that are verified under that certificate to be 660 considered invalid, transitively. As a result, RPs would not 661 consider as valid any ROAs or PATHSEC-protected updates based on 662 these certificates, which would make routes dependent on them to be 663 less preferred. Because a CA that revokes a certificate is 664 authorized to do so, this sort of attack cannot be detected, 665 intrinsically, by most RPs. However, the entities affected by the 666 revocation or replacement of CA certificates can be expected to 667 detect the attack and contact the CA to effect remediation. If the 668 CA was not the adversary, it should be able to issue new certificates 669 and restore the publication point. 671 An adversary that controls the CA for a publication point can publish 672 signed products that create more subtle types of DoS attacks against 673 RPs. For example, such an attacker could create subordinate CA 674 certificates with Subject Information Access (SIA) pointers that lead 675 RPs on a "wild goose chase" looking for additional publication points 676 and signed products. An attacker could publish certificates with 677 very brief validity intervals, or CRLs and manifests that become 678 "stale" very quickly. This sort of attack would cause RPs to access 679 repositories more frequently, and that might interfere with 680 legitimate accesses by other RPs. 682 An attacker with this capability could create very large numbers of 683 ROAs to be processed (with prefixes that are consistent with the 684 allocation for the CA), and correspondingly large manifests. An 685 attacker could create very deep subtrees with many ROAs per 686 publication point, etc. All of these types of DoS attacks against 687 RPs are feasible within the syntactic and semantic constraints 688 established for RPKI certificates, CRLs, and signed objects. 690 An attack that results in revocation and replacement (e.g., key 691 rollover or certificate renewal) of a CA certificate would cause RPs 692 to replace the old, valid certificate with the new one. This new 693 certificate might contain a public key that does not correspond to 694 the private key held by the certificate subject. That would cause 695 objects signed by that subject to be rejected as invalid, and prevent 696 the affected subject from being able to sign new objects. As above, 697 RPs would not consider as valid any ROAs issued under the affected CA 698 certificate, and updates based on router certificates issued by the 699 affected CA would be rejected. This would make routes dependent on 700 these signed products to be less preferred. However, the constraints 701 imposed by the use of RFC 3779 [RFC3779] extensions do prevent a 702 compromised CA from issuing (valid) certificates with INRs outside 703 the scope of the CA, thus limiting the impact of the attack. 705 An adversary that controls a CA could issue CA certificates with 706 overlapping INRs to different entities, when no transfer of INRs is 707 intended. This could cause confusion for RPs as conflicting ROAs 708 could be issued by the distinct (subordinate) CAs. 710 An adversary could replace a CA certificate, use the corresponding 711 private key to issue new signed products, and then publish them at a 712 publication point controlled by the attacker. This would effectively 713 transfer the affected INRs to the adversary, or to a third party of 714 his choosing. The result would be to cause RPs to view the entity 715 that controls the private key in question as the legitimate INR 716 holder. Again the constraints imposed by the use of RFC 3779 717 extensions prevent a compromised CA from issuing (valid) certificates 718 with INRs outside the scope of the CA, thus limiting the impact of 719 the attack. 721 Finally, an entity that manages a repository publication point can 722 inadvertently act as an attacker (an example of Walt Kelly's most 723 famous "Pogo" quote [Kelly70]). For example, a CA might fail to 724 replace its own certificate in a timely fashion (well before it 725 expires). If might fail to issue its CRL and manifest prior to 726 expiration, creating stale instances of these products that cause 727 concern for RPs. A CA with many subordinate CAs (e.g., an RIR or 728 NIR) might fail to distribute the expiration times for the CA 729 certificates that it issues. A network with many ROAs might do the 730 same for the EE certificates associated with the ROAs it generates. 731 A CA could rollover its key, but fail to reissue subordinate CA 732 certificates under its new key. Poor planning with regard to rekey 733 intervals for managed CAs could impose undue burdens for RPs, despite 734 a lack of malicious intent. All of these example of mismanagement 735 could adversely affect RPs, despite the absence of malicious intent. 737 5. Residual Vulnerabilities 739 The RPKI, upon which PATHSEC relies, has several residual 740 vulnerabilities that were discussed in the preceding text 741 (Section 4.4 and Section 4.5). These vulnerabilities are of two 742 principle forms: 744 o the RPKI repository system may be attacked in ways that make its 745 contents unavailable, not current, or inconsistent. The principle 746 defense against most forms of DoS attacks is the use of a local 747 cache by each RP. The local cache ensures availability of 748 previously-acquired RPKI data, in the event that a repository is 749 inaccessible or if repository contents are deleted (maliciously). 750 Nonetheless, the system cannot ensure that every RP will always 751 have access to up-to-date RPKI data. An RP, when it detects a 752 problem with acquired repository data has two options: 754 1. The RP may choose to make use of its local cache, employing 755 local configuration settings that tolerate expired or stale 756 objects. (Such behavior is, nominally, always within the 757 purview of an RP in PKI.) Using cached, expired or stale data 758 subjects the RP to attacks that take advantage of the RP's 759 ignorance of changes to this data. 761 2. The RP may chose to purge expired objects. Purging expired 762 objects removes the security info associated with the real 763 world INRs to which the objects refer. This is equivalent to 764 the affected INRs not having been afforded protection via the 765 RPKI. Since use of the RPKI (and PATHSEC) is voluntary, there 766 may always be set of INRs that are not protected by these 767 mechanisms. Thus purging moves the affected INRs to the set 768 of non-participating INR holders. This more conservative 769 response enables an attacker to move INRs from the protected 770 to the unprotected set. 772 o any CA in the RPKI may misbehave within the bounds of the INRs 773 allocated to it, e.g., it may issue certificates with duplicate 774 resource allocations or revoke certificates inappropriately. This 775 vulnerability is intrinsic in any PKI, but its impact is limited 776 in the RPKI because of the use of RFC 3779 extensions. It is 777 anticipated that RPs will deal with such misbehavior through 778 administrative means, once it is detected. 780 PATHSEC has a separate set of residual vulnerabilities: 782 o It has been stated that "route leaks" are viewed as a routing 783 security problem by many operators. However, BGP itself does not 784 include semantics that preclude what many perceive as route leaks, 785 and there is no definition of the term in any RFC. This makes it 786 inappropriate to address route leaks in this document. 787 Additionally, route leaks are outside the scope of PATHSEC, 788 consistent with the security context noted in Section 1 of this 789 document. If, at a later time, the SIDR security context is 790 revised to include route leaks, and an appropriate definition 791 exists, this document should be revised. 793 o PATHSEC is not required to protect all attributes associated with 794 an AS_PATH, even though some of these attributes may be employed 795 as inputs to routing decisions. Thus attacks that modify (or 796 strip) these other attributes are not prevented/detected by 797 PATHSEC. As noted in Section 1, the SIDR security context calls 798 for protecting only the info needed to verify that a received 799 route traversed the ASes in question, and that the NLRI in the 800 route is what was advertised. (The AS_PATH data also may have 801 traversed ASes within a confederation that are not represented. 802 However, these ASes are not externally visible, and thus do not 803 influence route selection, so their omission in this context is 804 not a security concern.) Thus, protection of other attributes is 805 outside the scope of this document, as described in Section 1. 806 If, at a later time, the SIDR security context is revised to 807 include protection of additional BGP attributes, this document 808 should be revised. 810 o PATHSEC cannot ensure that an AS will withdraw a route when the AS 811 no longer has a route for a prefix, as noted in Section 4.2. 812 PATHSEC may incorporate features to limit the lifetime of an 813 advertisement. Such lifetime limits provide an upper bound on the 814 time that the failure to withdraw a route will remain effective. 816 6. Security Considerations 818 A threat model is, by definition, a security-centric document. 819 Unlike a protocol description, a threat model does not create 820 security problems nor purport to address security problems. This 821 model postulates a set of threats (i.e., motivated, capable 822 adversaries) and examines classes of attacks that these threats are 823 capable of effecting, based on the motivations ascribed to the 824 threats. It describes the impact of these types of attacks on 825 PATHSEC, including on the RPKI on which PATHSEC relies. It describes 826 how the design of the RPKI (and the PATHSEC design goals) address 827 classes of attacks, where applicable. It also notes residual 828 vulnerabilities. 830 7. IANA Considerations 832 [Note to IANA, to be removed prior to publication: there are no IANA 833 considerations stated in this version of the document.] 835 8. Acknowledgements 837 TBD 839 9. Informative References 841 [Kelly70] Kelly, W., "'We Have Met the Enemy, and He is Us': Pogo 842 Earth Day Poster", April 1970. 844 [Kent2000] 845 Kent, S., Lynn, C., and K. Seo, "Design and Analysis of 846 the Secure Border Gateway Protocol (S-BGP)", IEEE DISCEX 847 Conference, June 2000. 849 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 850 Addresses and AS Identifiers", RFC 3779, June 2004. 852 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 853 Protocol 4 (BGP-4)", RFC 4271, January 2006. 855 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 856 4272, January 2006. 858 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 859 Internet Protocol", RFC 4301, December 2005. 861 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 862 Authentication Option", RFC 5925, June 2010. 864 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 865 Secure Internet Routing", RFC 6480, February 2012. 867 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 868 Resource Certificate Repository Structure", RFC 6481, 869 February 2012. 871 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 872 Origin Authorizations (ROAs)", RFC 6482, February 2012. 874 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 875 "Manifests for the Resource Public Key Infrastructure 876 (RPKI)", RFC 6486, February 2012. 878 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 879 X.509 PKIX Resource Certificates", RFC 6487, February 880 2012. 882 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object 883 Template for the Resource Public Key Infrastructure 884 (RPKI)", RFC 6488, February 2012. 886 [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) 887 Ghostbusters Record", RFC 6493, February 2012. 889 [RFC6810] Bush, R. and R. Austein, "The Resource Public Key 890 Infrastructure (RPKI) to Router Protocol", RFC 6810, 891 January 2013. 893 [SIDR-CH] "Secure Inter-Domain Routing: Charter for Working Group", 894 September 2013, . 897 [Sam04] Samuel, A., "Hacktivism and the Future of Political 898 Participation", Ph.D. dissertation, Harvard University, 899 August 2004. 901 Authors' Addresses 903 Stephen Kent 904 BBN Technologies 905 10 Moulton St. 906 Cambridge, MA 02138 907 US 909 Email: kent@bbn.com 911 Andrew Chi 912 University of North Carolina - Chapel Hill 913 c/o Department of Computer Science 914 CB 3175, Sitterson Hall 915 Chapel Hill, NC 27599 916 US 918 Email: achi@cs.unc.edu