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