idnits 2.17.1 draft-ietf-rpsec-routing-threats-01.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.) ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 268 has weird spacing: '...ability to ch...' == Line 440 has weird spacing: '...d links to sn...' == Line 470 has weird spacing: '...ion and what ...' == Line 823 has weird spacing: '...ference on Co...' == Line 828 has weird spacing: '...eedings of th...' -- 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 2003) is 7681 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) == Unused Reference: '4' is defined on line 813, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 816, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 819, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 821, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 826, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 831, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 836, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 840, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 842, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 845, but no explicit reference was found in the text ** 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' ** Downref: Normative reference to an Experimental RFC: RFC 2154 (ref. '5') -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Obsolete informational reference (is this intentional?): RFC 2362 (ref. '12') (Obsoleted by RFC 4601, RFC 5059) Summary: 5 errors (**), 0 flaws (~~), 17 warnings (==), 9 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: September 30, 2003 S. Murphy 5 Network Associates, Inc 6 Y. Yang 7 Cisco Systems 8 April 2003 10 Generic Threats to Routing Protocols 11 draft-ietf-rpsec-routing-threats-01 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 September 30, 2003. 35 Copyright Notice 37 Copyright (C) The Internet Society (2003). All Rights Reserved. 39 Abstract 41 Routing protocols are subject to attacks that can harm individual 42 users or the network operations as a whole. This document provides a 43 description and a summary of generic threats that affects routing 44 protocols in general. The 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 2.1 Routing Protocol Control and Data Planes . . . . . . . . . . 4 54 3. Generic Routing Protocol Threat Model . . . . . . . . . . . 5 55 3.1 Threat Definitions . . . . . . . . . . . . . . . . . . . . . 5 56 3.1.1 Threat Sources . . . . . . . . . . . . . . . . . . . . . . . 6 57 3.1.2 Threat Consequences . . . . . . . . . . . . . . . . . . . . 7 58 4. Generally Identifiable Routing Threats . . . . . . . . . . . 11 59 4.1 Deliberate Exposure . . . . . . . . . . . . . . . . . . . . 11 60 4.2 Sniffing . . . . . . . . . . . . . . . . . . . . . . . . . . 11 61 4.3 Traffic Analysis . . . . . . . . . . . . . . . . . . . . . . 12 62 4.4 Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . . 12 63 4.5 Falsification . . . . . . . . . . . . . . . . . . . . . . . 13 64 4.5.1 Falsifications by Originators . . . . . . . . . . . . . . . 13 65 4.5.2 Falsifications by Forwarders . . . . . . . . . . . . . . . . 16 66 4.6 Interference . . . . . . . . . . . . . . . . . . . . . . . . 17 67 4.7 Overload . . . . . . . . . . . . . . . . . . . . . . . . . . 18 68 4.8 Byzantine Failures . . . . . . . . . . . . . . . . . . . . . 18 69 4.9 Discarding of Control Packets . . . . . . . . . . . . . . . 18 70 4.10 Network Mapping Threats . . . . . . . . . . . . . . . . . . 18 71 4.11 DoS and DDoS Attacks . . . . . . . . . . . . . . . . . . . . 19 72 5. Security Considerations . . . . . . . . . . . . . . . . . . 20 73 Normative References . . . . . . . . . . . . . . . . . . . . 21 74 Informative References . . . . . . . . . . . . . . . . . . . 22 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 22 76 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 77 B. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 24 78 Intellectual Property and Copyright Statements . . . . . . . 25 80 1. Introduction 82 Routing protocols are subject to threats and attacks that can harm 83 individual users or the network operations as a whole. The document 84 provides a summary of generic threats that affects routing protocols. 85 In particular, the work identifies generic threats to routing 86 protocols that include threat sources, threat actions, and threat 87 consequences. A breakdown of routing functions that might be 88 separately attacked is provided. 90 The work should be considered as a precursor to developing a common 91 set of security requirements for routing protocols. For this reason, 92 the document does not address threats to routers such as hacking, 93 denial of service, flooding attacks and others. The document does not 94 consider threats that result from bad implementations that are 95 related to specific routing. The security requirements derived from 96 this threat analysis are intended to be used as guidance to those who 97 are designing routing protocols. 99 The document is organized as follows: Section 2 provides a review of 100 routing functions. Section 3 defines threats. In section 4 a 101 discussion on generally identifiable routing threats actions is 102 provided. Section 5 addresses security considerations. 104 2. Routing Functions Overview 106 This section provides an overview of common functions that are shared 107 among various routing protocols. In general, routing protocols share 108 the following common functions: 110 o Transport Subsystem: The routing protocol transmits messages to 111 its peers using some underlying protocol. For example, OSPF uses 112 IP, while AODV uses a broadcast link. Other protocols may run over 113 TCP. 115 o Neighbor State Maintenance: Peering relationship formation is the 116 first step for topology determination. For this reason, routing 117 protocols may need to maintain the state of their neighbors. Each 118 routing protocol may use a different mechanism for determining its 119 peers in the routing topology. Some protocols have distinct 120 exchange through which they establish peering relationships, e.g., 121 Hello exchanges in OSPF. 123 o Database Maintenance: Routing protocols exchange network topology 124 and reach-ability information. The routers collect this 125 information in routing databases with varying detail. The 126 maintenance of these databases is a significant portion of the 127 function of a routing protocol. 129 2.1 Routing Protocol Control and Data Planes 131 A router's functions can be divided into control and data plane 132 (protocol traffic vs. data traffic). In a similar fashion, a routing 133 protocol has a control and a data plane. A routing protocol has a 134 control plane that exchanges messages that are intended only for 135 control of the protocol state. 137 Routing protocol data plane uses messages to exchange information 138 that is intended to be used in the forwarding function. For example, 139 the information can be used to establish a forwarding table in each 140 router or to return a description of the route to be used. 142 Routing functions may affect the control and the data planes. 143 However, there may be an emphasis on one of the planes as opposed to 144 the other. For example, neighbor maintenance is likely to focus on 145 the routing protocol control plane, while database maintenance may 146 focus on the data plane. 148 3. Generic Routing Protocol Threat Model 150 This section develops a model that can be used to identify the 151 threats that can affect routing protocols in general. The model 152 examines the possible threats that routing protocols can be exposed 153 to from unauthorized entities. 155 Routing protocols are subject to treats at the control and data 156 planes and at the functional level. At the control plane level, 157 control and data plane are subject to attack. An attacker may be able 158 to break a neighbor (e.g., peering, adjacency) relationship. This 159 type of attack can impact the network routing behavior in the 160 affected routers and likely the surrounding neighborhood. An 161 attacker who is able to break a database exchange between two routers 162 can also affect routing behavior. In the routing protocol data 163 plane, an attacker who is able to introduce bogus data can have a 164 strong effect on the behavior of routing in the neighborhood. 166 At the routing function level threats can affect the transport 167 subsystem, where the routing protocol can be subject to attacks on 168 its underlying protocol. At the neighbor state maintenance level, 169 there are threats that can lead to attacks that can disrupt the 170 peering relationship with widespread consequences. For example, if 171 the DR election is disrupted in an OSPF network, an unauthorized 172 router could be chosen as designated router. This might allow 173 unauthorized access to routing information. In BGP, if a router 174 receives a CEASE message, it can break the peering relationship and 175 cause any related topology information to be flushed. 177 There are threats against the database maintenance functionality. For 178 example, the information in the database must be authentic and 179 authorized. Threats that jeopardize this information can affect the 180 routing functionality in the overall network. For example, if an 181 OSPF router sends LSA's with the wrong Advertising Router, the 182 receivers will compute a SPF tree that is incorrect and might not 183 forward the traffic. If a BGP router advertises a NLRI that it is 184 not authorized to advertise, then receivers might forward that NLRI's 185 traffic toward that router and the traffic would not be deliverable. 186 A PIM router might transmit a JOIN message to receive multicast data 187 it would otherwise not receive 189 3.1 Threat Definitions 191 Threat is defined in [1] as a potential for violation of security, 192 which exists when there is a circumstance, capability, action, or 193 event that could breach security and cause harm. A threat presents 194 itself when an attacker has the ability to take advantage of an 195 existing security weakness. Threats can be categorized based on 196 various rules, such as threat sources, threat actions, threat 197 consequences, threat consequence zones, and threat consequence 198 periods. 200 3.1.1 Threat Sources 202 There are many sources for threats that may affect routing protocols. 203 In some cases, unauthorized entities such as attackers may illegally 204 participate in the routing operations. In other circumstances, there 205 are threats to routing protocols from entities that are running 206 incorrect code, or using invalid configurations. 208 Threats can originate form outsiders or insiders. An insider is an 209 authorized participant in the routing protocol. An outsider is any 210 other host or network. A host is determined to be an outsider or an 211 insider from the point of view of a particular router. Even an 212 authorized protocol speaker can be an outsider to a particular router 213 if the router does not consider the speaker to be a legitimate peer 214 (as could conceivably happen on a multi-access link). 216 In general, threats can be classified into the following categories 217 based on their sources [2]: 219 o Threats that result from subverted links: A link become subverted 220 when an attacker gain access (or control) to it through a physical 221 medium. The attacker can then take control over the link. This 222 threat can result from the lack (or the use of weak) access 223 control mechanisms as applied to physical mediums or channels. The 224 attacker may eavesdrop, replay, delay, or drop routing messages, 225 or break routing sessions between authorized routers, without 226 participating in the routing exchange. 228 o Threats that result from subverted devices (e.g. routers): A 229 subverted device (router) is an authorized router that may have 230 routing software bugs, hardware defects, incorrect or unintended 231 configurations. Devices can be susceptible to such threats due to 232 the lack mechanisms to verify system integrity (For example, the 233 router is working correctly as been intended by the authoritative 234 network administrator), or such mechanisms can be circumvented. 235 Such threats may enable attackers to inappropriately claim 236 authority for some network resources, or violate routing 237 protocols, such as advertising invalid routing information. 239 For some protocols there is no notion of an authorized peer or 240 neighbor. For example, in OSPF (that is, before the MD5 part was 241 added), OSPF speaks to all routers on the local link that answer to 242 the AllSPFRouters multicast address. Furthermore, MANET protocols 243 frequently speak over the broadcast link. 245 3.1.2 Threat Consequences 247 A threat consequence is a security violation that results from a 248 threat action [1]. The compromise to the behavior of the routing 249 system can damage a particular network or host or can damage the 250 operation of the network as a whole. 252 There are four types of threat consequences: disclosure, deception, 253 disruption, and usurpation [1]. 255 o Disclosure: Disclosure of routing information happens when a 256 router successfully accesses the information without being 257 authorized. Subverted links can cause disclosure, if routing 258 exchanges lack confidentiality. Subverted devices (routers), can 259 cause disclosure, as long as they are successfully involved in the 260 routing exchanges. Although inappropriate disclosure of routing 261 information can pose a security threat or be part of a later, 262 larger, or higher layer attack, confidentiality is not generally a 263 design goal of routing protocols. 265 o Deception: This consequence happens when a legitimate router 266 receives a false routing message and believes it to be true. 267 Subverted links and/or subverted device (routers)can cause this 268 consequence if the receiving router lacks ability to check 269 routing message integrity, routing message origin, authentication 270 or peer router authentication. 272 o Disruption: This consequence occurs when a legitimate router's 273 operation is being interrupted or prevented. Subvert links can 274 cause this by replaying, delaying, or dropping routing messages, 275 or breaking routing sessions between legitimate routers. Subverted 276 devices (router) can cause this consequence by sending false 277 routing messages, interfering normal routing exchanges, or 278 flooding unnecessary messages. (DoS is a common threat action 279 causing disruption.) 281 o Usurpation: This consequence happens when an attacker gains 282 control over a legitimate router's services/functions. Subverted 283 links can cause this by delaying or dropping routing exchanges, or 284 replaying out-dated routing information. Subverted routers can 285 cause this consequence by sending false routing information, 286 interfering routing exchanges, or system integrity. 288 Note: an attacker does not have to directly control a router to 289 control its services. For example, in Figure 1, Network 1 is 290 dual-homed through Router A and Router B, and Router A is preferred. 291 However, Router B is compromised and advertises a lower metric. 292 Consequently, devices on the Internet choose the path through Router 293 B to reach Network 1. In this way, Router B steals the data traffic 294 and Router A surrenders its control of the services to Router B. This 295 depicted in Figure 1. 297 +-------------+ +-------+ 298 | Internet |---| Rtr A | 299 +------+------+ +---+---+ 300 | | 301 | | 302 | | 303 | *-+-* 304 +-------+ / \ 305 | Rtr B |------* N 1 * 306 +-------+ \ / 307 *---* 309 Figure 1: Figure 1 311 Several threat consequences might be caused by a single threat 312 action. In Figure 1, there exist at least two consequences: routers 313 using Router B to reach Network 1 are deceived, while Router A is 314 usurped. 316 Within the context of the threat consequences described above, damage 317 that might result from attacks against the network as a whole may 318 include: 320 o Network congestion: more data traffic is forwarded through some 321 portion of the network than would otherwise need to carry the 322 traffic, 324 o Blackhole: large amounts of traffic are directed to be forwarded 325 through one router that cannot handle the increased level of 326 traffic and drops many/most/all packets, 328 o Looping: data traffic is forwarded along a route that loops, so 329 that the data is never delivered (resulting in network 330 congestion), 332 o Partition: some portion of the network believes that it is 333 partitioned from the rest of the network when it is not, 335 o Churn: the forwarding in the network changes (unnecessarily) at a 336 rapid pace, resulting in large variations in the data delivery 337 patterns (and adversely affecting congestion control techniques), 339 o Instability: the protocol becomes unstable so that convergence on 340 a global forwarding state is not achieved, and 342 o Overload: the protocol messages themselves become a significant 343 portion of the traffic the network carries. 345 The damage that might result from attacks against a particular host 346 or network address may include: 348 o Starvation: data traffic destined for the network or host is 349 forwarded to a part of the network that cannot deliver it, 351 o Eavesdrop: data traffic is forwarded through some router or 352 network that would otherwise not see the traffic, affording an 353 opportunity to see the data or at least the data delivery pattern, 355 o Cut: some portion of the network believes that it has no route to 356 the host or network when it is in fact connected, 358 o Delay: data traffic destined for the network or host is forwarded 359 along a route that is in some way inferior to the route it would 360 otherwise take, 362 o Looping: data traffic for the network or host is forwarded along a 363 route that loops, so that the data is never delivered 365 It is important to consider all compromises, because some security 366 solutions can protect against one attack but not against others. It 367 might be possible to design a security solution that protected 368 against an attack that eavesdropped on one destination's traffic 369 without protecting against an attack that overwhelmed a router. Or 370 that prevented a starvation attack against one host, but not against 371 a net wide blackhole. The security requirements must be clear as to 372 which compromises are being avoided and which must be addressed by 373 other means (e.g., by administrative means outside the protocol). 375 3.1.2.1 Threat Consequence Zone 377 A threat consequence zone covers an area within which the network 378 operations have been affected by the threat consequences. Possible 379 threat consequence zones can be classified as: a single link or 380 router, multiple routers (within a single routing domain), a single 381 routing domain, multiple routing domains, or the global Internet. The 382 threat consequence zone varies based on the threat action and origin. 383 Similar threat actions that happened at different locations may cause 384 totally different threat consequence zones. For example, when a 385 compromised link breaks the routing session between a distribution 386 router and a stub router, only reach ability from and to the network 387 devices attached on the stub router will be impaired. In other words, 388 the threat consequence zone is a single router. Nonetheless, if the 389 compromised router is located between a customer edge router and its 390 corresponding provider edge router, such an action might cause the 391 whole customer site to lose its connection. In this case, the threat 392 consequence zone might be a single routing domain. 394 3.1.2.2 Threat Consequence Periods 396 Threat consequence period is defined as a portion of time during 397 which the network operations have been impacted by the threat 398 consequences. The threat consequence period is influenced by, but not 399 totally dependent on the duration of the threat action. In some 400 cases, the network operations will get back to normal as soon as the 401 threat action has been stopped. In other cases, however, threat 402 consequences may appear longer than threat action. For example, in 403 the original ARPANET link-state algorithm, some errors in a router 404 might introduce three instances of an LSA, and all of them would be 405 flooded throughout the network forever, until the entire network was 406 power cycled [3]. 408 4. Generally Identifiable Routing Threats 410 This section addresses generally identifiable and recognized threat 411 action against routing protocols. The threats are not necessarily 412 specific to individual protocols but may be present in one or more of 413 the common routing protocols in use today. 415 4.1 Deliberate Exposure 417 Deliberate Exposure occurs when an attacker takes control of a router 418 and intentionally releases routing information directly to other 419 routers. In some cases, the receiving routers may not be authorized 420 to access the leaked routing information. Deliberate exposure is 421 always a threat action, however, the exposure of routing information 422 may not be. 424 The consequence of deliberate exposure is the disclosure of routing 425 information. 427 The threat consequence zone of deliberate exposure depends on the 428 routing information that the attackers have exposed. The more 429 knowledge they have exposed, the bigger the threat consequence zone. 431 The threat consequence period of deliberate exposure might be longer 432 than the duration of the action itself. The routing information 433 exposed will not be out-dated until there is a topology change of the 434 exposed network. 436 4.2 Sniffing 438 Sniffing is an action whereby attackers monitor and/or record the 439 routing exchanges between authorized routers. Attackers can use 440 subverted links to sniff for routing information. 442 The consequence of sniffing is disclosure of routing information. 444 The threat consequence zone of sniffing depends on the attacker's 445 location, the routing protocol type, and the routing information that 446 has been recorded. For example, if the subverted link is in an OSPF 447 totally stubby area, the threat consequence zone should be limited to 448 the whole area. An attacker that is sniffing a subverted link in an 449 EBGP session can gain knowledge of multiple routing domains. 451 The threat consequence period might be longer than the duration of 452 the action. If an attacker stops sniffing a subverted link their 453 acquired knowledge will not be out-dated until there is a topology 454 change of the affected network. 456 4.3 Traffic Analysis 458 Traffic analysis is action whereby attackers gain routing information 459 by analyzing the characteristics of the data traffic on a subverted 460 link. Traffic analysis threats can affect any data that is sent in 461 the clear over a communication link. This threat is not peculiar to 462 routing protocols and is included here for completeness. 464 The consequence of data traffic analysis is the disclosure of routing 465 information. For example, the source and destination IP address of 466 the data traffic, the type, magnitude, and volume of traffic is 467 disclosed. 469 The threat consequence zone of the traffic analysis depends on the 470 attacker's location and what data traffic has passed through. A 471 subverted link at the network core should be able to disclose more 472 information than its counterpart at the edge. 474 The threat consequence period might be longer than the duration of 475 the traffic analysis. After the attacker stops traffic analysis, its 476 knowledge will not be out-dated until there is a topology change of 477 the disclosed network. 479 4.4 Spoofing 481 Spoofing occurs when an illegitimate device assumes the identity of a 482 legitimate one. Spoofing in and of itself is often not the true 483 attack. Spoofing is special in that it can be used to carry out other 484 threat actions causing other threat consequences. An attacker can use 485 spoofing as a means for launching other types of attacks. For 486 example, if an attacker succeeds to spoof the identity of a router, 487 the subverted router can act as masquerading router. In other 488 situation, the spoofed router can be used to send out unrealistic 489 routing information that might cause disruption of network services. 491 There are a few cases where spoofing can be an attack. For example, 492 if a router establishes a neighbor/peering relationship, spoofing the 493 identity of a legitimate router and by that action was able to 494 prevent the legitimate router from establishing a relationship; that 495 would be an attack, denying service to the good router. As a second 496 example, if a router is doing auditing, then the ability to spoof an 497 identity of a router would be an attack, since the audit data would 498 be false. 500 The consequences of spoofing are: 502 o The disclosure of routing information: The spoofed router will be 503 able to gain access to the routing information. 505 o The deception of peer relationship: The authorized routers, which 506 exchange routing messages with the spoofed router, do not realize 507 they are peering with a router that is faking another router's 508 identity. 510 The threat consequence zone includes: 512 The consequence zone of the disclosed routing information depends 513 on what routing information has been exchanged between the spoofed 514 router and its peers. 516 The threat consequence zone covers: 518 o The consequence zone of the fake peer relationship will be limited 519 to those routers mistrusting the attacker's identity. 521 o The consequence zone of the disclosed routing information depends 522 on the attacker's location, the routing protocol type, and the 523 routing information that has been exchanged between the attacker 524 and its deceived peers. 526 4.5 Falsification 528 Falsification is an intentional action whereby false routing 529 information is sent by a subverted router. To falsify the routing 530 information, an attacker has to be either the originator or a 531 forwarder of the routing information. False routing information 532 describes the network in an unrealistic view, whether or not intended 533 by the authoritative network administrator. 535 To falsify the routing information, an attacker has to be either the 536 originator or a forwarder of the routing information. It cannot be a 537 receiver-only. 539 4.5.1 Falsifications by Originators 541 An originator of routing information can launch the falsifications 542 that are described in the next sections. 544 4.5.1.1 Overclaiming 546 Over-claiming occurs when a subverted router advertises its control 547 of some network resources, while in reality it does not, or the 548 advertisement is not authorized. This is given in Figure 2 and 549 Figure 3. 551 +-------------+ +-------+ +-------+ 552 | Internet |---| Rtr B |---| Rtr A | 553 +------+------+ +-------+ +---+---+ 554 | . 555 | | 556 | . 557 | *-+-* 558 +-------+ / \ 559 | Rtr C |------------------* N 1 * 560 +-------+ \ / 561 +-------+ *---* 563 Figure 2: Overclaiming-1 565 +-------------+ +-------+ +-------+ 566 | Internet |---| Rtr B |---| Rtr A | 567 +------+------+ +-------+ +-------+ 568 | 569 | 570 | 571 | *---* 572 +-------+ / \ 573 | Rtr C |------------------* N 1 * 574 +-------+ \ / 575 *---* 577 Figure 3: Overclaiming-2 579 The above figures provide examples of overclaiming. Router A, the 580 attacker, is connected with the Internet through Router B. Router C 581 is authorized to advertise its link to Network 1. In Figure 2, Router 582 A controls a link to Network 1, but is not authorized to advertise 583 it. In Figure 3, Router A does not control such a link. But in either 584 case, Router A advertises the link to the Internet, through Router B. 586 Compromised routers, unauthorized routers, and masquerading routers 587 can overclaim network resources. The consequence of overclaiming 588 includes: 590 o Usurpation of the overclaimed network resources. In Figure 2 and 591 Figure 3, it will cause a usurpation of Network 1 when Router B or 592 other routers on the Internet (not shown in the figures) believe 593 that Router A provides the best path to reach the Network 1. They, 594 the routers, thereby forward the data traffic, destined to Network 595 1, to Router A. The best result is the data traffic uses an 596 unauthorized path Figure 2, and the worst case is the data never 597 reach the destination Network 1 Figure 3. The ultimate 598 consequence is Router A gaining control over Network 1's services, 599 by controlling the data traffic. 601 o Usurpation of the legitimate advertising routers. In Figure 2 and 602 Figure 3, Router C is the legitimate advertiser of Network 1. By 603 overclaiming, Router A also controls (partially or totally) the 604 services/functions provided by the Router C. (This is NOT a 605 disruption, because Router C is operating in a way intended by the 606 authoritative network administrator.) 608 o Deception of other routers. In Figure 2 and Figure 3, Router B, or 609 other routers on the Internet, might be deceived to believe the 610 path through Router A is the best. 612 o Disruption of data planes on some routers. This might happen on 613 routers that are on the path, which is used by other routers to 614 reach the overclaimed network resources through the attacker. In 615 Figure 2 and Figure 3, when other routers on the Internet are 616 deceived, they will forward the data traffic to Router B, which 617 might be overloaded. 619 The threat consequence zone varies based on the consequence: 621 o Where usurpation is concerned, the consequence zone covers the 622 network resources that are overclaimed by the attacker (Network 1 623 in Figure 2 and 3), and the routers that are authorized to 624 advertise the network resources but lose the competition against 625 the attacker(Router C in Figure 2 and Figure 3). 627 o Where deception is concerned, the consequence zone covers the 628 routers that do not believe the attacker's advertisement and use 629 the attacker to reach the claimed subnets (Router B and other 630 deceived routers on the Internet in FigureFigure 2 and Figure 3). 632 o Where disruption is concerned, the consequence zone includes the 633 routers that are on the path of misdirected data traffic (Router B 634 in Figure 2 and Figure 3). 636 The threat consequence will cease when the attacker stops 637 overclaiming, and will totally disappear when the routing tables are 638 converged. As a result the consequence period is longer than the 639 duration of the overclaiming. 641 4.5.1.2 Underclaiming 642 TBD: Need to agree on the title and if it is a threat or not? 644 4.5.1.3 Misclaiming 646 A Misclaiming threat is defined as an attacker action advertising its 647 authorized control of some network resources in a way that is not 648 intended by the authoritative network administrator. An attacker can 649 eulogize or disparage when advertising these network resources. 650 Subverted routers, unauthorized routers, and masquerading routers can 651 misclaim network resources. 653 The threat consequences of Misclaiming are similar to the 654 consequences of overclaimin. Eulogizing the network resources might 655 cause the same consequences made by overclaiming. 657 The consequence zone and period are also similar to those of 658 overclaiming. 660 4.5.2 Falsifications by Forwarders 662 When a legitimate router forwards routing information, it must or 663 must not modify the routing information, depending on the routing 664 information and the routing protocol type. For example, in RIP, the 665 forwarder must modify the routing information by increasing the hop 666 count by 1. On the other hand, the forwarder must not modify the type 667 1 LSA in OSPF. In general, forwarders in distance vector routing 668 protocols are authorized to and must modify the routing information, 669 while most forwarders in link state routing protocols are not 670 authorized to and must not modify most routing information. 672 As a forwarder authorized to modify routing message, an attacker does 673 not forward necessary routing information to other authorized 674 routers. Unauthorized aggregation (summarization) is special type of 675 understatements. 677 4.5.2.1 Misstatement 679 This is defined as an action whereby the attacker describes route 680 attributes in a wrong way. For example, in RIP, the attacker 681 increases the path cost by two hops instead of one. Another example 682 is, in BGP, the attacker deletes some AS numbers from the AS PATH. 684 When forwarding routing information that should not be modified, an 685 attacker can launch the following falsifications: 687 o Deletion: Attacker deletes valid data in the routing message. 689 o Insertion: Attacker inserts false data in the routing message. 691 o Substitution: Attacker replaces valid data in the routing message 692 with false data. 694 o Replaying: Attacker replays out-dated data in the routing message. 696 All types of attackers (Compromised links, compromised routers, 697 unauthorized routers, and masquerading routers) can falsify the 698 routing information when they forward the routing messages. 700 The threat consequences of these falsifications by forwarders are 701 similar to those caused by originators: Usurpation of some network 702 resources and related routers; deception of routers using false 703 paths; and disruption of data planes of routers on the false paths. 704 The threat consequence area and period are also similar. 706 4.6 Interference 708 Interference is a threat action where an attackers uses a subverted 709 link or router to inhibit the exchanges by legitimate routers. The 710 attacker can do this by adding noise, or by not forwarding packets, 711 or by replaying out-dated packets, or by delaying responses, or by 712 denial of receipts, and breaking synchronization. 714 Subverted, unauthorized and masquerading routers can slowdown their 715 routing exchanges or create flapping routing sessions of legitimate 716 peering routers. 718 The consequence of interference is the disruption of routing 719 operations. 721 The consequence zone of interference varies based on the source of 722 the threats: 724 o When a subverted link is used to launch the action, the threat 725 consequence zone covers routers that are using the link to 726 exchange the routing information. 728 o When subverted routers, unauthorized routers, or masquerading 729 routers are the attackers, the threat consequence zone covers 730 routers with which the attackers are exchanging routing 731 information. 733 o The threat consequences might disappear as soon as the 734 interference is stopped, or might not totally disappear until the 735 networks have converged. Therefore, the consequence period is 736 equal or longer than the duration of the interference. 738 4.7 Overload 740 Overload is defined as a threat action whereby attackers place excess 741 burden on legitimate routers. Attackers can overload the data plane 742 or control plane. Because data plane is involved in routing 743 exchanges, overload of data plane will also influence the routing 744 operations. 746 Note:Remark below comes directly from the list. More work is needed 747 here. 749 This section combines overload of the control plane and the data 750 plane (the control and data plane of the router, I presume, i.e., the 751 routing protocol messages and the data traffic, not the control and 752 data plane of the routing protocol itself as discussed in section 753 2.1). I think those are two very different topics. For one thing, 754 the routing protocol design might have a chance to limit control 755 plane traffic. But I don't think the routing protocol has much of a 756 chance to limit the data traffic. Effect on the behavior of the 757 entire routing system of data plane activity is another case where 758 there's no doubt that there's an opportunity for attack, but not much 759 chance that the routing protocol could do anything about it. (The 760 ability of someone to break the transport protocol connection (e.g., 761 TCP RST) is another. Traffic analysis is another. Overload on the 762 data plane is another.) How do we handle these? Leave them out of 763 the Routing *PROTOCOL* threat list? Or list them here as threats but 764 eliminate from the requirements draft? Specially designate them here 765 as threats but not through the routing protocol? I'm not sure - I 766 think we have to decide what the purpose of the document is to make a 767 choice. 769 4.8 Byzantine Failures 771 Definition is needed. 773 It is not clear how to valid that a Byzantine failure has occurred 775 NOTE: More work is needed 777 4.9 Discarding of Control Packets 779 TBD: Not clear from the list the needed text here. 781 4.10 Network Mapping Threats 782 TBD 784 4.11 DoS and DDoS Attacks 786 TBD: Information to be collected from the list. 788 5. Security Considerations 790 This entire informational draft RFC is security related. Specifically 791 it addresses security of routing protocols as associated with threats 792 to those protocols. In a larger context, this work builds upon the 793 recognition of the IETF community that signaling and control/ 794 management planes of networked devices need strengthening. Routing 795 protocols can be considered part of that signaling and control plane. 796 However, to date, routing protocols have largely remained unprotected 797 and open to malicious attacks. This document discusses inter and 798 intra domain routing protocol threats as we know them today and lays 799 the foundation for a future draft which fully discusses security 800 requirements for routing protocols. 802 Normative References 804 [1] Shirey, R, "Internet Security Glossary", RFC 2828 , May 2000. 806 [2] Smith, R et al., "Securing Distance-Vector Routing Protocols", 807 Symposium on Network and Distributed System Security , February 808 1997. 810 [3] Rosen, E., "Vulnerabilities of Network Control Protocols: An 811 Example, Computer Communication Review", , July 1981. 813 [4] Perlman, R, "Network Layer Protocols with Byzantine Robustness", 814 , August 1988 . 816 [5] Murphy, S et al., "OSPF with Digital Signatures", RFC 2154 , 817 June 1997. 819 [6] Moy, J, "OSPF Version 2", RFC 2328 , April 1998. 821 [7] Mittal, V et al., "Sensor-Based Intrusion Detection for 822 Intra-Domain istance-Vector Routing", Proceedings of the ACM 823 Conference on Computer and Communication Security (CCS'02), 824 Washington, DC , November 2002. 826 [8] Cheung, S. et. al., "Protecting Routing Infrastructures from 827 Denial of Service using co-operative intrusion detection", In 828 Proceedings of the 1995 IEEE Symposium on Security and Privacy 829 , May 1995. 831 [9] Bradley, K. et. al., "A distributed Network Monitoring 832 approach", Published , November 2001. 834 Informative References 836 [10] Vetter, W. et al., "Experimental Study of Insider Attacks in a 837 Link State Routing Protocol", 5th IEEE International 838 Conference on Network Protocols, Atlanta, GA , 1997. 840 [11] "Internet Group Management Protocol", RFC 3376 , October 2002. 842 [12] Estrin, D. et al., "Independent Multicast-Sparse Mode (PIM-SM): 843 Protocol pecification", RFC 2362 , June 1998 . 845 [13] Ballardie, A. et al., "Multicast-Specific Security Threats and 846 Counter-Measures", "Symposium on network and Distributed 847 System Security" , February 1995. 849 Authors' Addresses 851 Abbie Barbir (Editor) 852 Nortel Networks 853 3500 Carling Avenue 854 Nepean, Ontario K2H 8E9 855 Canada 857 Phone: 858 EMail: abbieb@nortelnetworks.com 860 Sandy Murphy 861 Network Associates, Inc 862 3060 Washington Rd. 863 Glenwood, MD 21738 864 USA 866 Phone: 443-259-2303 867 EMail: sandy@tislabs.com 869 Yi Yang 870 Cisco Systems 871 7025 Kit Creek Road 872 RTP, NC 27709 873 Canada 875 Phone: 876 EMail: yiya@cisco.com 878 Appendix A. Acknowledgements 880 This draft would not have been possible save for the excellent 881 efforts and team work characteristics of those listed here. 883 o Dennis Beard- Nortel Networks 885 o Ayman Musharbash - Nortel Networks 887 o Paul Knight - Nortel Networks 889 o Elwyn Davies - Nortel Networks 891 o Ameya Dilip Pandit - Graduate student - University of Missouri 893 o Senthilkumar Ayyasamy - Graduate student - University of Missouri 895 Appendix B. Acronyms 897 AODV - Ad-hoc On-demand Distance Vector routing protocol 899 AS - Autonomous system. Set of routers under a single technical 900 administration. Each AS normally uses a single interior gateway 901 protocol (IGP) and metrics to propagate routing information within 902 the set of routers. Also called routing domain. 904 AS-Path - In BGP, the route to a destination. The path consists of 905 the AS numbers of all routers a packet must go through to reach a 906 destination. 908 BGP - Border Gateway Protocol. Exterior gateway protocol used to 909 exchange routing information among routers in different autonomous 910 systems. 912 eBGP - External BGP. BGP configuration in which sessions are 913 established between routers in different ASs. 915 iBGP - Internal BGP. BGP configuration in which sessions are 916 established between routers in the same ASs. 918 LSRP - Link-State Routing Protocol 920 LSA - Link-State Announcement 922 M-OSPF - Multicast Open Shortest Path First 924 NLRI - Network layer reachability information. Information that is 925 carried in BGP packets and is used by MBGP. 927 OSPF - Open Shortest Path First. A link-state IGP that makes routing 928 decisions based on the shortest-path-first (SPF) algorithm (also 929 referred to as the Dijkstra algorithm). 931 Intellectual Property Statement 933 The IETF takes no position regarding the validity or scope of any 934 intellectual property or other rights that might be claimed to 935 pertain to the implementation or use of the technology described in 936 this document or the extent to which any license under such rights 937 might or might not be available; neither does it represent that it 938 has made any effort to identify any such rights. Information on the 939 IETF's procedures with respect to rights in standards-track and 940 standards-related documentation can be found in BCP-11. Copies of 941 claims of rights made available for publication and any assurances of 942 licenses to be made available, or the result of an attempt made to 943 obtain a general license or permission for the use of such 944 proprietary rights by implementors or users of this specification can 945 be obtained from the IETF Secretariat. 947 The IETF invites any interested party to bring to its attention any 948 copyrights, patents or patent applications, or other proprietary 949 rights which may cover technology that may be required to practice 950 this standard. Please address the information to the IETF Executive 951 Director. 953 Full Copyright Statement 955 Copyright (C) The Internet Society (2003). All Rights Reserved. 957 This document and translations of it may be copied and furnished to 958 others, and derivative works that comment on or otherwise explain it 959 or assist in its implementation may be prepared, copied, published 960 and distributed, in whole or in part, without restriction of any 961 kind, provided that the above copyright notice and this paragraph are 962 included on all such copies and derivative works. However, this 963 document itself may not be modified in any way, such as by removing 964 the copyright notice or references to the Internet Society or other 965 Internet organizations, except as needed for the purpose of 966 developing Internet standards in which case the procedures for 967 copyrights defined in the Internet Standards process must be 968 followed, or as required to translate it into languages other than 969 English. 971 The limited permissions granted above are perpetual and will not be 972 revoked by the Internet Society or its successors or assignees. 974 This document and the information contained herein is provided on an 975 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 976 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 977 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 978 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 979 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 981 Acknowledgement 983 Funding for the RFC Editor function is currently provided by the 984 Internet Society.