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