idnits 2.17.1 draft-ietf-rpsec-ospf-vuln-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1073. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1050. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1057. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1063. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (June 16, 2006) is 6523 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) == Outdated reference: A later version (-03) exists of draft-iab-sec-cons-00 -- No information found for draft-etienne-ospv2-auth-flaws - is the name correct? Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Routing Protocol Security E. Jones 3 Requirements O. Le Moigne 4 Internet-Draft Alcatel 5 Expires: December 18, 2006 June 16, 2006 7 OSPF Security Vulnerabilities Analysis 8 draft-ietf-rpsec-ospf-vuln-02.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 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 28 http://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 December 18, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 Internet infrastructure protocols were designed at the very early 42 stages of computer networks when "cyberspace" was still perceived as 43 a benign environment. As a consequence, malicious attacks were not 44 considered to be a major risk when these protocols were designed, 45 leaving today's Internet vulnerable. This paper provides an analysis 46 of OSPF vulnerabilities that could be exploited to modify the normal 47 routing process across a single domain together with an assessment of 48 when internal OSPF mechanisms can or cannot be leveraged to better 49 secure a domain. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Attacker's Definition . . . . . . . . . . . . . . . . . . 3 55 1.2. Attacker's Location . . . . . . . . . . . . . . . . . . . 4 56 1.3. Vulnerabilities Damages and Consequences . . . . . . . . . 4 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 3. Generic Attack Techniques . . . . . . . . . . . . . . . . . . 7 59 4. Vulnerabilities and Risks . . . . . . . . . . . . . . . . . . 9 60 4.1. OSPF General Vulnerabilities . . . . . . . . . . . . . . . 9 61 4.1.1. Local Intrusion Global Impact . . . . . . . . . . . . 9 62 4.1.2. Remote Attacker . . . . . . . . . . . . . . . . . . . 9 63 4.1.3. Attacker Disabling Fight Back . . . . . . . . . . . . 9 64 4.1.4. Attacker Leveraging Fight Back . . . . . . . . . . . . 11 65 4.1.5. Dealing with External Routes . . . . . . . . . . . . . 11 66 4.2. Protocol-specific Vulnerabilities . . . . . . . . . . . . 11 67 4.2.1. Packet Header with Cryptographic Authentication 68 Enabled . . . . . . . . . . . . . . . . . . . . . . . 12 69 4.2.2. Hello Message . . . . . . . . . . . . . . . . . . . . 13 70 4.2.3. DB Description, Link State Request and 71 Acknowledgment . . . . . . . . . . . . . . . . . . . . 15 72 4.2.4. Link State Update . . . . . . . . . . . . . . . . . . 15 73 4.3. Resource Consumption Vulnerabilities . . . . . . . . . . . 18 74 4.3.1. OSPF Cryptographic Authentication . . . . . . . . . . 19 75 4.3.2. Hello Message . . . . . . . . . . . . . . . . . . . . 19 76 4.3.3. Link State Request Message . . . . . . . . . . . . . . 20 77 4.3.4. Link State Acknowledgment Message . . . . . . . . . . 20 78 4.3.5. Link State DB Overflow . . . . . . . . . . . . . . . . 20 79 4.3.6. Others . . . . . . . . . . . . . . . . . . . . . . . . 21 80 4.4. Vulnerabilities through Other Protocols . . . . . . . . . 21 81 4.4.1. IP . . . . . . . . . . . . . . . . . . . . . . . . . . 22 82 4.4.2. Other Supporting Protocols (Management) . . . . . . . 22 83 4.5. Residual Risk . . . . . . . . . . . . . . . . . . . . . . 22 84 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 25 86 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 87 7.1. Normative References . . . . . . . . . . . . . . . . . . . 26 88 7.2. Informative References . . . . . . . . . . . . . . . . . . 26 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 90 Intellectual Property and Copyright Statements . . . . . . . . . . 28 92 1. Introduction 94 Internet infrastructure protocols were designed at the very early 95 stages of computer networks when "cyberspace" was still perceived as 96 a benign environment. As a consequence, malicious attacks were not 97 considered to be a major risk when these protocols were designed, 98 leaving today's Internet infrastructure vulnerable. 100 Since routers work in a cooperatively manner based on forwarding 101 network information received from their peers, they are all 102 threatened by the possibility that the exchanged routing information 103 may have been contaminated or forged by a malicious or faulty entity. 105 This paper provides an analysis of OSPF [1] vulnerabilities that 106 could be exploited to modify the normal routing process across a 107 single domain, together with an assessment of when internal OSPF 108 mechanisms can or cannot be leveraged to secure a domain. 110 1.1. Attacker's Definition 112 Throughout this paper the term attacker will be used to define any 113 entity capable of posing any threat to an OSPF routing domain. 114 Hence, this definition includes: 1) any subverted OSPF router, 2) any 115 malicious software capable of interacting with an OSPF routing 116 domain, 3) any faulty or misconfigured legitimate OSPF peer. 118 From a security standpoint, this paper is consolidating all possible 119 OSPF deployment situations into two opposite scenarios. 121 The first scenario requires OSPF Cryptographic Authentication or 122 Simple Password Authentication to be present on all links within a 123 routing domain. The second scenario takes place when Null 124 Authentication is adopted. 126 If one link is not protected then the whole routing domain becomes 127 potentially vulnerable; if the attacker is in the position to obtain 128 even a single copy of any OSPF message then the authentication 129 provided by Simple Password is compromised and the security for the 130 entire routing domain falls immediately in the second scenario. 132 In the first scenario, Cryptographic Authentication being deployed, 133 there are two kinds of entities capable of attacking or posing 134 threats: insiders and outsiders. An attacking entity is considered 135 an insider if it is in possession of the secret key for any OSPF 136 Cryptographic Authentication session either through: cryptanalysis, 137 social engineering, coercion or access to a compromised/subverted 138 routing resource. This also includes threats arising from 139 malfunctioning or faulty-configured OSPF routers. An outsider is an 140 attacker that is not in possession of the secret key. 142 In the second scenario, when the routing domain is not protected by 143 OSPF Cryptographic or Simple Password authentication there is no 144 distinction between insider and outsider entities. Any attacker can 145 successfully forge OSPF messages on behalf of any OSPF peer, 146 legitimate or not. 148 1.2. Attacker's Location 150 Since OSPF routers on broadcast, on Point-to-Multipoint, NBMA and on 151 virtual links will accept unicast packets that are destined directly 152 to them, no assumption is made on the location of the attacking 153 entity. This leads to a scenario where an attacker, in possession of 154 a secret key, if at all needed, can attack a router located in a 155 remote routing domain. The proper implementation of ingress 156 filtering and other mechanisms described by RFC2827 [2] and recently 157 by the Internet Draft [3] should mitigate this situation, forcing 158 insider and outsider attackers to at least have access to one of the 159 links in the routing domain target of their attack. 161 1.3. Vulnerabilities Damages and Consequences 163 Generally speaking attackers will be able to disrupt and manipulate 164 the routing domain, posing serious threats to the actual delivery of 165 data and control plane packets. 167 For instance, if the routing information creates loops in the 168 forwarding path some packets will never be delivered, denying service 169 to many destinations. Loops also create congestion by leaving 170 packets in the network longer than necessary and by consuming 171 resources without providing any useful service in the end. The 172 incorrect forwarding of large amounts of traffic over one link may 173 overwhelm the link and result in the delaying, or even prevention, of 174 traffic delivery. Moreover, incorrect routing information could 175 result in data traffic transiting networks that otherwise would have 176 never seen that data. 178 Finally, routing information that incorrectly reports OSPF Areas, or 179 any other portion of the domain, as unreachable will deny services to 180 all hosts connected to or exchanging traffic with said areas. 182 The damages [4] that might result from these attacks are: 184 starvation: data traffic destined for a node is forwarded to a 185 part of the network that cannot deliver it, 186 network congestion: more data traffic is forwarded through some 187 portion of the network than would otherwise need to carry the 188 traffic, 190 blackhole: large amounts of traffic are directed as to be 191 forwarded through one router that cannot handle the increased 192 level of traffic and drops many/most/all packets, 194 delay: data traffic destined for a node is forwarded along a path 195 that is in some way inferior to the path it would otherwise take, 197 looping: data traffic is forwarded along a path that loops, so 198 that the data is never delivered, 200 eavesdrop: data traffic is forwarded through some router or 201 network that would otherwise not see the traffic, affording an 202 opportunity to see the data, 204 partition: some portion of the network believes that it is 205 partitioned from the rest of the network when it is not, 207 cut: some portion of the network believes that it has no route to 208 some network that is in fact connected, 210 churn: the forwarding in the network changes at a rapid pace, 211 resulting in large variations in the data delivery patterns (and 212 adversely affecting congestion control techniques), 214 instability: OSPF becomes unstable so that convergence on a global 215 forwarding state is not achieved, 217 overload: the OSPF messages themselves become a significant 218 portion of the traffic the network carries. 220 resource exhaustion: the OSPF messages themselves cause exhaustion 221 of critical router resources, such as table space and queues. 223 These consequences can fall exclusively on a single OSPF Area or may 224 effect the operation of the OSPF network domain as a whole. 226 2. Terminology 228 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 229 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 230 document are to be interpreted as described in RFC 2119 [5]. 232 3. Generic Attack Techniques 234 The OSPF protocol is subject to the following attacks (list taken 235 from the IAB Internet-Draft providing guideline for the security 236 considerations section of Internet-Drafts [6]). 238 Eavesdropping: The routing data carried in OSPF is carried in 239 clear-text, so eavesdropping is a possible attack against routing 240 data confidentiality. 242 Message Replay: In general, OSPF with Cryptographic Authentication 243 provides a sufficient mechanism for replay protection of its 244 messages. Nonetheless, there are still some scenarios in which an 245 outsider attacker can successfully replay OSPF messages; these are 246 illustrated over the next sections. 248 Message Insertion: OSPF with Cryptographic Authentication enabled 249 is not vulnerable to message insertion from outsiders. In the 250 case of an insider or in the absence of Cryptographic 251 Authentication, message insertion becomes a trivial operation even 252 for a remote attacker. 254 Message Deletion: OSPF provides a certain degree of protection 255 against message deletion. The receiver itself cannot detect if a 256 message has been deleted or not, but the sender will detect a 257 deleted Link State Update (LSU) message since it will not receive 258 any OSPF Link State Acknowledgment message for it. There is no 259 acknowledging mechanism for Hello messages, but the deletion of 260 some, generally four or more, consecutive Hello messages belonging 261 to the same router will cause "adjacency breaking" and thus be 262 easily detected by all the parties involved. 264 Message Modification: OSPF with Cryptographic Authentication 265 provides protection against modification of messages. In the case 266 of an insider or in the absence of Cryptographic Authentication 267 message modification becomes possible. 269 Man-In-The-Middle: OSPF with Cryptographic Authentication provides 270 protection against man-in-the-middle attacks. In the case of an 271 insider or in the absence of Cryptographic Authentication, the 272 protocol becomes exposed to man-in-the-middle attacks through the 273 lower network layers - such as ARP spoofing - on all OSPF peers 274 that are one hop apart; while OSPF peers connected over virtual 275 links are exposed to Layer 3 man-in-the-middle attacks too. 277 Denial-of-Service: While bogus routing information data can 278 represent a Denial of Service attack on the end systems that are 279 trying to transmit data through the network and on the network 280 infrastructure itself, certain bogus information can represent a 281 more specific Denial of Service on the OSPF routing protocol 282 itself. For example, it is possible to reach the limits of the 283 Link State Database of a victim with External LSAs or with bogus 284 LSA headers during the Link State Database Exchange phase. 286 4. Vulnerabilities and Risks 288 4.1. OSPF General Vulnerabilities 290 The risks in OSPF arise from the following fundamental 291 vulnerabilities: 293 4.1.1. Local Intrusion Global Impact 295 Compromising a single network equipment (router) or a link's security 296 has an obvious and immediate local impact (ability to disable local 297 links, to change properties, to stop routers etc...). Unfortunately, 298 due to the lack of end-to-end authentication mechanisms - such as a 299 Public Key Infrastructure (PKI) - a breach in a single link has also 300 a global impact since the attacker is now in the position to tamper 301 with information regarding any other remote network equipment 302 belonging to the same routing domain. 304 4.1.2. Remote Attacker 306 Even though OSPF is designed and deployed to be used as an intra- 307 domain routing protocol, in most scenarios and situations an OSPF 308 router will still accept unicast IP packets directly addressed to 309 itself as described in paragraph 8.1 of RFC2328 [1]. "On physical 310 point-to-point networks, the IP destination is always set to the 311 address AllOSPFRouters. On all other network types (including 312 virtual links), the majority of OSPF packets are sent as unicasts, 313 i.e., sent directly to the other end of the adjacency." This opens 314 the door to attacks that may be originating from outside the OSPF 315 domain. Timing the stream of different packets needed for a given 316 attack poses a certain degree of difficulty if executed from a remote 317 AS, but it may not be enough to stop a skilled and motivated 318 attacker. This means that, for example, customers on the access 319 edges of a network can start attacking the routing domain in the 320 core, if said domain were not to be protected by Cryptographic 321 Authentication or if the malicious subscribers were to obtain the 322 secret key. 324 4.1.3. Attacker Disabling Fight Back 326 It is often the case while reading papers, or other literature 327 material, about OSPF to come across the concept of an OSPF "natural" 328 fight back mechanism, for example [7]. OSPF fight back can be 329 defined as follows: any router receiving an LSA that lists itself as 330 the advertising router and noticing that the content of this LSA is 331 not coherent with its status of resources will try to correct the 332 situation either by flushing or updating the erroneous LSA. The 333 following three scenarios show how the OSPF fight back mechanism can 334 be disabled clearing the way to stealthy attacks. 336 4.1.3.1. Periodic Injection 338 This is a brief explanation on how a malicious LSA will succeed in 339 attacking a routing domain, overriding any fight back: 341 According to RFC2328 [1], a router will never emit (or update) its 342 LSAs faster than once every MinLSInterval (5 seconds). This allows 343 for almost permanent changes in the routing domain, if an attacker is 344 flooding the OSPF domain with malicious LSAs at a rate higher than 345 one every MinLSInterval. 347 On top of this, if an OSPF implementation behaves as described by 348 RFC2328 [1] on paragraph 13, the router owner of the LSA may never 349 fight back and it will collaborate in the flooding of malicious 350 routing information on its behalf. The flooding happens because the 351 malicious LSA is considered newer than the copy already present in 352 the legitimate owner's Link State Database - the malicious LSA will 353 have a higher sequence number - (check performed on Step 5) and 354 because the legitimate copy of the LSA already present in the Link 355 State Database was not received via flooding but installed by the 356 router itself (check performed in step 5.a). When step 5.f is 357 finally executed - after the malicious LSA has been already flooded - 358 a simple test reveals that the LSA was owned by the router and that 359 it contained erroneous information. Only at this stage action is 360 taken to correct it; but since any router must wait MinLSInterval 361 before updating any of its LSAs, the owner will fight back every 362 MinLSInterval while the flooding is in progress. We have also 363 observed a complete lack of fight back in implementations that 364 erroneously reset MinLSInterval when flooding LSAs. 366 4.1.3.2. Partitioned Networks 368 If the flooding mechanism does not have a path to rely malicious LSAs 369 to the legitimate owner, said owner will never initiate a fight back. 370 An example of this could be a subverted router conveniently located 371 on a partitioning link. If said router is removed, the entire 372 network domain would be partitioned into two disconnected portions. 373 This subverted router could choose to inject a given malicious LSA 374 only into one part of the routing domain, claiming that this LSA is 375 coming from a legitimate router located on the opposite portion of 376 the network. The legitimate router will never be made aware of the 377 forged information on its behalf and thus will never initiate a fight 378 back. This will create fatal inconsistencies between the Link State 379 Databases of the various OSPF routers. 381 4.1.3.3. Phantom Routers 383 All information injected in the routing domain on behalf of non- 384 existing (phantom) OSPF routers will never trigger a fight back 385 reaction. Thus, this information will remain in the Link State 386 Databases of the legitimate routers for MaxAge (1 hour, by default). 387 It is important to underline that even if Link State Advertisements 388 (LSAs) crafted on behalf of phantom routers are kept in the Link 389 State Database, these are not taken into account by the Shortest Path 390 First (SPF) algorithm. 392 4.1.4. Attacker Leveraging Fight Back 394 The fight back mechanism can contribute to amplify certain Denial of 395 Service attacks. One single false LSA may unleash a significant 396 number of LSA updates that are trying to correct it. Even though 397 such a reaction is both efficient and desirable, it may be leveraged 398 to amplify the effects of certain Denial of Service attacks, if 399 continuously triggered. 401 4.1.5. Dealing with External Routes 403 Every piece of routing information that is dealing with outside 404 routes, forged or real, that is introduced in the domain - by means 405 of route redistribution via BGP, RIP or any other routing protocol 406 including statically configured - cannot be verified and it is 407 propagated to all OSPF Areas of the domain that are not configured as 408 stub-areas or NSSA. Even though verification of routes that are 409 outside the routing domain is clearly beyond the scope of OSPF, the 410 current flooding mechanism of such information may be used as an 411 efficient intrinsic vector for conveying malicious/bogus messages. 412 Moreover, if an attacker manages to subvert an ASBR node, or 413 successfully masquerades as one, there will be no fight back from any 414 of the other ASBRs regarding ownership, validity and metric 415 advertisement for the External routes claimed by the subverted ASBR; 416 thus, the attacker could easily attract to itself big portions of the 417 traffic destined outside the AS. 419 4.2. Protocol-specific Vulnerabilities 421 There are two types of authentication mechanisms in OSPF: Simple 422 Password and Cryptographic. Simple Password authentication consists 423 of a plain text password carried in the header of each OSPF message; 424 the vulnerability of this Authentication method is obvious and will 425 not be discussed further. There are five different OSPF message 426 types: Hello, Database Description, Link State Request, Link State 427 Update, Link State Acknowledgement. The next sections discuss 428 general vulnerabilities for every field in the five OSPF messages as 429 well as the ones arising from Cryptographic Authentication. Each 430 section also defines the ability for outsiders, insiders or faulty 431 OSPF peers to exploit these weaknesses. 433 4.2.1. Packet Header with Cryptographic Authentication Enabled 435 4.2.1.1. IP Header 437 No field of the IP header is protected by the Message Authentication 438 Code (MAC) available when Cryptographic Authentication is enabled. 439 This poses a threat to OSPF any time the protocol relies on any IP 440 field. For example RFC2328 [1] states on paragraph 10.5: "When 441 receiving an Hello on a point-to-point network (but not on a virtual 442 link) set the neighbor structure's Neighbor IP address to the 443 packet's IP source address". 445 4.2.1.2. OSPF Header 447 Neighbor OSPF routers may reset their Cryptographic Sequence Number 448 states when a peer reboots (if the "resetting" peer is not capable of 449 storing Cryptographic Sequence Numbers across reboots) or when the 450 peer's Cryptographic Sequence Number rolls over. At this point, any 451 previously logged packet can be maliciously replayed and will look 452 legitimate if the secret key has not changed in the mean time. 453 Moreover, if the replayed packet is chosen with a high enough 454 sequence number, it will block the communication between the recently 455 rebooted router and its peer(s) for RouterDeadInterval plus the time 456 needed to establish a new adjacency [8]. This vulnerability is 457 exploitable by any outsider that is able to log OSPF packets. It is 458 important to underline that this vulnerability could be used to break 459 adjacencies between OSPF peers. 461 Breaking an adjacency will cause an OSPF router to update its own 462 Router LSA which in turn will force a new SPF calculation, this may 463 lead to changes in the routing table due to the loss of one peer. If 464 the router is also the Designated Router (DR) for the link, breaking 465 an adjacency also entails modifying the corresponding link's Network 466 LSA, potentially resulting in transit links being declared as stub 467 connections and/or partitioning of the domain. 469 Finally, even for an insider attacker (with or without the ability to 470 log packets) forging a single Hello message, with a high enough 471 sequence number, is an excellent and quick option to break any 472 established adjacency. In conclusion this vulnerability may be 473 appealing to both outsider and insider attackers. 475 4.2.2. Hello Message 477 In general errors in Hello message parameters such as incorrect 478 AreaID, RouterDeadInterval, HelloInterval and so on will cause the 479 Hello to be silently discarded with no further impact. 481 Other Hello parameters are analyzed next, and in order to modify the 482 following parameters, the attacker must be an insider, i.e. in 483 possession of the secret for the link to be attacked or the link must 484 be configured with the Null Authentication security option. 486 4.2.2.1. Neighbor 488 Omission of one or more adjacent neighbors in the neighbor list will 489 immediately break the adjacency and force a synchronization process 490 between the legitimate owner of the Hello message and all the omitted 491 neighbors. 493 Breaking an adjacency will cause an OSPF router to update its own 494 Router LSA which in turn will force a new SPF calculation, this may 495 lead to changes in the routing table due to the loss of one peer. If 496 the router is also the Designated Router (DR) for the link, breaking 497 an adjacency also entails modifying the corresponding link's Network 498 LSA, potentially resulting in transit links being declared as stub 499 connections and/or partitioning of the domain. 501 4.2.2.2. DR and BDR 503 Tampering with these two fields can lead to several problematic 504 scenarios,(concerning broadcast and NBMA networks) each leading to 505 different consequences for the routing domain. 507 In order to be taken into account by the DR election process on a 508 victim router, the attacker must list the victim router ID into the 509 active neighbor list of its malicious Hello. Next some examples of 510 attacks are described. 512 In the Hello message, setting to null the DR and BDR fields, on 513 behalf of a legitimate router on the network, and listing all 514 neighbors in the malicious Hello, will force a full re-election of 515 the DR and BDR. 517 Bogus Hello messages from a non-existing router, with a Router 518 Priority and an IP address higher than any legitimate router on a 519 network, listing itself as DR will allow the attacker to successfully 520 convince all the routers present in the neighbor list (of the 521 malicious Hello) that the DR has changed. Any router believing in 522 the non-existing DR will update its Router LSA by listing a link to a 523 stub network instead of the transit network (because it is not fully 524 adjacent to the non-existing DR). Thus, this router will not use 525 this network anymore as a transit network; this will lead to 526 connectivity loss. 528 If the attacker is listing the current DR and BDR in the active 529 neighbors, then the current DR and BDR will also be deceived into 530 thinking that the non-existing router is the new DR. This will have 531 an impact on all the routers connected to the network at once. 533 4.2.2.3. Deletion of Hello Messages 535 If no Hello message is received from a given neighbor for a period of 536 time longer than RouterDeadInterval, then the adjacency with this 537 router is considered to be broken. 539 Breaking an adjacency will cause an OSPF router to update its own 540 Router LSA which in turn will force a new SPF calculation, this may 541 lead to changes in the routing table due to the loss of one peer. If 542 the router is also the Designated Router (DR) for the link, breaking 543 an adjacency also entails modifying the corresponding link's Network 544 LSA, potentially resulting in transit links being declared as stub 545 connections and/or partitioning of the domain. 547 4.2.2.4. Hello Message Replay 549 The Hello Replay attack cannot be perpetrated by an outsider as 550 described by [8]. "The HELLO packet lists the recently seen routers, 551 so if an attacker replays a HELLO packet back to its source, the 552 source won't see itself in the list and will deduce the connection 553 isn't bidirectional. [...] On broadcast, NBMA or Point to Multipoint 554 networks, the neighbor is identified by its IP address, so both 555 attacks can be used." [7] (paragraphs 3.2.2 and 3.2.3). This clashes 556 with what is stated by RFC2328 [1] (paragraph 10.5): "When receiving 557 a Hello Packet from a neighbor on a broadcast, Point-to-MultiPoint or 558 NBMA network, set the neighbor structure's Neighbor ID equal to the 559 Router ID found in the packet's OSPF header." Zebra seems to be in 560 agreement with the RFC's interpretation provided above and is not 561 vulnerable to the Hello Replay attack. 563 In conclusion, the RouterID field is covered by Cryptographic 564 Authentication and therefore it cannot be modified by an outsider 565 without infringing on the MAC (Message Authentication Code), and if 566 the Hello message is replayed to its owner without modifying anything 567 the RouterID will match the one of the owner and the message will be 568 ignored. 570 4.2.3. DB Description, Link State Request and Acknowledgment 572 There is no clear threat except for an insider attacker, or a faulty 573 router, that behaves as described in the resource consumption 574 section. 576 4.2.4. Link State Update 578 In order to modify the parameters described in the following 579 subsections, the attacker must be able to successfully inject 580 malicious LSUs. Hence, the attacker must either subvert, impersonate 581 or fake a router which is at least in the exchange state or higher. 582 In the two latter cases, the attacker must be an insider, i.e. in 583 possession of the secret key for a link or a link must be configured 584 with the Null Authentication security option. 586 4.2.4.1. Link State Update Header 588 The Link State Update (LSU) Header does not appear to present any 589 vulnerability in and for itself. In the case of attacks involving 590 bogus LSAs, some fields of the LSU header may need to be maliciously 591 modified to be consistent with the bogus information carried by the 592 LSAs. 594 In general, errors in some LSU Header parameters such as incorrect 595 RouterID, AreaID and AuType will cause the LSU to be silently 596 discarded with no further impact. 598 4.2.4.2. Link State Advertisement Header 600 4.2.4.2.1. LS age (MaxAge Attack) 602 Setting the age field of an LSA to MaxAge will cause the LSA to be 603 flushed from all the routers reached by the flooding mechanism. The 604 owner of the LSA will fight back by issuing a new LSA with age set to 605 0 and a higher sequence number. Any attack exploiting this 606 vulnerability could cause unnecessary flooding and refreshing of the 607 Link State Database, hence making the routing information 608 inconsistent. Routers that do not have a copy of the LSA in their 609 Link State Databases will not contribute to the flushing of it, this 610 can help the owner of the LSA in its fight back [9]. 612 4.2.4.2.2. LS sequence number (Max Sequence Number Attack) 614 This is an implementation bug that has been published long ago [10] 615 and not a protocol vulnerability. Nonetheless it is listed in this 616 memo for historical reasons and because at least one recent 617 implementation of OSPF was still affected by it. 619 The bug concerns sequence numbers roll-over. When an LSA reaches its 620 maximum (0x7FFFFFFF) value it is not flushed by flooding it with its 621 age set to MaxAge; instead, the erroneous implementation will simply 622 re-issue the LSA with a rolled-over sequence number. Any newer 623 instance will always be considered outdated when compared to the old 624 one having the LS sequence number set to the maximum value. Thus, an 625 insider attacker could install a bogus LSA on all routers for a 626 MaxAge-long interval without any effective fight back from the owner 627 of the LSA [10]. 629 4.2.4.3. Router Link State Advertisement 631 4.2.4.3.1. Remove, add routers to the domain 633 It is possible to tamper with the topology of a domain by introducing 634 phantom OSPF routers through bogus Router LSAs. Depending on how 635 said phantom OSPF nodes are claiming to be interconnected with each 636 other and with real OSPF peers, they may or may not be utilized by 637 the SPF algorithms present in other OSPF peers. A similar situation 638 applies when a Router LSA is maliciously flushed impacting routes 639 across the domain. Adding or deleting OSPF routers through bogus 640 existing router LSAs will trigger a fight back reaction by the owner 641 of the LSA, except under the circumstances stated in Section 4.1.3. 643 4.2.4.3.2. E Bit 645 A Router LSA carrying the E bit set to 1 automatically allows a 646 router to introduce External LSAs in the routing domain. This could 647 be exploited to escalate a normal router into an ASBR. 649 Setting the E bit to 1 on Router LSAs will trigger a fight back 650 reaction by the owner of the LSA, except under the circumstances 651 stated in Section 4.1.3. 653 4.2.4.3.3. Link ID, Link data 655 Adding links (stub or transit) to any Router LSA will result in 656 adversely impacting the normal flow of data-traffic through the 657 domain. The same applies in the case of a Router LSA omitting any 658 link previously present. More specifically: advertised stub networks 659 are not verifiable by the Shortest Path First algorithms running on 660 other routers present in the same Area. So, if a bogus Router LSA 661 lists a stub network matching the network address of any existing 662 remote network, other OSPF routers will actually consider the router 663 owner of this LSA as a possible path to said remote network. This 664 implies that a malicious or faulty entity advertising bogus stub 665 networks could attract traffic towards itself and/or deviate normal 666 routing across the domain. 668 Adding any kind of link to a Router LSA will trigger fight back by 669 the owner of the LSA, except under the circumstances stated in 670 Section 4.1.3. 672 4.2.4.3.4. Metric 674 The metric fields of an LSA can be modified in the attempt to affect 675 the SPF algorithm. Such operation could serve the purpose of 676 attracting traffic to a node for eavesdropping or overloading; on the 677 other hand, it could also be used for starving a given node. 679 Modifying the fields of a Router LSA regarding a link's metric will 680 trigger a fight back reaction by the owner of the LSA, except under 681 the circumstances stated in Section 4.1.3. 683 4.2.4.4. Network Link State Advertisement 685 4.2.4.4.1. Remove or add links to a domain 687 It is possible to tamper with the topology of a domain by introducing 688 phantom transit links through bogus Network LSAs. Depending on how 689 said phantom transit links are connected to real or phantom OSPF 690 routers, the bogus nodes may or may not be utilized by the SPF 691 algorithms present in other OSPF peers. A similar situation applies 692 where an existing transit link is maliciously flushed impacting 693 routes across the domain. 695 Adding or subtracting transit links through bogus Network LSAs will 696 trigger a fight back reaction by the owner of the LSA, except under 697 the circumstances stated in Section 4.1.3. 699 4.2.4.4.2. Attached Router 701 It is possible to add or eliminate nodes from a transit link by 702 tampering with the list of attached routers. If a legitimate node is 703 removed from this list, that router will be considered disconnected 704 by all the remaining OSPF peers in the domain, even though its Router 705 LSA will state the opposite. There must be consistency between 706 Network and Router LSAs for a router to be considered part of a link. 708 Subtracting a router from the list of attached routers through a 709 bogus Network LSA will trigger a fight back reaction by the owner of 710 the LSA, the DR for the network link, except under the circumstances 711 stated in Section 4.1.3. 713 4.2.4.5. Summary Link State Advertisement 715 It is possible to add or eliminate information contained in both 716 types of Summary Link State LSA affecting routes across different 717 Areas. 719 Forging bogus Summary Link State LSAs will trigger a fight back 720 reaction by the owner of the LSA, except under the circumstances 721 stated in Section 4.1.3. 723 4.2.4.6. AS External Link State Advertisement 725 Every external route introduced by an ASBR is advertised by a single 726 External LSA. There is no way for OSPF routers to verify the 727 information carried by External LSA messages. Introduction of bogus 728 External LSAs will affect the domain's knowledge of the outside 729 world. Bogus External LSAs can be used to attract a portion of the 730 data traffic destined outside the domain to a specific node for 731 eavesdropping or overloading purposes. The same considerations apply 732 to any attempt to starve one or more nodes. 734 Introducing false External LSAs will trigger a fight back reaction by 735 the owner of the LSA and/or will not be recognized as legitimate 736 information by other routers if the LSA is forged on behalf of anon- 737 ASBR router, except under the circumstances stated in Section 4.1.3. 739 4.2.4.6.1. Forward 741 The Forward field of an External LSA specifies the host (OSPF router 742 or not) meant to be used as gateway for that external route; said 743 host can be located everywhere in the domain including Stub Areas. 744 If this field is forged and the forward host is not an OSPF router 745 then there will be no OSPF fight back from the host itself, but there 746 may be a fight back reaction from the ASBR owner of the LSA. By 747 exploiting this feature, an attacker could redirect traffic destined 748 outside the routing domain to any given host in the domain which may, 749 or may not, be under its control. For example, this can be used to 750 generate loops between an ABR and any of its neighbors located in its 751 Stub Area, simply by mentioning one of these neighbors in the forward 752 field of an External LSA advertisement for traffic destined outside 753 the domain. 755 Forging bogus AS External LSAs with modified Forward field 756 information will trigger a fight back reaction by the owner of the 757 LSA, except under the circumstances stated in Section 4.1.3. 759 4.3. Resource Consumption Vulnerabilities 761 Every resource may be exploited in the attempt to interfere with 762 traffic flows from legitimate users. In some cases the resource may 763 be so overwhelmed by malicious/illegitimate packets that legitimate 764 users will not only experience a drop in the performance of the 765 service, but they may be even prevented from accessing the service 766 itself. If one, or more, critical resource of a router is busy 767 serving bogus traffic, or dropping malicious routing messages, then 768 the whole router will be impacted and enter a delicate and more 769 vulnerable state. Next is a list of possible weaknesses that can be 770 exploited to produce a resource consumption attack. 772 4.3.1. OSPF Cryptographic Authentication 774 With Cryptographic Authentication disabled both outsider and insider 775 entities - including attackers and faulty routers - can successfully 776 forge malicious/erroneous OSPF messages that will be in the position 777 to attack a router or exhaust its control plane resources, such as 778 queues and CPU cycles. 780 On the other hand, when Cryptographic Authentication is enabled, only 781 insiders may successfully force malicious OSPF messages to be 782 accepted by the victim's control plane. Unfortunately though, 783 outsider entities are still in the position to generate a powerful 784 resource consumption attack by intentionally exploiting the 785 Cryptographic Authentication mechanism itself as described in [3]. 786 These entities may inject OSPF packets with bogus cryptographic 787 information that will consume critical resources only to be discarded 788 afterward. This will impact OSPF by delaying or even preventing 789 legitimate messages to be authenticated and used. 791 4.3.2. Hello Message 793 4.3.2.1. DR and BDR Election 795 Hello messages are used by OSPF also to carry out the DR and BDR 796 election process. The DR election process itself presents a possible 797 resource consumption vulnerability since it may be fooled into 798 electing a new DR at every run. When a new DR is elected all routers 799 on the network will have to use resources to establish adjacency with 800 this new DR; the same applies in the case of the BDR. 802 4.3.2.2. Number of Neighbors 804 OSPF routers create a neighbor data structure for each neighbor 805 discovered through the Hello protocol. The resources to store this 806 information could be exhausted on a broadcast or NBMA network with a 807 large host address range. 809 4.3.2.3. Message Size 811 Since a router must list all its current active neighbors in each of 812 its Hello messages, it may have to issue a Hello message bigger than 813 the Layer 2 media's MTU, e.g. bigger than the Ethernet frame's size. 814 Since this is usually a delicate area in implementation and design 815 all the necessary care should be exerted. 817 4.3.3. Link State Request Message 819 Any Link State Request message forces the destination router to reply 820 with a Link State Update message containing the requested LSA. An 821 insider attacker, or a faulty router, could mount a resource 822 consumption attack by continuously requesting Link State information 823 from its neighbors at any desired rate. 825 4.3.4. Link State Acknowledgment Message 827 Not acknowledging Link State Update messages forces the originating 828 peer to keep a copy of the LSU on the retransmission list; this leads 829 to re-transmission loops wasting resources on both sides. 831 4.3.5. Link State DB Overflow 833 4.3.5.1. Router/Network LSA 835 Router/Network LSAs received from non-existing OSPF peers will not be 836 used by the SPF algorithm and will not directly adverse the routes 837 nor the topology. Nonetheless, these LSAs will consume resources in 838 the Link State Database and will not be removed from this database 839 until they "naturally" expire after MaxAge (1 hour). If the purpose 840 of an attacker is to simply consume database resources, then crafting 841 LSAs on behalf of non-existing OSPF routers is a good option since it 842 makes the effects of the attack last longer and triggers no fight 843 back reaction at all. Finally, it is important to highlight that 844 Link State Database overflows produced by Router and Network LSAs 845 will not be limited by the mitigation mechanism detailed in RFC1765 846 [11]. 848 4.3.5.2. External LSA 850 External LSAs may also be successfully exploited in the attempt to 851 fill Link State Database resources. If these LSAs are crafted on 852 behalf of non-existing ASBRs, their information will not be used by 853 any SPF algorithm; however they will be successfully installed in the 854 Link State Databases. Moreover, External LSAs are forwarded to all 855 routers in the domain (except routers located in Stub Areas), expire 856 only after MaxAge if no fight back is place, and are never 857 consolidated by OSPF. 859 4.3.5.3. Link State Database Description Messages 861 The Database Exchange process poses a resource consumption threat on 862 the slave router participating to the process. An insider attacker - 863 or a faulty router - capable of leading a victim into the Database 864 Exchange process could advertise a huge list of non-existing links 865 through Database Description messages. The victim will keep updating 866 this list and start asking for details via Link State Request 867 messages. The number of bogus links that the victim router will have 868 to store poses an immediate resource consumption threat, while the 869 prolonged request for details about the bogus LSAs will keep the 870 victim's retransmission list full and busy. 872 4.3.5.4. Retransmission List Exhaustion 874 Any LSU that is not acknowledged is put on a re-transmission list. 875 OSPF messages present in this list are sent over regular intervals 876 until they are acknowledged by the receivers. Failing to acknowledge 877 LSUs, accidentally or voluntarily, will trigger resource consumption 878 on the remote peer's retransmission mechanisms. 880 4.3.6. Others 882 4.3.6.1. Routing table size/performance issue 884 Increasing the size of the routing table could potentially move a 885 router into a very delicate state and eventually reach the limits 886 assigned to some resources. This could be achieved by using Router, 887 Network or External LSAs from existing peers and somehow disabling 888 the fight back from the legitimate owners. 890 4.3.6.2. Fragmentation 892 Fragmentation of OSPF messages due to Layer 2 MTU is a crucial factor 893 for any given implementation; any situation involving such process 894 should be carefully tested. For example in the case of a router 895 running the open source routing suite Zebra over Ethernet links, 896 receiving a forged Router LSA that claims to have more than 118 links 897 will adversely impact the routing daemon. Even though the LSA does 898 not violate RFC2328, which states that a Router LSA must be entirely 899 contained into one single IP packet, a Router LSA listing more than 900 118 links does exceed the Ethernet MTU and will be fragmented over 901 multiple Ethernet frames: this seems to have a serious impact on the 902 behavior of Zebra. 904 4.4. Vulnerabilities through Other Protocols 905 4.4.1. IP 907 OSPF runs directly over IP. Therefore, OSPF is subject to attack 908 through attacks on IP. Direct attacks against the IP stack of a 909 router, such as integrity and fragmentation attacks, will impact OSPF 910 but are clearly beyond the scope of this document. 912 4.4.2. Other Supporting Protocols (Management) 914 The security of OSPF is inherently dependent on the security of the 915 managing procedures. Critical examples are the configuration of the 916 state of any interface, the Manual Stop procedure and the Timer 917 Values. 919 4.4.2.1. Manual stop 921 A manual stop event causes the OSPF router to bring down all its 922 adjacencies, release all associated OSPF resources, and delete all 923 associated routes. If the mechanisms by which an OSPF router was 924 informed of a manual stop is not carefully protected, OSPF 925 connections could be destroyed by an attacker. Consequently, OSPF 926 security is secondarily dependent on the security of whatever 927 protocols are used to operate the platform. 929 4.4.2.2. Timer events 931 The RxmtInterval, InfTransDelay, RouterDeadInterval, HelloInterval 932 timers together with the RouterPriority parameter are critical to 933 OSPF operation. For example, if the HelloInterval timer value is 934 changed, all remote peers will refuse Hello messages from that router 935 and after RouterDeadInterval bring the adjacency down. Consequently, 936 OSPF security is secondarily dependent on the security of the 937 protocols by which the platform is managed and configured. 939 4.5. Residual Risk 941 OSPF Cryptographic Authentication assumes that the cryptographic 942 algorithms are secure, that the secrets used are protected from 943 exposure and are chosen well so as not to be guessable, that the 944 platforms are securely managed and operated to prevent break-ins, 945 etc. 947 Information theory states that the English language has about 1.3 948 bits of entropy for each 8-bit character. If an administrator were 949 to choose the secret key for the Cryptographic Authentication to be 950 any English word, the entropy associated to the secret key protecting 951 the session would be drastically reduced from 128 bits to the point 952 where it could be guessed in a matter of minutes or days. On top of 953 that, Common Line Interfaces (CLI) will generally limit the key input 954 to a specific subset of ASCII characters - letters and number plus a 955 few symbols - and will not accept a 128-bits number value (for 956 example in hexadecimal format). 958 This becomes crucial in all those cases where the secret defending an 959 OSPF adjacency is poorly chosen and changed once every three months, 960 or every year, or never. In all these scenarios an attacker that 961 somehow managed to obtain a copy of a single OSPF Hello message may 962 eventually be able to crack the secret key and attack the entire 963 routing domain for a prolonged period of time. 965 5. IANA Considerations 967 This document has no actions for IANA 969 6. Security Considerations 971 This document is security related and discusses threats against the 972 OSPF routing protocol. 974 7. References 976 7.1. Normative References 978 [1] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 980 7.2. Informative References 982 [2] Ferguson, P. and D. Senie, "Network Ingress Filtering: 983 Defeating Denial of Service Attacks which employ IP Source 984 Address Spoofing", BCP 38, RFC 2827, May 2000. 986 [3] Zinin, A., "Protecting Internet Routing Infrastructure from 987 Outsider DoS Attacks", draft-zinin-rtg-dos-02 (work in 988 progress), May 2005. 990 [4] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to 991 Routing Protocols", draft-ietf-rpsec-routing-threats-07 (work 992 in progress), October 2004. 994 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 995 Levels", BCP 14, RFC 2119, March 1997. 997 [6] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on 998 Security Considerations", draft-iab-sec-cons-00 (work in 999 progress), August 2002. 1001 [7] Wang, F. and S. Wu, "On the Vulnerabilities and Protection of 1002 OSPF Routing Protocols", IEEE Comp. Soc. Proceedings 7th 1003 International Conference on Computer Communications and 1004 Networks: 148-152. Los Alamitos, CA, 1998. 1006 [8] Etienne, J., "Flaws in Packet's Authentication of OSPFv2", 1007 draft-etienne-ospv2-auth-flaws-00 (work in progress), 1008 November 2001. 1010 [9] Murphy, S., "Retrofitting Security into Internet Infrastructure 1011 Protocols.", DISCEX '00 Proceedings of DARPA Information 1012 Survivability Conference and Exposition, 2000. 1014 [10] Vetter, B., Wang, F., and S. Wu, "An Experimental Study of 1015 Insider Attacks for the OSPF Routing Protocol", IEEE 5th IEEE 1016 International Conference on Network Protocols, Atlanta, GA, 1017 Oct 28-31, 1997. 1019 [11] Moy, J., "OSPF Database Overflow", RFC 1765, March 1995. 1021 Authors' Addresses 1023 Emanuele Jones 1024 Alcatel 1025 3400 W. Plano Pkwy. 1026 Plano, TX 75075 1027 USA 1029 Email: emanuele.jones@alcatel.com 1030 URI: http://www.alcatel.com/ 1032 Olivier Le Moigne 1033 Alcatel 1034 600 March Road 1035 Ottawa, ON K2K 2E6 1036 Canada 1038 Email: olivier.le_moigne@alcatel.com 1039 URI: http://www.alcatel.com/ 1041 Intellectual Property Statement 1043 The IETF takes no position regarding the validity or scope of any 1044 Intellectual Property Rights or other rights that might be claimed to 1045 pertain to the implementation or use of the technology described in 1046 this document or the extent to which any license under such rights 1047 might or might not be available; nor does it represent that it has 1048 made any independent effort to identify any such rights. Information 1049 on the procedures with respect to rights in RFC documents can be 1050 found in BCP 78 and BCP 79. 1052 Copies of IPR disclosures made to the IETF Secretariat and any 1053 assurances of licenses to be made available, or the result of an 1054 attempt made to obtain a general license or permission for the use of 1055 such proprietary rights by implementers or users of this 1056 specification can be obtained from the IETF on-line IPR repository at 1057 http://www.ietf.org/ipr. 1059 The IETF invites any interested party to bring to its attention any 1060 copyrights, patents or patent applications, or other proprietary 1061 rights that may cover technology that may be required to implement 1062 this standard. Please address the information to the IETF at 1063 ietf-ipr@ietf.org. 1065 Disclaimer of Validity 1067 This document and the information contained herein are provided on an 1068 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1069 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1070 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1071 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1072 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1073 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1075 Copyright Statement 1077 Copyright (C) The Internet Society (2006). This document is subject 1078 to the rights, licenses and restrictions contained in BCP 78, and 1079 except as set forth therein, the authors retain all their rights. 1081 Acknowledgment 1083 Funding for the RFC Editor function is currently provided by the 1084 Internet Society.