idnits 2.17.1 draft-ietf-rpsec-routing-threats-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 321 has weird spacing: '...against a net...' == Line 322 has weird spacing: '...r as to which...' == Line 323 has weird spacing: '...ssed by other...' == Line 569 has weird spacing: '...eceived route...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 6, 2004) is 7324 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2828 (ref. '1') (Obsoleted by RFC 4949) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 2763 (ref. '6') (Obsoleted by RFC 5301) ** Downref: Normative reference to an Informational RFC: RFC 1721 (ref. '7') Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Barbir 3 Internet-Draft Nortel Networks 4 Expires: October 5, 2004 S. Murphy 5 Sparta, Inc. 6 Y. Yang 7 Cisco Systems 8 April 6, 2004 10 Generic Threats to Routing Protocols 11 draft-ietf-rpsec-routing-threats-05 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at http:// 28 www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on October 5, 2004. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 Routing protocols are subject to attacks that can harm individual 42 users or network operations as a whole. This document provides a 43 description and a summary of generic threats that affect routing 44 protocols in general. This work describes threats, including threat 45 sources and capabilities, threat actions, and threat consequences as 46 well as a breakdown of routing functions that might be separately 47 attacked. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Routing Functions Overview . . . . . . . . . . . . . . . . . . 4 53 3. Generic Routing Protocol Threat Model . . . . . . . . . . . . 5 54 3.1 Threat Definitions . . . . . . . . . . . . . . . . . . . . 5 55 3.1.1 Threat Sources . . . . . . . . . . . . . . . . . . . . 6 56 3.1.2 Threat Consequences . . . . . . . . . . . . . . . . . 6 57 4. Generally Identifiable Routing Threats . . . . . . . . . . . . 11 58 4.1 Deliberate Exposure . . . . . . . . . . . . . . . . . . . 11 59 4.2 Sniffing . . . . . . . . . . . . . . . . . . . . . . . . . 11 60 4.3 Traffic Analysis . . . . . . . . . . . . . . . . . . . . . 12 61 4.4 Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . 12 62 4.5 Falsification . . . . . . . . . . . . . . . . . . . . . . 13 63 4.5.1 Falsifications by Originators . . . . . . . . . . . . 13 64 4.5.2 Falsifications by Forwarders . . . . . . . . . . . . . 16 65 4.6 Interference . . . . . . . . . . . . . . . . . . . . . . . 17 66 4.7 Overload . . . . . . . . . . . . . . . . . . . . . . . . . 17 67 4.8 Byzantine Failures . . . . . . . . . . . . . . . . . . . . 17 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 69 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 70 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 20 71 6.2 Informative References . . . . . . . . . . . . . . . . . . . 20 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 73 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 74 B. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 75 Intellectual Property and Copyright Statements . . . . . . . . 24 77 1. Introduction 79 Routing protocols are subject to threats and attacks that can harm 80 individual users or the network operations as a whole. The document 81 provides a summary of generic threats that affect routing protocols. 82 In particular, this work identifies generic threats to routing 83 protocols that include threat sources, threat actions, and threat 84 consequences. A breakdown of routing functions that might be 85 separately attacked is provided. 87 This work should be considered as a precursor to developing a common 88 set of security requirements for routing protocols. While it is well 89 known that bad, incomplete, or poor implementations of routing 90 protocols may, in themselves, lead to routing problems or failures, 91 or may increase the risk of a network being attacked successfully, 92 these issues are not considered here. This document only considers 93 attacks against robust, well considered implementations of routing 94 protocols, as outlined in OSPF [5], IS-IS [6], RIP [7] and BGP [8]. 96 The document is organized as follows: Section 2 provides a review of 97 routing functions. Section 3 defines threats. In section 4, a 98 discussion on generally identifiable routing threat actions is 99 provided. Section 5 addresses security considerations. 101 2. Routing Functions Overview 103 This section provides an overview of common functions that are shared 104 among various routing protocols. In general, routing protocols share 105 the following functions: 106 o Transport Subsystem: The routing protocol transmits messages to 107 its neighbors using some underlying protocol. For example, OSPF 108 uses IP, while other protocols may run over TCP. 109 o Neighbor State Maintenance: Neighboring relationship formation is 110 the first step for topology determination. For this reason, 111 routing protocols may need to maintain state information. Each 112 routing protocol may use a different mechanism for determining its 113 neighbors in the routing topology. Some protocols have distinct 114 exchanges through which they establish neighboring relationships, 115 e.g., Hello exchanges in OSPF. 116 o Database Maintenance: Routing protocols exchange network topology 117 and reachability information. The routers collect this information 118 in routing databases with varying detail. The maintenance of these 119 databases is a significant portion of the function of a routing 120 protocol. 122 In a routing protocol there are message exchanges that are intended 123 for the control of the state of the protocol. For example, neighbor 124 maintenance messages carry such information. On the other hand, there 125 are messages that are used to exchange information that is intended 126 to be used in the forwarding function. These messages effects the 127 data (information) part of the routing protocol. For example, 128 messages that are used to maintain the database. 130 3. Generic Routing Protocol Threat Model 132 The model developed in this section can be used to identify threats 133 to any routing protocol. It examines attacks which can be launched 134 against routing from subverted entities within the routing system and 135 from entities outside the routing system. Both of these types of 136 entities are called unauthorized entities. 138 Routing protocols are subject to threats at various levels. For 139 example, an attacker may attack messages that carry control 140 information in a routing protocol to break a neighboring (e.g., 141 peering, adjacency) relationship. This type of attack can impact the 142 network routing behavior in the affected routers and likely the 143 surrounding neighborhood. An attacker may attack messages that carry 144 data information to break a database exchange between two routers. An 145 attacker who is able to introduce bogus data can have a strong effect 146 on the behavior of routing in the neighborhood. 148 At the routing function level, threats can affect the transport 149 subsystem, where the routing protocol can be subject to attacks on 150 its underlying protocol. At the neighbor state maintenance level, 151 there are threats that can lead to attacks that can disrupt the 152 neighboring relationship with widespread consequences. For example, 153 in BGP, if a router receives a CEASE message, it can lead to breaking 154 its neighboring relationship to other routers. 156 There are threats against the database maintenance functionality. For 157 example, the information in the database must be authentic and 158 authorized. Threats that jeopardize this information can affect the 159 routing functionality in the overall network. For example, if an OSPF 160 router sends LSAs with the wrong Advertising Router, the receivers 161 will compute an SPF tree that is incorrect and might not forward the 162 traffic. If a BGP router advertises a NLRI that it is not authorized 163 to advertise, then receivers might forward that NLRI's traffic toward 164 that router and the traffic would not be deliverable. A PIM router 165 might transmit a JOIN message to receive multicast data it would 166 otherwise not receive. 168 3.1 Threat Definitions 170 In this work, a threat is defined as a motivated, capable adversary. 171 This characterization of threats clearly distinguishes threats from 172 attacks. By modeling the motivations (attack goals) and capabilities 173 of the adversaries who are threats, one can better understand what 174 classes of attacks these threats may mount and thus what types of 175 countermeasures will be required to deal with these attacks. In [1], 176 a threat is defined as a potential for violation of security, which 177 exists when there is a circumstance, capability, action, or event 178 that could breach security and cause harm. Threats can be categorized 179 based on various rules, such as threat sources, threat actions, 180 threat consequences, threat consequence zones, and threat consequence 181 periods. 183 3.1.1 Threat Sources 185 There are many sources for threats that may affect routing protocols. 186 In some cases, unauthorized entities such as attackers may illegally 187 participate in the routing operations. In other circumstances, there 188 are threats to routing protocols from entities that are running 189 incorrect code, or using invalid configurations. 191 Threats can originate from outsiders or insiders. An insider is an 192 authorized participant in the routing protocol. An outsider is any 193 other host or network. A particular router determines if a host is an 194 outsider or an insider. 196 In general, threats can be classified into the following categories 197 based on their sources [2]: 198 o Threats that result from subverted links: A link becomes subverted 199 when an attacker gains access to (or control) it through a 200 physical medium. The attacker can then take control over the link. 201 This threat can result from the lack (or the use of weak) access 202 control mechanisms as applied to physical mediums or channels. The 203 attacker may eavesdrop, replay, delay, or drop routing messages, 204 or break routing sessions between authorized routers, without 205 participating in the routing exchange. 206 o Threats that result from subverted devices (e.g. routers): A 207 subverted device (router) is an authorized router that may have 208 been broken into by an attacker. The attacker can use the 209 subverted device to inappropriately claim authority for some 210 network resources, or violate routing protocols, such as 211 advertising invalid routing information. 213 3.1.2 Threat Consequences 215 A threat consequence is a security violation that results from a 216 threat action [1]. The compromise to the behavior of the routing 217 system can damage a particular network or host or can damage the 218 operation of the network as a whole. 220 There are four types of threat consequences: disclosure, deception, 221 disruption, and usurpation [1]. 222 o Disclosure: Disclosure of routing information happens when a 223 router successfully accesses the information without being 224 authorized. Subverted links can cause disclosure, if routing 225 exchanges lack confidentiality. Subverted devices (routers), can 226 cause disclosure, as long as they are successfully involved in the 227 routing exchanges. Although inappropriate disclosure of routing 228 information can pose a security threat or be part of a later, 229 larger, or higher layer attack, confidentiality is not generally a 230 design goal of routing protocols. 231 o Deception: This consequence happens when a legitimate router 232 receives a forged routing message and believes it to be authentic. 233 Subverted links and/or subverted devices (routers)can cause this 234 consequence if the receiving router lacks the ability to check 235 routing message integrity or origin authentication. 236 o Disruption: This consequence occurs when a legitimate router's 237 operation is being interrupted or prevented. Subverted links can 238 cause this by replaying, delaying, or dropping routing messages, 239 or breaking routing sessions between legitimate routers. Subverted 240 devices (routers) can cause this consequence by sending false 241 routing messages, interfering with normal routing exchanges, or 242 flooding unnecessary messages. (DoS is a common threat action 243 causing disruption.) 244 o Usurpation: This consequence happens when an attacker gains 245 control over a legitimate router's services/functions. Subverted 246 links can cause this by delaying or dropping routing exchanges, or 247 replaying out-dated routing information. Subverted routers can 248 cause this consequence by sending false routing information or 249 interfering routing exchanges. 251 Note: an attacker does not have to directly control a router to 252 control its services. For example, in Figure 1, Network 1 is 253 dual-homed through Router A and Router B, and Router A is preferred. 254 However, Router B is compromised and advertises a better metric. 255 Consequently, devices on the Internet choose the path through Router 256 B to reach Network 1. In this way, Router B steals the data traffic 257 and Router A surrenders its control of the services to Router B. This 258 depicted in Figure 1. 260 +-------------+ +-------+ 261 | Internet |---| Rtr A | 262 +------+------+ +---+---+ 263 | | 264 | | 265 | | 266 | *-+-* 267 +-------+ / \ 268 | Rtr B |----------* N 1 * 269 +-------+ \ / 270 *---* 272 Figure 1: Dual-homed Network 274 Several threat consequences might be caused by a single threat 275 action. In Figure 1, there exist at least two consequences: routers 276 using Router B to reach Network 1 are deceived, while Router A is 277 usurped. 279 Within the context of the threat consequences described above, damage 280 that might result from attacks against the network as a whole may 281 include: 282 o Network congestion: more data traffic is forwarded through some 283 portion of the network than would otherwise need to carry the 284 traffic, 285 o Blackhole: the consequence is that "packets go in, but go 286 nowhere", 287 o Looping: data traffic is forwarded along a route that loops, so 288 that the data is never delivered (resulting in network 289 congestion), 290 o Partition: some portion of the network believes that it is 291 partitioned from the rest of the network when it is not, 292 o Churn: the forwarding in the network changes (unnecessarily) at a 293 rapid pace, resulting in large variations in the data delivery 294 patterns (and adversely affecting congestion control techniques), 295 o Instability: the protocol becomes unstable so that convergence on 296 a global forwarding state is not achieved, and 297 o Overload: the protocol messages themselves become a significant 298 portion of the traffic the network carries. 300 The damage that might result from attacks against a particular host 301 or network address may include: 302 o Starvation: data traffic destined for the network or host is 303 forwarded to a part of the network that cannot deliver it, 304 o Eavesdrop: data traffic is forwarded through some router or 305 network that would otherwise not see the traffic, affording an 306 opportunity to see the data or at least the data delivery pattern, 307 o Cut: some portion of the network believes that it has no route to 308 the host or network when it is in fact connected, 309 o Delay: data traffic destined for the network or host is forwarded 310 along a route that is in some way inferior to the route it would 311 otherwise take, 312 o Looping: data traffic for the network or host is forwarded along a 313 route that loops, so that the data is never delivered 315 It is important to consider all compromises, because some security 316 solutions can protect against one attack but not against others. It 317 might be possible to design a security solution that protects against 318 an attack that eavesdropped on one destination's traffic without 319 protecting against an attack that overwhelmed a router. Similarly, it 320 is possible to design a security solution that prevents a starvation 321 attack against one host, but not against a network wide resources. 322 The security requirements must be clear as to which compromises are 323 being avoided and which compromises must be addressed by other means 324 (e.g., by administrative means outside the protocol). 326 3.1.2.1 Threat Consequence Zone 328 A threat consequence zone covers the area within which the network 329 operations have been affected by threat actions. Possible threat 330 consequence zones can be classified as: a single link or router, 331 multiple routers (within a single routing domain), a single routing 332 domain, multiple routing domains, or the global Internet. The threat 333 consequence zone varies based on the threat action and origin. 334 Similar threat actions that happened at different locations may cause 335 totally different threat consequence. For example, when a compromised 336 link breaks the routing session between a distribution router and a 337 stub router, only reachability to and from the network devices 338 attached to the stub router will be impaired. In other words, the 339 threat consequence zone is a single router. In another case, if the 340 compromised router is located between a customer edge router and its 341 corresponding provider edge router, such an action might cause the 342 whole customer site to lose its connection. In this case, the threat 343 consequence zone might be a single routing domain. 345 3.1.2.2 Threat Consequence Periods 347 Threat consequence period is defined as a portion of time during 348 which the network operations are been impacted by the threat 349 consequences. The threat consequence period is influenced by, but not 350 totally dependent on the duration of the threat action. In some 351 cases, the network operations will get back to normal as soon as the 352 threat action has been stopped. In other cases, however, threat 353 consequences may persist longer than the threat action. For example, 354 in the original ARPANET link-state algorithm, some errors in a router 355 introduced three instances of an LSA. All of them flooded throughout 356 the network continuously, until the entire network was power cycled 357 [3]. 359 4. Generally Identifiable Routing Threats 361 This section addresses generally identifiable and recognized threat 362 actions against routing protocols. The threat actions are not 363 necessarily specific to individual protocols but may be present in 364 one or more of the common routing protocols in use today. 366 4.1 Deliberate Exposure 368 Deliberate Exposure occurs when an attacker takes control of a router 369 and intentionally releases routing information directly to devices 370 that, otherwise, should not receive the exposed information. In some 371 cases, the receiving devices (e.g. routers) may not be authorized to 372 access the leaked routing information. Deliberate exposure is always 373 a threat action; however, the exposure of routing information may not 374 be. 376 The consequence of deliberate exposure is the disclosure of routing 377 information. 379 The threat consequence zone of deliberate exposure depends on the 380 routing information that the attackers have exposed. The more 381 knowledge they have exposed, the bigger the threat consequence zone. 383 The threat consequence period of deliberate exposure might be longer 384 than the duration of the action itself. The routing information 385 exposed will not be out-dated until there is a topology change of the 386 exposed network. 388 4.2 Sniffing 390 Sniffing is an action whereby attackers monitor and/or record the 391 routing exchanges between authorized routers. Attackers can use 392 subverted links to sniff for routing information. Attackers can also 393 sniff data plane information (however, this is out of scope of the 394 current work). 396 The consequence of sniffing is disclosure of routing information. 398 The threat consequence zone of sniffing depends on the attacker's 399 location, the routing protocol type, and the routing information that 400 has been recorded. For example, if the subverted link is in an OSPF 401 totally stubby area, the threat consequence zone should be limited to 402 the whole area. An attacker that is sniffing a subverted link in an 403 EBGP session can gain knowledge of multiple routing domains. 405 The threat consequence period might be longer than the duration of 406 the action. If an attacker stops sniffing a subverted link their 407 acquired knowledge will not be out-dated until there is a topology 408 change of the affected network. 410 4.3 Traffic Analysis 412 Traffic analysis is an action whereby attackers gain routing 413 information by analyzing the characteristics of the data traffic on a 414 subverted link. Traffic analysis threats can affect any data that is 415 sent over a communication link. This threat is not peculiar to 416 routing protocols and is included here for completeness. 418 The consequence of data traffic analysis is the disclosure of routing 419 information. For example, the source and destination IP addresses of 420 the data traffic, and the type, magnitude, and volume of traffic can 421 be disclosed. 423 The threat consequence zone of the traffic analysis depends on the 424 attacker's location and what data traffic has passed through. A 425 subverted link at the network core should be able to disclose more 426 information than its counterpart at the edge. 428 The threat consequence period might be longer than the duration of 429 the traffic analysis. After the attacker stops traffic analysis, its 430 knowledge will not be out-dated until there is a topology change of 431 the disclosed network. 433 4.4 Spoofing 435 Spoofing occurs when an illegitimate device assumes the identity of a 436 legitimate one. Spoofing in and of itself is often not the true 437 attack. Spoofing is special in that it can be used to carry out other 438 threat actions causing other threat consequences. An attacker can use 439 spoofing as a means for launching other types of attacks. For 440 example, if an attacker succeeds in spoofing the identity of a 441 router, the attacker can act as a masquerading router. In other 442 situations, the spoofing router can be used to send out unrealistic 443 routing information that might cause the disruption of network 444 services. 446 There are a few cases where spoofing can be an attack in and of 447 itself. For example, messages from an attacker which spoof the 448 identity of a legitimate router may cause a neighbor relationship to 449 form and deny the formation of the relationship with the legitimate 450 router. 452 The consequences of spoofing are: 453 o The disclosure of routing information: The spoofing router will be 454 able to gain access to the routing information. 456 o The deception of peer relationship: The authorized routers, which 457 exchange routing messages with the spoofing router, do not realize 458 they are neighboring with a router that is faking another router's 459 identity. 461 The threat consequence zone covers: 462 o The consequence zone of the fake peer relationship will be limited 463 to those routers trusting the attacker's claimed identity. 464 o The consequence zone of the disclosed routing information depends 465 on the attacker's location, the routing protocol type, and the 466 routing information that has been exchanged between the attacker 467 and its deceived neighbors. 469 Note: This section focuses on addressing spoofing as a threat on its 470 own. However, spoofing creates conditions for other threats. Other 471 consequences are considered falsifications and are treated in the 472 next section. 474 4.5 Falsification 476 Falsification is an intentional action whereby false routing 477 information is sent by a subverted router. To falsify the routing 478 information, an attacker has to be either the originator or a 479 forwarder of the routing information. It cannot be a receiver-only. 480 False routing information describes the network in an unrealistic 481 fashion, whether or not intended by the authoritative network 482 administrator. 484 4.5.1 Falsifications by Originators 486 An originator of routing information can launch the falsifications 487 that are described in the next sections. 489 4.5.1.1 Overclaiming 491 Overclaiming occurs when a subverted router advertises its control of 492 some network resources, while in reality it does not, or the 493 advertisement is not authorized. This is given in Figure 2 and Figure 494 3. 496 +-------------+ +-------+ +-------+ 497 | Internet |---| Rtr B |---| Rtr A | 498 +------+------+ +-------+ +---+---+ 499 | . 500 | | 501 | . 502 | *-+-* 503 +-------+ / \ 504 | Rtr C |------------------* N 1 * 505 +-------+ \ / 506 *---* 508 Figure 2: Overclaiming-1 510 +-------------+ +-------+ +-------+ 511 | Internet |---| Rtr B |---| Rtr A | 512 +------+------+ +-------+ +-------+ 513 | 514 | 515 | 516 | *---* 517 +-------+ / \ 518 | Rtr C |------------------* N 1 * 519 +-------+ \ / 520 *---* 522 Figure 3: Overclaiming-2 524 The above figures provide examples of overclaiming. Router A, the 525 attacker, is connected to the Internet through Router B. Router C is 526 authorized to advertise its link to Network 1. In Figure 2, Router A 527 controls a link to Network 1, but is not authorized to advertise it. 528 In Figure 3, Router A does not control such a link. But in either 529 case, Router A advertises the link to the Internet, through Router B. 531 Compromised routers, unauthorized routers, and masquerading routers 532 can overclaim network resources. The consequence of overclaiming 533 includes: 534 o Usurpation of the overclaimed network resources. In Figure 2 and 535 Figure 3, usurpation of Network 1 can occur when Router B (or 536 other routers on the Internet, (not shown in the figures)) 537 believes that Router A provides the best path to reach the Network 538 1. As a result, routers forward data traffic, destined to Network 539 1 to Router A. The best result is that the data traffic uses an 540 unauthorized path, as in Figure 2. The worst case is that the data 541 never reaches the destination Network 1, as in Figure 3. The 542 ultimate consequence is Router A gaining control over Network 1's 543 services, by controlling the data traffic. 544 o Usurpation of the legitimate advertising routers. In Figure 2 and 545 Figure 3 Router C is the legitimate advertiser of Network 1. By 546 overclaiming, Router A also controls (partially or totally) the 547 services/functions provided by the Router C. (This is NOT a 548 disruption, because Router C is operating in a way intended by the 549 authoritative network administrator.) 550 o Deception of other routers. In Figure 2 and Figure 3, Router B, or 551 other routers on the Internet, might be deceived to believe the 552 path through Router A is the best. 553 o Disruption of data planes on some routers. This might happen to 554 routers that are on the path that is used by other routers to each 555 the overclaimed network resources through the attacker. In Figure 556 2 and Figure 3, when other routers on the Internet are deceived, 557 they will forward the data traffic to Router B, which might be 558 overloaded. 560 The threat consequence zone varies based on the consequence: 561 o Where usurpation is concerned, the consequence zone covers the 562 network resources that are overclaimed by the attacker (Network 1 563 in Figure 2 and 3), and the routers that are authorized to 564 advertise the network resources but lose the competition against 565 the attacker(Router C in Figure 2 and Figure 3). 566 o Where deception is concerned, the consequence zone covers the 567 routers that do believe the attacker's advertisement and use the 568 attacker to reach the claimed networks (Router B and other 569 deceived routers on the Internet in Figure 2 and Figure 3). 570 o Where disruption is concerned, the consequence zone includes the 571 routers that are on the path of misdirected data traffic (Router B 572 in Figure 2 and Figure 3). 574 The threat consequence will cease when the attacker stops 575 overclaiming, and will totally disappear when the routing tables are 576 converged. As a result the consequence period is longer than the 577 duration of the overclaiming. 579 4.5.1.2 Misclaiming 581 A misclaiming threat is defined as an action where an attacker is 582 advertising its authorized control of some network resources in a way 583 that is not intended by the authoritative network administrator. An 584 attacker can eulogize or disparage when advertising these network 585 resources. Subverted routers, unauthorized routers, and masquerading 586 routers can misclaim network resources. 588 The threat consequences of misclaiming are similar to the 589 consequences of overclaiming. 591 The consequence zone and period are also similar to those of 592 overclaiming. 594 4.5.2 Falsifications by Forwarders 596 When a legitimate router forwards routing information, it must or 597 must not modify the routing information, depending on the routing 598 information and the routing protocol type. For example, in RIP, the 599 forwarder must modify the routing information by increasing the hop 600 count by 1. On the other hand, the forwarder must not modify the type 601 1 LSA in OSPF. In general, forwarders in distance vector routing 602 protocols are authorized to and must modify the routing information, 603 while most forwarders in link state routing protocols are not 604 authorized to and must not modify most routing information. 606 As a forwarder authorized to modify routing message, an attacker 607 might not forward necessary routing information to other authorized 608 routers. 610 4.5.2.1 Misstatement 612 This is defined as an action whereby the attacker describes route 613 attributes in an incorrect manner. For example, in RIP, the attacker 614 might increase the path cost by two hops instead of one. In BGP, the 615 attacker might delete some AS numbers from the AS PATH. 617 Where forwarding routing information should not be modified, an 618 attacker can launch the following falsifications: 619 o Deletion: Attacker deletes valid data in the routing message. 620 o Insertion: Attacker inserts false data in the routing message. 621 o Substitution: Attacker replaces valid data in the routing message 622 with false data. 623 o Replaying: Attacker replays out-dated data in the routing message. 625 All types of attackers (compromised links, compromised routers, 626 unauthorized routers, and masquerading routers) can falsify the 627 routing information when they forward the routing messages. 629 The threat consequences of these falsifications by forwarders are 630 similar to those caused by originators: usurpation of some network 631 resources and related routers; deception of routers using false 632 paths; and disruption of data planes of routers on the false paths. 633 The threat consequence zone and period are also similar. 635 4.6 Interference 637 Interference is a threat action where an attacker uses a subverted 638 link or router to inhibit the exchanges by legitimate routers. The 639 attacker can do this by adding noise, or by not forwarding packets, 640 or by replaying out-dated packets, or by delaying responses, or by 641 denial of receipts, or by breaking synchronization. 643 Subverted, unauthorized and masquerading routers can slow down their 644 routing exchanges or induce flapping in the routing sessions of 645 legitimate neighboring routers. 647 The consequence of interference is the disruption of routing 648 operations. 650 The consequence zone of interference varies based on the source of 651 the threats: 652 o When a subverted link is used to launch the action, the threat 653 consequence zone covers routers that are using the link to 654 exchange the routing information. An attack on a link can cause 655 consequences at the neighbor maintenance level that may lead to 656 changes in the database. In this case, the consequences can be 657 felt network-wide. 658 o When subverted routers, unauthorized routers, or masquerading 659 routers are the attackers, the threat consequence zone covers 660 routers with which the attackers are exchanging routing 661 information. 663 The threat consequences might disappear as soon as the interference 664 is stopped, or might not totally disappear until the networks have 665 converged. Therefore, the consequence period is equal or longer than 666 the duration of the interference. 668 4.7 Overload 670 Overload is defined as a threat action whereby attackers place excess 671 burden on legitimate routers. For example, it is possible for an 672 attacker to trigger a router to create an excessive amount of state 673 that other routers within the network are not able to handle. In a 674 similar fashion, it is possible for an attacker to overload database 675 routing exchanges and thus influence the routing operations. 677 4.8 Byzantine Failures 679 As described in [4], "A node with a Byzantine failure may corrupt 680 messages, forge messages, delay messages, or send conflicting 681 messages to different nodes". These faults may arise from routers 682 which have been subverted by an attacker or which have faulty 683 hardware or software. In any case, they represent a threat to correct 684 operation of routing and routing protocols. 686 The ability of the network to function in the face of such defects is 687 described as Byzantine robustness and would fall into the scope of a 688 requirements document for routing protocol security which may build 689 from the base established in this document. 691 5. Security Considerations 693 This entire document is security related. Specifically the document 694 addresses security of routing protocols as associated with threats to 695 those protocols. In a larger context, this work builds upon the 696 recognition of the IETF community that signaling and control/ 697 management planes of networked devices need strengthening. Routing 698 protocols can be considered part of that signaling and control plane. 699 However, to date, routing protocols have largely remained unprotected 700 and open to malicious attacks. This document discusses inter- and 701 intra-domain routing protocol threats that are currently known and 702 lays the foundation for other documents that will discuss security 703 requirements for routing protocols. This document is protocol 704 independent. 706 6. References 708 6.1 Normative References 710 [1] Shirey, R, "Internet Security Glossary", RFC 2828 , May 2000. 712 [2] Smith, B et al., "Securing Distance-Vector Routing Protocols", 713 Symposium on Network and Distributed System Security , February 714 1997. 716 [3] Rosen, E., "Vulnerabilities of Network Control Protocols: An 717 Example, Computer Communication Review", , July 1981. 719 [4] Perlman, R, "Network Layer Protocols with Byzantine Robustness", 720 , August 1988 . 722 [5] Moy, J, "OSPF Version 2", RFC 2328, April 1998. 724 [6] Shen, N. et. al., "Dynamic Hostname Exchange Mechanism for 725 IS-IS", RFC 2763 , February 2000. 727 [7] Malkin, G., "RIP Version 2 Protocol Analysis", RFC 1721 , 728 November 1994. 730 6.2 Informative References 732 [8] Kent, S. et al., "Secure Border Gateway Protocol 733 (Secure-BGP)", IEEE Journal on Selected Areas in Communications 734 , April 2000. 736 Authors' Addresses 738 Abbie Barbir 739 Nortel Networks 740 3500 Carling Avenue 741 Nepean, Ontario K2H 8E9 742 Canada 744 Phone: 745 EMail: abbieb@nortelnetworks.com 746 Sandy Murphy 747 Sparta, Inc. 748 7075 Samuel Morse Drive 749 Columbia, MD 750 USA 752 Phone: 410-872-1515 x206 753 EMail: sandy@tislabs.com 755 Yi Yang 756 Cisco Systems 757 7025 Kit Creek Road 758 RTP, NC 27709 759 USA 761 Phone: 762 EMail: yiya@cisco.com 764 Appendix A. Acknowledgments 766 This draft would not have been possible save for the excellent 767 efforts and team work characteristics of those listed here. 768 o Dennis Beard- Nortel Networks 769 o Ayman Musharbash - Nortel Networks 770 o Jean-Jacques Puig, int-evry, France 771 o Paul Knight - Nortel Networks 772 o Elwyn Davies - Nortel Networks 773 o Ameya Dilip Pandit - Graduate student - University of Missouri 774 o Senthilkumar Ayyasamy - Graduate student - University of Missouri 775 o Stephen Kent- BBN 776 o Tim Gage - CISCO 777 o James Ng - CISCO 778 o Alvaro Retana - CISCO 780 Appendix B. Acronyms 782 AS - Autonomous system. Set of routers under a single technical 783 administration. Each AS normally uses a single interior gateway 784 protocol (IGP) and metrics to propagate routing information within 785 the set of routers. Also called routing domain. 787 AS-Path - In BGP, the route to a destination. The path consists of 788 the AS numbers of all routers a packet must go through to reach a 789 destination. 791 BGP - Border Gateway Protocol. Exterior gateway protocol used to 792 exchange routing information among routers in different autonomous 793 systems. 795 LSA - Link-State Announcement 797 NLRI - Network layer reachability information. Information that is 798 carried in BGP packets and is used by MBGP. 800 OSPF - Open Shortest Path First. A link-state IGP that makes routing 801 decisions based on the shortest-path-first (SPF) algorithm (also 802 referred to as the Dijkstra algorithm). 804 Intellectual Property Statement 806 The IETF takes no position regarding the validity or scope of any 807 intellectual property or other rights that might be claimed to 808 pertain to the implementation or use of the technology described in 809 this document or the extent to which any license under such rights 810 might or might not be available; neither does it represent that it 811 has made any effort to identify any such rights. Information on the 812 IETF's procedures with respect to rights in standards-track and 813 standards-related documentation can be found in BCP-11. Copies of 814 claims of rights made available for publication and any assurances of 815 licenses to be made available, or the result of an attempt made to 816 obtain a general license or permission for the use of such 817 proprietary rights by implementors or users of this specification can 818 be obtained from the IETF Secretariat. 820 The IETF invites any interested party to bring to its attention any 821 copyrights, patents or patent applications, or other proprietary 822 rights which may cover technology that may be required to practice 823 this standard. Please address the information to the IETF Executive 824 Director. 826 Full Copyright Statement 828 Copyright (C) The Internet Society (2004). All Rights Reserved. 830 This document and translations of it may be copied and furnished to 831 others, and derivative works that comment on or otherwise explain it 832 or assist in its implementation may be prepared, copied, published 833 and distributed, in whole or in part, without restriction of any 834 kind, provided that the above copyright notice and this paragraph are 835 included on all such copies and derivative works. However, this 836 document itself may not be modified in any way, such as by removing 837 the copyright notice or references to the Internet Society or other 838 Internet organizations, except as needed for the purpose of 839 developing Internet standards in which case the procedures for 840 copyrights defined in the Internet Standards process must be 841 followed, or as required to translate it into languages other than 842 English. 844 The limited permissions granted above are perpetual and will not be 845 revoked by the Internet Society or its successors or assignees. 847 This document and the information contained herein is provided on an 848 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 849 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 850 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 851 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 852 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 854 Acknowledgment 856 Funding for the RFC Editor function is currently provided by the 857 Internet Society.