idnits 2.17.1 draft-ietf-sidr-bgpsec-threats-03.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 (September 14, 2012) is 4232 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: March 18, 2013 September 14, 2012 7 Threat Model for BGP Path Security 8 draft-ietf-sidr-bgpsec-threats-03 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 March 18, 2013. 60 Copyright Notice 62 Copyright (c) 2012 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 [I-D.ietf-sidr-rpki-rtr]. Specifically, the RPKI enables relying 138 parties (RPs) to determine if the origin AS for a path was authorized 139 to advertise the prefix contained in a BGP update message. This 140 security feature is enabled by the use of two types of digitally 141 signed data: a PKI [RFC6487] that associates one or more prefixes 142 with the public key(s) of an address space holder, and Route 143 Origination Authorizations (ROAs) [RFC6482] that allows a prefix 144 holder to specify the AS(es) that are authorized to originate routes 145 for a prefix. 147 The security model adopted for PATHSEC does not assume an "oracle" 148 that can see all of the BGP inputs and outputs associated with every 149 AS or every BGP router. Instead, the model is based on a local 150 notion of what constitutes legitimate, authorized behavior by the BGP 151 routers associated with an AS. This is an AS-centric model of secure 152 operation, consistent with the AS-centric model that BGP employs for 153 routing. This model forms the basis for the discussion that follows. 155 This document begins with a brief set of definitions relevant to the 156 subsequent sections. It then discusses classes of adversaries that 157 are perceived as viable threats against routing in the public 158 Internet. It continues to explore a range of attacks that might be 159 effected by these adversaries, against both path security and the 160 infrastructure upon which PATHSEC relies. It concludes with a brief 161 review of residual vulnerabilities, i.e., vulnerabilities that are 162 not addressed by use of the RPKI and that appear likely to be outside 163 the scope of PATHSEC mechanisms. 165 2. Terminology 167 The following security and routing terminology definitions are 168 employed in this document. 170 Adversary - An adversary is an entity (e.g., a person or an 171 organization) perceived as malicious, relative to the security policy 172 of a system. The decision to characterize an entity as an adversary 173 is made by those responsible for the security of a system. Often one 174 describes classes of adversaries with similar capabilities or 175 motivations, rather than specific individuals or organizations. 177 Attack - An attack is an action that attempts to violate the security 178 policy of a system, e.g., by exploiting a vulnerability. There is 179 often a many to one mapping of attacks to vulnerabilities, because 180 many different attacks may be used to exploit a vulnerability. 182 Autonomous System (AS) - An AS is a set of one or more IP networks 183 operated by a single administrative entity. 185 AS Number (ASN) - An ASN is a 2 or 4 byte number issued by a registry 186 to identify an AS in BGP. 188 Certification Authority (CA) - An entity that issues digital 189 certificates (e.g., X.509 certificates) and vouches for the binding 190 between the data items in a certificate. 192 Countermeasure - A countermeasure is a procedure or technique that 193 thwarts an attack, preventing it from being successful. Often 194 countermeasures are specific to attacks or classes of attacks. 196 Border Gateway Protocol (BGP) - A path vector protocol used to convey 197 "reachability" information among autonomous systems, in support of 198 inter-domain routing. 200 False (Route) Origination - If a network operator originates a route 201 for a prefix that the operator does not hold (and that it has not 202 been authorized to originate by the prefix holder, this is termed 203 false route origination. 205 Internet Service Provider (ISP) - An organization managing (and, 206 typically, selling,) Internet services to other organizations or 207 individuals. 209 Internet Number Resources (INRs) - IPv4 or IPv6 address space and 210 ASNs 212 Internet Registry - An organization that manages the allocation or 213 distribution of INRs. This encompasses the Internet Assigned Number 214 Authority (IANA), Regional Internet Registries (RIRs), National 215 Internet Registries (NIRs), and Local Internet Registries (LIRs, 216 network operators). 218 Man in the Middle (MITM) - A MITM is an entity that is able to 219 examine and modify traffic between two (or more) parties on a 220 communication path. 222 Network Operator - An entity that manages an AS and thus emits (E)BGP 223 updates, e.g., an ISP. 225 NOC (Network Operations Center) - A network operator employs a set 226 equipment and a staff to manage a network, typically on a 24/7 basis. 227 The equipment and staff are often referred to as the NOC for the 228 network. 230 Prefix - A prefix is an IP address and a mask used to specify a set 231 of addresses that are grouped together for purposes of routing. 233 Public Key Infrastructure (PKI) - A PKI is a collection of hardware, 234 software, people, policies, and procedures used to create, manage, 235 distribute, store, and revoke digital certificates. 237 Relying Parties (RPs) - An RP is an entity that makes use of signed 238 products from a PKI, i.e., relies on signed data that is verified 239 using certificates and Certificate Revocation Lists (CRLs) from a 240 PKI. 242 RPKI Repository System - The RPKI repository system consists of a 243 distributed set of loosely synchronized databases. 245 Resource PKI (RPKI) - A PKI operated by the entities that manage 246 INRs, and that issues X.509 certificates (and CRLs) that attest to 247 the holdings of INRs. 249 RPKI Signed Object - An RPKI signed object is a Cryptographic Message 250 Syntax (CMS)-encapsulated data object complying with the format and 251 semantics defined in [RFC6488]. 253 Route - In the Internet, a route is a prefix and an associated 254 sequence of ASNs that indicates a path via which traffic destined for 255 the prefix can be directed. (The route includes the origin AS.) 257 Route leak - A route leak is said to occur when AS-A advertises 258 routes that it has received from an AS-B to AS-A's neighbors, but 259 AS-A is not viewed as a transit provider for the prefixes in the 260 route. 262 Threat - A threat is a motivated, capable adversary. An adversary 263 that is not motivated to launch an attack is not a threat. An 264 adversary that is motivated but not capable of launching an attack 265 also is not a threat. 267 Vulnerability - A vulnerability is a flaw or weakness in a system's 268 design, implementation, or operation and management that could be 269 exploited to violate the security policy of a system. 271 3. Threat Characterization 273 As noted in Section 2 above, a threat is defined as a motivated, 274 capable, adversary. The following classes of threats represent 275 classes of adversaries viewed as relevant to this environment. 277 Network Operators - A network operator may be a threat. An operator 278 may be motivated to cause BGP routers it controls to emit update 279 messages with inaccurate routing info, e.g. to cause traffic to flow 280 via paths that are economically advantageous for the operator. Such 281 updates might cause traffic to flow via paths that would otherwise be 282 rejected as less advantageous by other network operators. Because an 283 operator controls the BGP routers in its network, it is in a position 284 to modify their operation in arbitrary ways. Routers managed by a 285 network operator are vehicles for mounting MITM attacks on both 286 control and data plane traffic. If an operator participates in the 287 RPKI, it will have at least one CA resource certificate and may be 288 able to generate an arbitrary number of subordinate CA certificates 289 and ROAs. It will be authorized to populate (and may even host) its 290 own repository publication point. If it implements PATHSEC, and if 291 PATHSEC makes use of certificates associated with routers or ASes, it 292 will have the ability to issue such certificates for itself. If 293 PATHSEC digitally signs updates, it will be able to do so in a 294 fashion that will be accepted by PATHSEC-enabled neighbors. 296 Hackers - Hackers are considered a threat. A hacker might assume 297 control of network management computers and routers controlled by 298 operators, including operators that implement PATHSEC. In such 299 cases, hackers would be able to act as rogue network operators (see 300 above). It is assumed that hackers generally do not have the 301 capability to effect MITM attacks on most links between networks 302 (links used to transmit BGP and subscriber traffic). A hacker might 303 be recruited, without his/her knowledge, by criminals or by nations, 304 to act on their behalf. Hackers may be motivated by a desire for 305 "bragging rights" or for profit or to express support for a cause 306 ("hacktivists" [Sam04]). 308 Criminals - Criminals may be a threat. Criminals might persuade (via 309 threats or extortion) a network operator to act as a rogue operator 310 (see above), and thus be able to effect a wide range of attacks. 311 Criminals might persuade the staff of a telecommunications provider 312 to enable MITM attacks on links between routers. Motivations for 313 criminals may include the ability to extort money from network 314 operators or network operator clients, e.g., by adversely affecting 315 routing for these network operators or their clients. Criminals also 316 may wish to manipulate routing to conceal the sources of spam, DoS 317 attacks, or other criminal activities. 319 Registries - Any registry in the RPKI could be a threat. Staff at 320 the registry are capable of manipulating repository content or 321 mismanaging the RPKI certificates that they issue. These actions 322 could adversely affect a network operator or a client of a network 323 operator. The staff could be motivated to do this based on political 324 pressure from the nation in which the registry operates (see below) 325 or due to criminal influence (see above). 327 Nations - A nation may be a threat. A nation may control one or more 328 network operators that operate in the nation, and thus can cause them 329 to act as rogue network operators. A nation may have a technical 330 active wiretapping capability (e.g., within its territory) that 331 enables it to effect MITM attacks on inter-network traffic. (This 332 capability may be facilitated by control or influence over a 333 telecommunications provider operating within the nation.) It may 334 have an ability to attack and take control of routers or management 335 network computers of network operators in other countries. A nation 336 may control a registry (e.g., an RIR) that operates within its 337 territory, and might force that registry to act in a rogue capacity. 338 National threat motivations include the desire to control the flow of 339 traffic to/from the nation or to divert traffic destined for other 340 nations (for passive or active wiretapping, including DoS). 342 4. Attack Characterization 344 This section describes classes of attacks that may be effected 345 against Internet routing (relative to the context described in 346 Section 1). Attacks are classified based on the target of the 347 attack, as an element of the routing system, or the routing security 348 infrastructure on which PATHSEC relies. In general, attacks of 349 interest are ones that attempt to violate the integrity or 350 authenticity of BGP traffic, or which violate the authorizations 351 associated with entities participating in the RPKI. Attacks that 352 violate the implied confidentiality of routing traffic, e.g., passive 353 wiretapping attacks, are not considered a requirement for BGP 354 security (see [RFC4272]). 356 4.1. Active wiretapping of sessions between routers 358 An adversary may attack the BGP (TCP) session that connects a pair of 359 BGP speakers. An active attack against a BGP (TCP) session can be 360 effected by directing traffic to a BGP speaker from some remote 361 point, or by being positioned as a MITM on the link that carries BGP 362 session traffic. Remote attacks can be effected by any adversary. 363 However, a MITM attack requires access to the link, and only a few 364 classes of adversaries are assumed to be capable of MITM attacks 365 against a BGP session. MITM attacks may be directed against BGP, 366 PATHSEC-protected BGP, or against TCP or IP. Such attacks include 367 replay of selected BGP messages, selective modification of BGP 368 messages, and DoS attacks against BGP routers. [RFC4272] describes 369 several countermeasures for such attacks, and thus this document does 370 not further address such attacks. 372 4.2. Attacks on a BGP router 374 An adversary may attack a BGP router, whether it implements PATHSEC 375 or not. Any adversary that controls routers legitimately, or that 376 can assume control of a router, is assumed to be able to effect the 377 types of attacks described below. Note that any router behavior that 378 can be ascribed to a local routing policy decision is not considered 379 to be an attack. This is because such behavior could be explained as 380 a result of local policy settings, and thus is beyond the scope of 381 what PATHSEC can detect as unauthorized behavior. Thus, for example, 382 a router may fail to propagate some or all route withdrawals or 383 effect "route leaks". (These behaviors are not precluded by the 384 specification for BGP, and might be the result of a local policy that 385 is not publicly disclosed. As a result, they are not considered 386 attacks. See Section 5 for additional discussion.) 388 Attacks on a router are equivalent to active wiretapping attacks (in 389 the most general sense) that manipulate (forge, tamper with, or 390 suppress) data contained in BGP updates. The list below illustrates 391 attacks of this type. 393 AS Insertion: A router might insert one or more ASNs, other than 394 its own ASN, into an update message. This violates the BGP spec 395 and thus is considered an attack. 397 False (Route) Origination: A router might originate a route for a 398 prefix, when the AS that the router represents is not authorized 399 to originate routes for that prefix. This is an attack, but it is 400 addressed by the use of the RPKI [RFC6480]. 402 Secure Path Downgrade: A router might remove AS_PATH data from a 403 PATHSEC-protected update that it receives, when forwarding this 404 update to a PATHSEC-enabled neighbor. This behavior violates the 405 PATHSEC security goals and thus is considered an attack. 407 Invalid AS_PATH Data Insertion: A router might emit a PATHSEC- 408 protected update with "bad" data (such as a signature), i.e., 409 PATHSEC data that cannot be validated by other PATHSEC routers. 410 Such behavior is assumed to violate the PATHSEC goals and thus is 411 considered an attack. 413 Stale Path Announcement: If PATHSEC-secured announcements can 414 expire, such an announcement may be propagated with PATHSEC data 415 that is "expired". This behavior would violate the PATHSEC goals 416 and is considered a type of replay attack. 418 Premature Path Announcement Expiration: If a PATHSEC-secured 419 announcement has an associated expiration time, a router might 420 emit a PATHSEC-secured announcement with an expiry time that is 421 very short. Unless the PATHSEC protocol specification mandates a 422 minimum expiry time, this is not an attack. However, if such a 423 time is mandated, this behavior becomes an attack. BGP speakers 424 along a path generally cannot determine if an expiry time is 425 "suspiciously short" since they cannot know how long a route may 426 have been held by an earlier AS, prior to being released. 428 MITM Attack: A cryptographic key used for point-to-point security 429 (e.g., TCP-AO, TLS, or IPsec) between two BGP routers might be 430 compromised (e.g., by extraction from a router). This would 431 enable an adversary to effect MITM attacks on the link(s) where 432 the key is used. Use of specific security mechanisms to protect 433 inter-router links between ASes is outside the scope of PATHSEC. 435 Compromised Router Private Key: If PATHSEC mechanisms employ 436 public key cryptography, e.g., to digitally sign data in an 437 update, then a private key associated with a router or an AS might 438 be compromised by an attack against the router. An adversary with 439 access to this key would be able to generate updates that appear 440 to have passed through the AS that this router represents. Such 441 updates might be in injected on a link between the compromised 442 router and its neighbors, if that link is accessible to the 443 adversary. If the adversary controls another network, it could 444 use this key to forge signatures that appear to come from the AS 445 or router(s) in question, with some constraints. So, for example, 446 an adversary that controls another AS could use a compromised 447 router/AS key to issue PATHSEC-signed data that include the 448 targeted AS/router. (Neighbors of the adversary's AS ought not 449 accept a route that purports to emanate directly from the targeted 450 AS. So, an adversary could take a legitimate, protected route 451 that passes through the compromised AS, add itself as the next 452 hop, and then forward the resulting route to neighbors.) 454 Withdrawal Suppression Attack: A PATHSEC-protected update may be 455 signed and announced, and later withdrawn. An adversary 456 controlling intermediate routers could fail to propagate the 457 withdrawal. BGP is already vulnerable to behavior of this sort, 458 so withdrawal suppression is not characterized as an attack, under 459 the assumptions upon which this mode is based (i.e., no oracle). 461 4.3. Attacks on network operator management computers (non-CA 462 computers) 464 An adversary may choose to attack computers used by a network 465 operator to manage its network, especially its routers. Such attacks 466 might be effected by an adversary who has compromised the security of 467 these computers. This might be effected via remote attacks, 468 extortion of network operations staff, etc. If an adversary 469 compromises NOC computers, he can execute any management function 470 that authorized network operations staff would have performed. Thus 471 the adversary could modify local routing policy to change 472 preferences, to black-hole certain routes, etc. This type of 473 behavior cannot be externally detected as an attack. Externally, 474 this appears as a form of rogue operator behavior. (Such behavior 475 might be perceived as accidental or malicious by other operators.) 477 If a network operator participates in the RPKI, an adversary could 478 manipulate the RP tools that extract data from the RPKI, causing the 479 output of these tools to be corrupted in various ways. For example, 480 an attack of this sort could cause the operator to view valid routes 481 as not validated, which could alter its routing behavior. 483 If an adversary invoked the tool used to manage the repository 484 publication point for this operator, it could delete any objects 485 stored there (certificates, CRLs, manifests, ROAs, or subordinate CA 486 certificates). This could affect the routing status of entities that 487 have allocations/assignments from this network operator (e.g., by 488 deleting their CA certificates). 490 An adversary could invoke the tool used to request certificate 491 revocation, causing router certificates, ROAs, or subordinate CA 492 certificates to be revoked. An attack of this sort could affect not 493 only this operator, but also any operators that receive allocations/ 494 assignments from it, e.g., because their CA certificates were 495 revoked. 497 If an operator is PATHSEC-enabled, an attack of this sort could cause 498 the affected operator to be viewed as not PATHSEC-enabled, possibly 499 making routes it emits be less preferred by other operators. 501 If an adversary invoked a tool used to request ROAs, it could 502 effectively re-allocate some of the prefixes allocated/assigned to 503 the network operator (e.g., by modifying the origin AS in ROAs). 504 This might cause other PATHSEC-enabled networks to view the affected 505 network as no longer originating routes for these prefixes. Multi- 506 homed subscribers of this operator who received an allocation from 507 the operator might find their traffic was now routed via other 508 connections. 510 If the network operator is PATHSEC-enabled, and make use of 511 certificates associated with routers/ASes, an adversary could invoke 512 a tool used to request such certificates. The adversary could then 513 replace valid certificates for routers/ASes with ones that might be 514 rejected by PATHSEC-enabled neighbors. 516 4.4. Attacks on a repository publication point 518 A critical element of the RPKI is the repository system. An 519 adversary might attack a repository, or a publication point within a 520 repository, to adversely affect routing. 522 This section considers only those attacks that can be launched by any 523 adversary who controls a computer hosting one or more repository 524 publication points, without access to the cryptographic keys needed 525 to generate valid RPKI signed products. Such attacks might be 526 effected by an insider or an external threat. Because all repository 527 objects are digitally signed, attacks of this sort translate into DoS 528 attacks against the RPKI RPs. There are a few distinct forms of such 529 attacks, as described below. 531 Note first that the RPKI calls for RPs to cache the data they acquire 532 and verify from the repository system. Attacks that delete signed 533 products, that insert products with "bad" signatures, that tamper 534 with object signatures, or that replace newer objects with older 535 (valid) ones, can be detected by RPs (with a few exceptions). RPs 536 are expected to make use of local caches. If repository publication 537 points are unavailable or the retrieved data is corrupted, an RP can 538 revert to using the cached data. This behavior helps insulate RPs 539 from the immediate effects of DoS attacks on publication points. 541 Each RPKI data object has an associated date at which it expires, or 542 is considered stale. (Certificates expire, CRLs become stale.) When 543 an RP uses cached data it is a local decision how to deal with stale 544 or expired data. It is common in PKIs to make use of stale 545 certificate revocation status data, when fresher data is not 546 available. Use of expired certificates is less common, although not 547 unknown. Each RP will decide, locally, whether to continue to make 548 use of or ignore cached RPKI objects that are stale or expired. 550 If an adversary inserts an object into a publication point, and the 551 object has a "bad" signature, the object will not be accepted and 552 used by RPs. 554 If an adversary modifies any signed product at a publication point, 555 the signature on the product will fail, causing RPs to not accept it. 556 This is equivalent to deleting the object, in many respects. 558 If an adversary deletes one or more CA certificates, ROAs or the CRL 559 for a publication point, the manifest for that publication point will 560 allow an RP to detect this attack. (The RP would be very unhappy if 561 there is no CRL for the CA instance anyway.) An RP can continue to 562 use the last valid instance of the deleted object (as a local policy 563 option), thus minimizing the impact of such an attack. 565 If an adversary deletes a manifest (and does not replace it with an 566 older instance), that is detectable by RPs. Such behavior should 567 result in the CA (or publication point maintainer) being notified of 568 the problem. An RP can continue to use the last valid instance of 569 the deleted manifest (a local policy option), thus minimizing the 570 impact of such an attack. 572 If an adversary deletes newly added CA certificates or ROAs, and 573 replaces the current manifest with the previous manifest, the 574 manifest (and the CRL that it matches) will be "stale" (see 575 [RFC6486]). This alerts an RP that there may be a problem. The RP 576 should use the information from a Ghostbuster record [RFC6493] to 577 contact the entity responsible for the publication point, requesting 578 that entity to remedy the problem (e.g., republish the missing CA 579 certificates and/or ROAs). An RP cannot know the content of the new 580 certificates or ROAs that are not present, but it can continue to use 581 what it has cached. An attack of this sort will, at least 582 temporarily, cause RPs to be unaware of the newly published objects. 583 INRs associated with these objects will be treated as 584 unauthenticated. 586 If a CA revokes a CA certificate or a ROA (via deleting the 587 corresponding EE certificate), and the adversary tries to reinstate 588 that CA certificate or ROA, the adversary would have to rollback the 589 CRL and the manifest to undo this action by the CA. As above, this 590 would make the CRL and manifest stale, and this is detectable by RPs. 591 An RP cannot know which CA certificates or ROAs were deleted. 592 Depending on local policy, the RP might use the cached instances of 593 the affected objects, and thus be tricked into making decisions based 594 on these revoked objects. Here too the goal is that the CA will be 595 notified of the problem (by RPs) and will remedy the error. 597 In the attack scenarios above, when a CRL or manifest is described as 598 stale, this means that the next issue date for the CRL or manifest 599 has passed. Until the next issue date, an RP will not detect the 600 attack. Thus it behooves CAs to select CRL/manifest lifetimes (the 601 two are linked) that represent an acceptable trade-off between risk 602 and operational burdens. 604 Attacks effected by adversaries that are legitimate managers of 605 publication points can have much greater effects, and are discussed 606 below under attacks on or by CAs. 608 4.5. Attacks on an RPKI CA 610 Every entity to which INRs have been allocated/assigned is a CA in 611 the RPKI. Each CA is nominally responsible for managing the 612 repository publication point for the set of signed products that it 613 generates. (An INR holder may choose to outsource the operation of 614 the RPKI CA function, and the associated publication point. In such 615 cases, the organization operating on behalf of the INR holder becomes 616 the CA, from an operational and security perspective. The following 617 discussion does not distinguish such outsourced CA operations.) 619 Note that attacks attributable to a CA may be the result of malice by 620 the CA (i.e., the CA is the adversary) or they may result from a 621 compromise of the CA. 623 All of adversaries listed in Section 2 are presumed to be capable of 624 launching attacks against the computers used to perform CA functions. 625 Some adversaries might effect an attack on a CA by violating 626 personnel or physical security controls as well. The distinction 627 between CA as adversary vs. CA as an attack victim is important. 628 Only in the latter case should one expect the CA to remedy problems 629 caused by a attack once the attack has been detected. (If a CA does 630 not take such action, the effects are the same as if the CA is an 631 adversary.) 633 Note that most of the attacks described below do not require 634 disclosure of a CA's private key to an adversary. If the adversary 635 can gain control of the computer used to issue certificates, it can 636 effect these attacks, even though the private key for the CA remains 637 "secure" (i.e., not disclosed to unauthorized parties). However, if 638 the CA is not the adversary, and if the CA's private key is not 639 compromised, then recovery from these attacks is much easier. This 640 motivates use of hardware security modules to protect CA keys, at 641 least for higher tiers in the RPKI. 643 An attack by a CA can result in revocation or replacement of any of 644 the certificates that the CA has issued. Revocation of a certificate 645 should cause RPs to delete the (formerly) valid certificate (and 646 associated signed object, in the case of a revoked EE certificate) 647 that they have cached. This would cause repository objects (e.g., CA 648 certificates and ROAs) that are verified under that certificate to be 649 considered invalid, transitively. As a result, RPs would not 650 consider as valid any ROAs or PATHSEC-protected updates based on 651 these certificates, which would make routes dependent on them to be 652 less preferred. Because a CA that revokes a certificate is 653 authorized to do so, this sort of attack cannot be detected, 654 intrinsically, by most RPs. However, the entities affected by the 655 revocation or replacement of CA certificates can be expected to 656 detect the attack and contact the CA to effect remediation. If the 657 CA was not the adversary, it should be able to issue new certificates 658 and restore the publication point. 660 An adversary that controls the CA for a publication point can publish 661 signed products that create more subtle types of DoS attacks against 662 RPs. For example, such an attacker could create subordinate CA 663 certificates with Subject Information Access (SIA) pointers that lead 664 RPs on a "wild goose chase" looking for additional publication points 665 and signed products. An attacker could publish certificates with 666 very brief validity intervals, or CRLs and manifests that become 667 "stale" very quickly. This sort of attack would cause RPs to access 668 repositories more frequently, and that might interfere with 669 legitimate accesses by other RPs. 671 An attacker with this capability could create very large numbers of 672 ROAs to be processed (with prefixes that are consistent with the 673 allocation for the CA), and correspondingly large manifests. An 674 attacker could create very deep subtrees with many ROAs per 675 publication point, etc. All of these types of DoS attacks against 676 RPs are feasible within the syntactic and semantic constraints 677 established for RPKI certificates, CRLs, and signed objects. 679 An attack that results in revocation and replacement (e.g., key 680 rollover or certificate renewal) of a CA certificate would cause RPs 681 to replace the old, valid certificate with the new one. This new 682 certificate might contain a public key that does not correspond to 683 the private key held by the certificate subject. That would cause 684 objects signed by that subject to be rejected as invalid, and prevent 685 the affected subject from being able to sign new objects. As above, 686 RPs would not consider as valid any ROAs issued under the affected CA 687 certificate, and updates based on router certificates issued by the 688 affected CA would be rejected. This would make routes dependent on 689 these signed products to be less preferred. However, the constraints 690 imposed by the use of RFC 3779 [RFC3779] extensions do prevent a 691 compromised CA from issuing (valid) certificates with INRs outside 692 the scope of the CA, thus limiting the impact of the attack. 694 An adversary that controls a CA could issue CA certificates with 695 overlapping INRs to different entities, when no transfer of INRs is 696 intended. This could cause confusion for RPs as conflicting ROAs 697 could be issued by the distinct (subordinate) CAs. 699 An adversary could replace a CA certificate, use the corresponding 700 private key to issue new signed products, and then publish them at a 701 publication point controlled by the attacker. This would effectively 702 transfer the affected INRs to the adversary, or to a third party of 703 his choosing. The result would be to cause RPs to view the entity 704 that controls the private key in question as the legitimate INR 705 holder. Again the constraints imposed by the use of RFC 3779 706 extensions prevent a compromised CA from issuing (valid) certificates 707 with INRs outside the scope of the CA, thus limiting the impact of 708 the attack. 710 Finally, an entity that manages a repository publication point can 711 inadvertently act as an attacker (an example of Walt Kelly's most 712 famous "Pogo" quote [Kelly70]). For example, a CA might fail to 713 replace its own certificate in a timely fashion (well before it 714 expires). If might fail to issue its CRL and manifest prior to 715 expiration, creating stale instances of these products that cause 716 concern for RPs. A CA with many subordinate CAs (e.g., an RIR or 717 NIR) might fail to distribute the expiration times for the CA 718 certificates that it issues. A network with many ROAs might do the 719 same for the EE certificates associated with the ROAs it generates. 720 A CA could rollover its key, but fail to reissue subordinate CA 721 certificates under its new key. Poor planning with regard to rekey 722 intervals for managed CAs could impose undue burdens for RPs, despite 723 a lack of malicious intent. All of these example of mismanagement 724 could adversely affect RPs, despite the absence of malicious intent. 726 5. Residual Vulnerabilities 728 The RPKI, upon which PATHSEC relies, has several residual 729 vulnerabilities that were discussed in the preceding text 730 (Section 4.4 and Section 4.5). These vulnerabilities are of two 731 principle forms: 733 o the RPKI repository system may be attacked in ways that make its 734 contents unavailable, not current, or inconsistent. The principle 735 defense against most forms of DoS attacks is the use of a local 736 cache by each RP. The local cache ensures availability of 737 previously-acquired RPKI data, in the event that a repository is 738 inaccessible or if repository contents are deleted (maliciously). 739 Nonetheless, the system cannot ensure that every RP will always 740 have access to up-to-date RPKI data. An RP, when it detects a 741 problem with acquired repository data has two options: 743 1. The RP may choose to make use of its local cache, employing 744 local configuration settings that tolerate expired or stale 745 objects. (Such behavior is, nominally, always within the 746 purview of an RP in PKI.) Using cached, expired or stale data 747 subjects the RP to attacks that take advantage of the RP's 748 ignorance of changes to this data. 750 2. The RP may chose to purge expired objects. Purging expired 751 objects removes the security info associated with the real 752 world INRs to which the objects refer. This is equivalent to 753 the affected INRs not having been afforded protection via the 754 RPKI. Since use of the RPKI (and PATHSEC) is voluntary, there 755 may always be set of INRs that are not protected by these 756 mechanisms. Thus purging moves the affected INRs to the set 757 of non-participating INR holders. This more conservative 758 response enables an attacker to move INRs from the protected 759 to the unprotected set. 761 o any CA in the RPKI may misbehave within the bounds of the INRs 762 allocated to it, e.g., it may issue certificates with duplicate 763 resource allocations or revoke certificates inappropriately. This 764 vulnerability is intrinsic in any PKI, but its impact is limited 765 in the RPKI because of the use of RFC 3779 extensions. It is 766 anticipated that RPs will deal with such misbehavior through 767 administrative means, once it is detected. 769 PATHSEC has a separate set of residual vulnerabilities: 771 o "Route leaks" are viewed as a routing security problem by many 772 operators, even though there is no IETF-codified definition of a 773 route leak. BGP itself does not include semantics that preclude 774 what many perceive as route leaks. Moreover, route leaks are 775 outside the scope of PATHSEC, at this time, based on the SIDR 776 charter. Thus route leaks are not addressed in this threat model. 778 o PATHSEC is not planned to protect all attributes associated with 779 an AS_PATH. Some of these attributes are employed as inputs to 780 routing decisions. Thus attacks that modify (or strip) these 781 other attributes are not prevented/detected by PATHSEC. The SIDR 782 charter calls for protecting only the info needed to verify that a 783 received route traversed the ASes in question, and that the NLRI 784 in the route is what was advertised. Thus, protection of other 785 attributes is outside the scope of the charter, at the time this 786 document was prepared. 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 The author wishes to thank... 817 9. Informative References 819 [I-D.ietf-sidr-rpki-rtr] 820 Bush, R. and R. Austein, "The RPKI/Router Protocol", 821 draft-ietf-sidr-rpki-rtr-26 (work in progress), 822 February 2012. 824 [Kelly70] Kelly, W., "'We Have Met the Enemy, and He is Us': Pogo 825 Earth Day Poster", April 1970. 827 [Kent2000] 828 Kent, S., Lynn, C., and K. Seo, "Design and Analysis of 829 the Secure Border Gateway Protocol (S-BGP)", IEEE DISCEX 830 Conference, June 2000. 832 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 833 Addresses and AS Identifiers", RFC 3779, June 2004. 835 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 836 Protocol 4 (BGP-4)", RFC 4271, January 2006. 838 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 839 RFC 4272, January 2006. 841 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 842 Internet Protocol", RFC 4301, December 2005. 844 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 845 Authentication Option", RFC 5925, June 2010. 847 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 848 Secure Internet Routing", RFC 6480, February 2012. 850 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 851 Origin Authorizations (ROAs)", RFC 6482, February 2012. 853 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 854 "Manifests for the Resource Public Key Infrastructure 855 (RPKI)", RFC 6486, February 2012. 857 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 858 X.509 PKIX Resource Certificates", RFC 6487, 859 February 2012. 861 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object 862 Template for the Resource Public Key Infrastructure 863 (RPKI)", RFC 6488, February 2012. 865 [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) 866 Ghostbusters Record", RFC 6493, February 2012. 868 [Sam04] Samuel, A., "Hacktivism and the Future of Political 869 Participation", Ph.D. dissertation, Harvard University, 870 August 2004. 872 [TCPMD5] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 873 Signature Option", RFC 2385, August 1998. 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 BBN Technologies 887 10 Moulton St. 888 Cambridge, MA 02138 889 US 891 Email: achi@bbn.com