idnits 2.17.00 (12 Aug 2021) /tmp/idnits56081/draft-ietf-rpsec-ospf-vuln-00.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 a Security Considerations section. ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 291 has weird spacing: '... itself as de...' == 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 (May 2004) is 6580 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) -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Downref: Normative reference to an Experimental RFC: RFC 1765 (ref. '10') Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Emanuele Jones 3 INTERNET DRAFT Alcatel 4 draft-ietf-rpsec-ospf-vuln-00.txt Olivier Le Moigne 5 Alcatel 6 May 2004 8 OSPF Security Vulnerabilities Analysis 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet- Drafts as 23 reference material or to cite them other than as "work in progress". 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 Specification of Requirements 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in RFC2119. 37 Abstract 39 Internet infrastructure protocols were designed at the very early 40 stages of computer networks when "cyberspace" was still perceived as 41 a benign environment. As a consequence, malicious attacks were not 42 considered to be a major risk when these protocols were designed, 43 leaving today's Internet vulnerable. This paper provides an analysis 44 of OSPF vulnerabilities that could be exploited to modify the normal 45 routing process across a single domain together with an assessment 46 of when internal OSPF mechanisms can or cannot be leveraged to 47 better secure a domain. 49 Table of Contents 51 Status of this Memo ........................................... 1 52 Specification of Requirements ................................. 1 53 Abstract ...................................................... 1 54 1. Introduction ............................................... 3 55 1.1. Attacker's Definition .................................... 3 56 1.2. Attacker's Location ...................................... 4 57 1.3. Vulnerabilities Damages and Consequences ................. 4 58 2. Generic Attack Techniques .................................. 5 59 3. Vulnerabilities and Risks .................................. 6 60 3.1. OSPF General Vulnerabilities ............................. 6 61 3.1.1. Local Intrusion Global Impact .......................... 6 62 3.1.2. Remote Attacker ........................................ 7 63 3.1.3. Attacker Disabling Fight Back .......................... 7 64 3.1.4. Attacker Leveraging Fight Back ......................... 8 65 3.1.5. Dealing with External Routes ........................... 8 66 3.2. Protocol-specific Vulnerabilities ........................ 9 67 3.2.1. Packet Header with Cryptographic Authentication Enabled. 9 68 3.2.2. Hello Message .......................................... 10 69 3.2.3. DB Description, Link State Request and Acknowledgment .. 12 70 3.2.4. Link State Update ...................................... 12 71 3.3. Resource Consumption Vulnerabilities ..................... 15 72 3.3.1. OSPF Cryptographic Authentication ...................... 15 73 3.3.2. Hello Message .......................................... 16 74 3.3.3. Link State Request Message ............................. 16 75 3.3.4. Link State Acknowledgment Message ...................... 16 76 3.3.5. Link State DB Overflow ................................. 16 77 3.3.6. Others ................................................. 17 78 3.4. Vulnerabilities through Other Protocols .................. 18 79 3.4.1. IP ..................................................... 18 80 3.4.2. Other Supporting Protocols (Management) ................ 18 81 3.5. Residual Risk ............................................ 18 82 4. References ................................................. 19 83 5. Authors' Addresses ......................................... 20 85 1. Introduction 87 Internet infrastructure protocols were designed at the very early 88 stages of computer networks when "cyberspace" was still perceived as 89 a benign environment. As a consequence, malicious attacks were not 90 considered to be a major risk when these protocols were designed, 91 leaving today's Internet infrastructure vulnerable. 93 Since routers work in a cooperatively manner based on forwarding 94 network information received from their peers, they are all 95 threatened by the possibility that the exchanged routing information 96 may have been contaminated or forged by a malicious or faulty 97 entity. 99 This paper provides an analysis of OSPF [1] vulnerabilities that 100 could be exploited to modify the normal routing process across a 101 single domain, together with an assessment of when internal OSPF 102 mechanisms can or cannot be leveraged to secure a domain. 104 1.1. Attacker's Definition 105 Throughout this paper the term attacker will be used to define any 106 entity capable of posing any threat to an OSPF routing domain. 107 Hence, this definition includes: 1) any subverted OSPF router, 2) 108 any malicious software capable of interacting with an OSPF routing 109 domain, 3) any faulty or misconfigured legitimate OSPF peer. 111 From a security standpoint, this paper is consolidating all possible 112 OSPF deployment situations into two opposite scenarios. 114 The first scenario requires OSPF Cryptographic Authentication or 115 Simple Password Authentication to be present on all links within a 116 routing domain. The second scenario takes place when Null 117 Authentication is adopted. 119 If one link is not protected then the whole routing domain becomes 120 potentially vulnerable; if the attacker is in the position to obtain 121 even a single copy of any OSPF message then the authentication 122 provided by Simple Password is compromised and the security for the 123 entire routing domain falls immediately in the second scenario. 125 In the first scenario, Cryptographic Authentication being deployed, 126 there are two kinds of entities capable of attacking or posing 127 threats: insiders and outsiders. An attacking entity is considered 128 an insider if it is in possession of the secret key for any OSPF 129 Cryptographic Authentication session either through: cryptanalysis, 130 social engineering, coercion or access to a compromised/subverted 131 routing resource. This also includes threats arising from 132 malfunctioning or faulty-configured OSPF routers. An outsider is an 133 attacker that is not in possession of the secret key. 135 In the second scenario, when the routing domain is not protected by 136 OSPF Cryptographic or Simple Password authentication there is no 137 distinction between insider and outsider entities. Any attacker can 138 successfully forge OSPF messages on behalf of any OSPF peer, 139 legitimate or not. 141 1.2. Attacker's Location 142 Since OSPF routers on broadcast, on Point-to-Multipoint, NBMA and on 143 virtual links will accept unicast packets that are destined directly 144 to them, no assumption is made on the location of the attacking 145 entity. This leads to a scenario where an attacker, in possession of 146 a secret key, if at all needed, can attack a router located in a 147 remote routing domain. The proper implementation of ingress 148 filtering and other mechanisms described by RFC2827 [2] and 149 recently by the Internet Draft [3] should mitigate this situation, 150 forcing insider and outsider attackers to at least have access to 151 one of the links in the routing domain target of their attack. 153 1.3. Vulnerabilities Damages and Consequences 154 Generally speaking attackers will be able to disrupt and manipulate 155 the routing domain, posing serious threats to the actual delivery of 156 data and control plane packets. 158 For instance, if the routing information creates loops in the 159 forwarding path some packets will never be delivered, denying 160 service to many destinations. Loops also create congestion by 161 leaving packets in the network longer than necessary and by 162 consuming resources without providing any useful service in the end. 163 The incorrect forwarding of large amounts of traffic over one link 164 may overwhelm the link and result in the delaying, or even 165 prevention, of traffic delivery. Moreover, incorrect routing 166 information could result in data traffic transiting networks that 167 otherwise would have never seen that data. 169 Finally, routing information that incorrectly reports OSPF Areas, or 170 any other portion of the domain, as unreachable will deny services 171 to all hosts connected to or exchanging traffic with said areas. 173 The damages [4] that might result from these attacks are: 175 starvation: data traffic destined for a node is forwarded to a part 176 of the network that cannot deliver it, 178 network congestion: more data traffic is forwarded through some 179 portion of the network than would otherwise need to carry the 180 traffic, 182 blackhole: large amounts of traffic are directed as to be forwarded 183 through one router that cannot handle the increased level of traffic 184 and drops many/most/all packets, 185 delay: data traffic destined for a node is forwarded along a path 186 that is in some way inferior to the path it would otherwise take, 188 looping: data traffic is forwarded along a path that loops, so that 189 the data is never delivered, 191 eavesdrop: data traffic is forwarded through some router or network 192 that would otherwise not see the traffic, affording an opportunity 193 to see the data, 195 partition: some portion of the network believes that it is 196 partitioned from the rest of the network when it is not, 198 cut: some portion of the network believes that it has no route to 199 some network that is in fact connected, 201 churn: the forwarding in the network changes at a rapid pace, 202 resulting in large variations in the data delivery patterns (and 203 adversely affecting congestion control techniques), 205 instability: OSPF becomes unstable so that convergence on a global 206 forwarding state is not achieved, 208 overload: the OSPF messages themselves become a significant portion 209 of the traffic the network carries. 211 resource exhaustion: the OSPF messages themselves cause exhaustion 212 of critical router resources, such as table space and queues. 214 These consequences can fall exclusively on a single OSPF Area or may 215 effect the operation of the OSPF network domain as a whole. 217 2. Generic Attack Techniques 219 The OSPF protocol is subject to the following attacks (list taken 220 from the IAB Internet-Draft providing guideline for the security 221 considerations section of Internet-Drafts [5]). 223 Eavesdropping: The routing data carried in OSPF is carried in clear- 224 text, so eavesdropping is a possible attack against routing data 225 confidentiality. 227 Message Replay: In general, OSPF with Cryptographic Authentication 228 provides a sufficient mechanism for replay protection of its 229 messages. Nonetheless, there are still some scenarios in which an 230 outsider attacker can successfully replay OSPF messages; these are 231 illustrated over the next sections. 233 Message Insertion: OSPF with Cryptographic Authentication enabled is 234 not vulnerable to message insertion from outsiders. In the case of 235 an insider or in the absence of Cryptographic Authentication, 236 message insertion becomes a trivial operation even for a remote 237 attacker. 239 Message Deletion: OSPF provides a certain degree of protection 240 against message deletion. The receiver itself cannot detect if a 241 message has been deleted or not, but the sender will detect a 242 deleted Link State Update (LSU) message since it will not receive 243 any OSPF Link State Acknowledgment message for it. There is no 244 acknowledging mechanism for Hello messages, but the deletion of 245 some, generally four or more, consecutive Hello messages belonging 246 to the same router will cause "adjacency breaking" and thus be 247 easily detected by all the parties involved. 249 Message Modification: OSPF with Cryptographic Authentication 250 provides protection against modification of messages. In the case of 251 an insider or in the absence of Cryptographic Authentication message 252 modification becomes possible. 254 Man-In-The-Middle: OSPF with Cryptographic Authentication provides 255 protection against man-in-the-middle attacks. In the case of an 256 insider or in the absence of Cryptographic Authentication, the 257 protocol becomes exposed to man-in-the-middle attacks through the 258 lower network layers - such as ARP spoofing - on all OSPF peers that 259 are one hop apart; while OSPF peers connected over virtual links are 260 exposed to Layer 3 man-in-the-middle attacks too. 262 Denial-of-Service: While bogus routing information data can 263 represent a Denial of Service attack on the end systems that are 264 trying to transmit data through the network and on the network 265 infrastructure itself, certain bogus information can represent a 266 more specific Denial of Service on the OSPF routing protocol itself. 267 For example, it is possible to reach the limits of the Link State 268 Database of a victim with External LSAs or with bogus LSA headers 269 during the Link State Database Exchange phase. 271 3. Vulnerabilities and Risks 273 3.1. OSPF General Vulnerabilities 274 The risks in OSPF arise from the following fundamental 275 vulnerabilities: 277 3.1.1. Local Intrusion Global Impact 278 Compromising a single network equipment (router) or a link's 279 security has an obvious and immediate local impact (ability to 280 disable local links, to change properties, to stop routers etc...). 281 Unfortunately, due to the lack of end-to-end authentication 282 mechanisms - such as a Public Key Infrastructure (PKI) - a breach in 283 a single link has also a global impact since the attacker is now in 284 the position to tamper with information regarding any other remote 285 network equipment belonging to the same routing domain. 287 3.1.2. Remote Attacker 288 Even though OSPF is designed and deployed to be used as an intra- 289 domain routing protocol, in most scenarios and situations an OSPF 290 router will still accept unicast IP packets directly addressed to 291 itself as described in paragraph 8.1 of RFC2328 [1]. "On physical 292 point-to-point networks, the IP destination is always set to the 293 address AllOSPFRouters. On all other network types (including 294 virtual links), the majority of OSPF packets are sent as unicasts, 295 i.e., sent directly to the other end of the adjacency." This opens 296 the door to attacks that may be originating from outside the OSPF 297 domain. Timing the stream of different packets needed for a given 298 attack poses a certain degree of difficulty if executed from a 299 remote AS, but it may not be enough to stop a skilled and motivated 300 attacker. This means that, for example, customers on the access 301 edges of a network can start attacking the routing domain in the 302 core, if said domain were not to be protected by Cryptographic 303 Authentication or if the malicious subscribers were to obtain the 304 secret key. 306 3.1.3. Attacker Disabling Fight Back 307 It is often the case while reading papers, or other literature 308 material, about OSPF to come across the concept of an OSPF "natural" 309 fight back mechanism, for example [6]. OSPF fight back can be 310 defined as follows: any router receiving an LSA that lists itself as 311 the advertising router and noticing that the content of this LSA is 312 not coherent with its status of resources will try to correct the 313 situation either by flushing or updating the erroneous LSA. The 314 following three scenarios show how the OSPF fight back mechanism can 315 be disabled clearing the way to stealthy attacks. 317 3.1.3.1 Periodic Injection 318 This is a brief explanation on how a malicious LSA will succeed in 319 attacking a routing domain, overriding any fight back: 321 According to RFC2328 [1], a router will never emit (or update) its 322 LSAs faster than once every MinLSInterval (5 seconds). This allows 323 for almost permanent changes in the routing domain, if an attacker 324 is flooding the OSPF domain with malicious LSAs at a rate higher 325 than one every MinLSInterval. 327 On top of this, if an OSPF implementation behaves as described by 328 RFC2328 [1, paragraph 13], the router owner of the LSA may never 329 fight back and it will collaborate in the flooding of malicious 330 routing information on its behalf. The flooding happens because the 331 malicious LSA is considered newer than the copy already present in 332 the legitimate owner's Link State Database - the malicious LSA will 333 have a higher sequence number - (check performed on Step 5) and 334 because the legitimate copy of the LSA already present in the Link 335 State Database was not received via flooding but installed by the 336 router itself (check performed in step 5.a). When step 5.f is 337 finally executed - after the malicious LSA has been already flooded 338 - a simple test reveals that the LSA was owned by the router and 339 that it contained erroneous information. Only at this stage action 340 is taken to correct it; but since any router must wait MinLSInterval 341 before updating any of its LSAs, the owner will fight back every 342 MinLSInterval while the flooding is in progress. We have also 343 observed a complete lack of fight back in implementations that 344 erroneously reset MinLSInterval when flooding LSAs. 346 3.1.3.2 Partitioned Networks 347 If the flooding mechanism does not have a path to rely malicious 348 LSAs to the legitimate owner, said owner will never initiate a fight 349 back. An example of this could be a subverted router conveniently 350 located on a partitioning link. If said router is removed, the 351 entire network domain would be partitioned into two disconnected 352 portions. This subverted router could choose to inject a given 353 malicious LSA only into one part of the routing domain, claiming 354 that this LSA is coming from a legitimate router located on the 355 opposite portion of the network. The legitimate router will never be 356 made aware of the forged information on its behalf and thus will 357 never initiate a fight back. This will create fatal inconsistencies 358 between the Link State Databases of the various OSPF routers. 360 3.1.3.3 Phantom Routers 361 All information injected in the routing domain on behalf of non- 362 existing (phantom) OSPF routers will never trigger a fight back 363 reaction. Thus, this information will remain in the Link State 364 Databases of the legitimate routers for MaxAge (1 hour, by default). 365 It is important to underline that even if Link State Advertisements 366 (LSAs) crafted on behalf of phantom routers are kept in the Link 367 State Database, these are not taken into account by the Shortest 368 Path First (SPF) algorithm. 370 3.1.4. Attacker Leveraging Fight Back 371 The fight back mechanism can contribute to amplify certain Denial of 372 Service attacks. One single false LSA may unleash a significant 373 number of LSA updates that are trying to correct it. Even though 374 such a reaction is both efficient and desirable, it may be leveraged 375 to amplify the effects of certain Denial of Service attacks, if 376 continuously triggered. 378 3.1.5. Dealing with External Routes 379 Every piece of routing information that is dealing with outside 380 routes, forged or real, that is introduced in the domain - by means 381 of route redistribution via BGP, RIP or any other routing protocol 382 including statically configured - cannot be verified and it is 383 propagated to all OSPF Areas of the domain that are not configured 384 as stub-areas or NSSA. Even though verification of routes that are 385 outside the routing domain is clearly beyond the scope of OSPF, the 386 current flooding mechanism of such information may be used as an 387 efficient intrinsic vector for conveying malicious/bogus messages. 388 Moreover, if an attacker manages to subvert an ASBR node, or 389 successfully masquerades as one, there will be no fight back from 390 any of the other ASBRs regarding ownership, validity and metric 391 advertisement for the External routes claimed by the subverted ASBR; 392 thus, the attacker could easily attract to itself big portions of 393 the traffic destined outside the AS. 395 3.2. Protocol-specific Vulnerabilities 396 There are two types of authentication mechanisms in OSPF: Simple 397 Password and Cryptographic. Simple Password authentication consists 398 of a plain text password carried in the header of each OSPF message; 399 the vulnerability of this Authentication method is obvious and will 400 not be discussed further. There are five different OSPF message 401 types: Hello, Database Description, Link State Request, Link State 402 Update, Link State Acknowledgement. The next sections discuss 403 general vulnerabilities for every field in the five OSPF messages as 404 well as the ones arising from Cryptographic Authentication. Each 405 section also defines the ability for outsiders, insiders or faulty 406 OSPF peers to exploit these weaknesses. 408 3.2.1. Packet Header with Cryptographic Authentication Enabled 409 IP Header 410 No field of the IP header is protected by the Message Authentication 411 Code (MAC) available when Cryptographic Authentication is enabled. 412 This poses a threat to OSPF any time the protocol relies on any IP 413 field. For example RFC2328 [1] states on paragraph 10.5: "When 414 receiving an Hello on a point-to-point network (but not on a virtual 415 link) set the neighbor structure's Neighbor IP address to the 416 packet's IP source address". 418 OSPF Header 419 Neighbor OSPF routers may reset their Cryptographic Sequence Number 420 states when a peer reboots (if the "resetting" peer is not capable 421 of storing Cryptographic Sequence Numbers across reboots) or when 422 the peer's Cryptographic Sequence Number rolls over. At this point, 423 any previously logged packet can be maliciously replayed and will 424 look legitimate if the secret key has not changed in the mean time. 425 Moreover, if the replayed packet is chosen with a high enough 426 sequence number, it will block the communication between the 427 recently rebooted router and its peer(s) for RouterDeadInterval plus 428 the time needed to establish a new adjacency [7]. This vulnerability 429 is exploitable by any outsider that is able to log OSPF packets. It 430 is important to underline that this vulnerability could be used to 431 break adjacencies between OSPF peers. 433 Breaking an adjacency will cause an OSPF router to update its own 434 Router LSA which in turn will force a new SPF calculation, this may 435 lead to changes in the routing table due to the loss of one peer. If 436 the router is also the Designated Router (DR) for the link, breaking 437 an adjacency also entails modifying the corresponding link's Network 438 LSA, potentially resulting in transit links being declared as stub 439 connections and/or partitioning of the domain. 441 Finally, even for an insider attacker (with or without the ability 442 to log packets) forging a single Hello message, with a high enough 443 sequence number, is an excellent and quick option to break any 444 established adjacency. In conclusion this vulnerability may be 445 appealing to both outsider and insider attackers. 447 3.2.2. Hello Message 448 In general errors in Hello message parameters such as incorrect 449 AreaID, RouterDeadInterval, HelloInterval and so on will cause the 450 Hello to be silently discarded with no further impact. 452 Other Hello parameters are analyzed next, and in order to modify the 453 following parameters, the attacker must be an insider, i.e. in 454 possession of the secret for the link to be attacked or the link 455 must be configured with the Null Authentication security option. 457 3.2.2.1. Neighbor 458 Omission of one or more adjacent neighbors in the neighbor list will 459 immediately break the adjacency and force a synchronization process 460 between the legitimate owner of the Hello message and all the 461 omitted neighbors. 463 Breaking an adjacency will cause an OSPF router to update its own 464 Router LSA which in turn will force a new SPF calculation, this may 465 lead to changes in the routing table due to the loss of one peer. If 466 the router is also the Designated Router (DR) for the link, breaking 467 an adjacency also entails modifying the corresponding link's Network 468 LSA, potentially resulting in transit links being declared as stub 469 connections and/or partitioning of the domain. 471 3.2.2.2. DR and BDR 472 Tampering with these two fields can lead to several problematic 473 scenarios,(concerning broadcast and NBMA networks) each leading to 474 different consequences for the routing domain. 476 In order to be taken into account by the DR election process on a 477 victim router, the attacker must list the victim router ID into the 478 active neighbor list of its malicious Hello. Next some examples of 479 attacks are described. 481 In the Hello message, setting to null the DR and BDR fields, on 482 behalf of a legitimate router on the network, and listing all 483 neighbors in the malicious Hello, will force a full re-election of 484 the DR and BDR. 486 Bogus Hello messages from a non-existing router, with a Router 487 Priority and an IP address higher than any legitimate router on a 488 network, listing itself as DR will allow the attacker to 489 successfully convince all the routers present in the neighbor list 490 (of the malicious Hello) that the DR has changed. Any router 491 believing in the non-existing DR will update its Router LSA by 492 listing a link to a stub network instead of the transit network 493 (because it is not fully adjacent to the non-existing DR). Thus, 494 this router will not use this network anymore as a transit network; 495 this will lead to connectivity loss. 497 If the attacker is listing the current DR and BDR in the active 498 neighbors, then the current DR and BDR will also be deceived into 499 thinking that the non-existing router is the new DR. This will have 500 an impact on all the routers connected to the network at once. 502 3.2.2.3. Deletion of Hello Messages 503 If no Hello message is received from a given neighbor for a period 504 of time longer than RouterDeadInterval, then the adjacency with this 505 router is considered to be broken. 507 Breaking an adjacency will cause an OSPF router to update its own 508 Router LSA which in turn will force a new SPF calculation, this may 509 lead to changes in the routing table due to the loss of one peer. If 510 the router is also the Designated Router (DR) for the link, breaking 511 an adjacency also entails modifying the corresponding link's Network 512 LSA, potentially resulting in transit links being declared as stub 513 connections and/or partitioning of the domain. 515 3.2.2.4. Hello Message Replay 516 The Hello Replay attack cannot be perpetrated by an outsider as 517 described by [7]. "The HELLO packet lists the recently seen routers, 518 so if an attacker replays a HELLO packet back to its source, the 519 source won't see itself in the list and will deduce the connection 520 isn't bidirectional. [...] On broadcast, NBMA or Point to Multipoint 521 networks, the neighbor is identified by its IP address, so both 522 attacks can be used." [7, paragraphs 3.2.2 and 3.2.3] This clashes 523 with what is stated by RFC2328 [1, paragraph 10.5]: "When receiving 524 a Hello Packet from a neighbor on a broadcast, Point-to-MultiPoint 525 or NBMA network, set the neighbor structure's Neighbor ID equal to 526 the Router ID found in the packet's OSPF header." Zebra seems to be 527 in agreement with the RFC's interpretation provided above and is not 528 vulnerable to the Hello Replay attack. 530 In conclusion, the RouterID field is covered by Cryptographic 531 Authentication and therefore it cannot be modified by an outsider 532 without infringing on the MAC (Message Authentication Code), and if 533 the Hello message is replayed to its owner without modifying 534 anything the RouterID will match the one of the owner and the 535 message will be ignored. 537 3.2.3. DB Description, Link State Request and Acknowledgment 538 There is no clear threat except for an insider attacker, or a faulty 539 router, that behaves as described in the resource consumption 540 section. 542 3.2.4. Link State Update 543 In order to modify the parameters described in the following 544 subsections, the attacker must be able to successfully inject 545 malicious LSUs. Hence, the attacker must either subvert, impersonate 546 or fake a router which is at least in the exchange state or higher. 547 In the two latter cases, the attacker must be an insider, i.e. in 548 possession of the secret key for a link or a link must be configured 549 with the Null Authentication security option. 551 3.2.4.1 Link State Update Header 552 The Link State Update (LSU) Header does not appear to present any 553 vulnerability in and for itself. In the case of attacks involving 554 bogus LSAs, some fields of the LSU header may need to be maliciously 555 modified to be consistent with the bogus information carried by the 556 LSAs. 558 In general, errors in some LSU Header parameters such as incorrect 559 RouterID, AreaID and AuType will cause the LSU to be silently 560 discarded with no further impact. 562 3.2.4.2. Link State Advertisement Header 563 LS age (MaxAge Attack) 564 Setting the age field of an LSA to MaxAge will cause the LSA to be 565 flushed from all the routers reached by the flooding mechanism. The 566 owner of the LSA will fight back by issuing a new LSA with age set 567 to 0 and a higher sequence number. Any attack exploiting this 568 vulnerability could cause unnecessary flooding and refreshing of the 569 Link State Database, hence making the routing information 570 inconsistent. Routers that do not have a copy of the LSA in their 571 Link State Databases will not contribute to the flushing of it, this 572 can help the owner of the LSA in its fight back [8]. 574 LS sequence number (Max Sequence Number Attack) 575 This is an implementation bug that has been published long ago [9] 576 and not a protocol vulnerability. Nonetheless it is listed in this 577 memo for historical reasons and because at least one recent 578 implementation of OSPF was still affected by it. 580 The bug concerns sequence numbers roll-over. When an LSA reaches its 581 maximum (0x7FFFFFFF) value it is not flushed by flooding it with its 582 age set to MaxAge; instead, the erroneous implementation will simply 583 re-issue the LSA with a rolled-over sequence number. Any newer 584 instance will always be considered outdated when compared to the old 585 one having the LS sequence number set to the maximum value. Thus, an 586 insider attacker could install a bogus LSA on all routers for a 587 MaxAge-long interval without any effective fight back from the owner 588 of the LSA [9]. 590 3.2.4.3. Router Link State Advertisement 591 Remove, add routers to the domain 592 It is possible to tamper with the topology of a domain by 593 introducing phantom OSPF routers through bogus Router LSAs. 594 Depending on how said phantom OSPF nodes are claiming to be 595 interconnected with each other and with real OSPF peers, they may or 596 may not be utilized by the SPF algorithms present in other OSPF 597 peers. A similar situation applies when a Router LSA is maliciously 598 flushed impacting routes across the domain. Adding or deleting OSPF 599 routers through bogus existing router LSAs will trigger a fight back 600 reaction by the owner of the LSA, except under the circumstances 601 stated in paragraph 3.1.3. 603 E Bit 604 A Router LSA carrying the E bit set to 1 automatically allows a 605 router to introduce External LSAs in the routing domain. This could 606 be exploited to escalate a normal router into an ASBR. 608 Setting the E bit to 1 on Router LSAs will trigger a fight back 609 reaction by the owner of the LSA, except under the circumstances 610 stated in paragraph 3.1.3. 612 Link ID, Link data 613 Adding links (stub or transit) to any Router LSA will result in 614 adversely impacting the normal flow of data-traffic through the 615 domain. The same applies in the case of a Router LSA omitting any 616 link previously present. More specifically: advertised stub networks 617 are not verifiable by the Shortest Path First algorithms running on 618 other routers present in the same Area. So, if a bogus Router LSA 619 lists a stub network matching the network address of any existing 620 remote network, other OSPF routers will actually consider the router 621 owner of this LSA as a possible path to said remote network. This 622 implies that a malicious or faulty entity advertising bogus stub 623 networks could attract traffic towards itself and/or deviate normal 624 routing across the domain. 626 Adding any kind of link to a Router LSA will trigger fight back by 627 the owner of the LSA, except under the circumstances stated in 628 paragraph 3.1.3. 630 Metric 631 The metric fields of an LSA can be modified in the attempt to affect 632 the SPF algorithm. Such operation could serve the purpose of 633 attracting traffic to a node for eavesdropping or overloading; on 634 the other hand, it could also be used for starving a given node. 636 Modifying the fields of a Router LSA regarding a link's metric will 637 trigger a fight back reaction by the owner of the LSA, except under 638 the circumstances stated in paragraph 3.1.3. 640 3.2.4.4. Network Link State Advertisement 641 Remove or add links to a domain 642 It is possible to tamper with the topology of a domain by 643 introducing phantom transit links through bogus Network LSAs. 644 Depending on how said phantom transit links are connected to real or 645 phantom OSPF routers, the bogus nodes may or may not be utilized by 646 the SPF algorithms present in other OSPF peers. A similar situation 647 applies where an existing transit link is maliciously flushed 648 impacting routes across the domain. 650 Adding or subtracting transit links through bogus Network LSAs will 651 trigger a fight back reaction by the owner of the LSA, except under 652 the circumstances stated in paragraph 3.1.3. 654 Attached Router 655 It is possible to add or eliminate nodes from a transit link by 656 tampering with the list of attached routers. If a legitimate node is 657 removed from this list, that router will be considered disconnected 658 by all the remaining OSPF peers in the domain, even though its 659 Router LSA will state the opposite. There must be consistency 660 between Network and Router LSAs for a router to be considered part 661 of a link. 663 Subtracting a router from the list of attached routers through a 664 bogus Network LSA will trigger a fight back reaction by the owner of 665 the LSA, the DR for the network link, except under the circumstances 666 stated in paragraph 3.1.3. 668 3.2.4.5. Summary Link State Advertisement 669 It is possible to add or eliminate information contained in both 670 types of Summary Link State LSA affecting routes across different 671 Areas. 673 Forging bogus Summary Link State LSAs will trigger a fight back 674 reaction by the owner of the LSA, except under the circumstances 675 stated in paragraph 3.1.3. 677 3.2.4.6. AS External Link State Advertisement 678 Every external route introduced by an ASBR is advertised by a single 679 External LSA. There is no way for OSPF routers to verify the 680 information carried by External LSA messages. Introduction of bogus 681 External LSAs will affect the domain's knowledge of the outside 682 world. Bogus External LSAs can be used to attract a portion of the 683 data traffic destined outside the domain to a specific node for 684 eavesdropping or overloading purposes. The same considerations apply 685 to any attempt to starve one or more nodes. 687 Introducing false External LSAs will trigger a fight back reaction 688 by the owner of the LSA and/or will not be recognized as legitimate 689 information by other routers if the LSA is forged on behalf of anon- 690 ASBR router, except under the circumstances stated in paragraph 691 3.1.3. 693 Forward 694 The Forward field of an External LSA specifies the host (OSPF router 695 or not) meant to be used as gateway for that external route; said 696 host can be located everywhere in the domain including Stub Areas. 697 If this field is forged and the forward host is not an OSPF router 698 then there will be no OSPF fight back from the host itself, but 699 there may be a fight back reaction from the ASBR owner of the LSA. 700 By exploiting this feature, an attacker could redirect traffic 701 destined outside the routing domain to any given host in the domain 702 which may, or may not, be under its control. For example, this can 703 be used to generate loops between an ABR and any of its neighbors 704 located in its Stub Area, simply by mentioning one of these 705 neighbors in the forward field of an External LSA advertisement for 706 traffic destined outside the domain. 708 Forging bogus AS External LSAs with modified Forward field 709 information will trigger a fight back reaction by the owner of the 710 LSA, except under the circumstances stated in paragraph 3.1.3. 712 3.3. Resource Consumption Vulnerabilities 713 Every resource may be exploited in the attempt to interfere with 714 traffic flows from legitimate users. In some cases the resource may 715 be so overwhelmed by malicious/illegitimate packets that legitimate 716 users will not only experience a drop in the performance of the 717 service, but they may be even prevented from accessing the service 718 itself. If one, or more, critical resource of a router is busy 719 serving bogus traffic, or dropping malicious routing messages, then 720 the whole router will be impacted and enter a delicate and more 721 vulnerable state. Next is a list of possible weaknesses that can be 722 exploited to produce a resource consumption attack. 724 3.3.1. OSPF Cryptographic Authentication 725 With Cryptographic Authentication disabled both outsider and insider 726 entities - including attackers and faulty routers - can successfully 727 forge malicious/erroneous OSPF messages that will be in the position 728 to attack a router or exhaust its control plane resources, such as 729 queues and CPU cycles. 731 On the other hand, when Cryptographic Authentication is enabled, 732 only insiders may successfully force malicious OSPF messages to be 733 accepted by the victim's control plane. Unfortunately though, 734 outsider entities are still in the position to generate a powerful 735 resource consumption attack by intentionally exploiting the 736 Cryptographic Authentication mechanism itself as described in [3]. 737 These entities may inject OSPF packets with bogus cryptographic 738 information that will consume critical resources only to be 739 discarded afterward. This will impact OSPF by delaying or even 740 preventing legitimate messages to be authenticated and used. 742 3.3.2. Hello Message 743 DR and BDR Election 744 Hello messages are used by OSPF also to carry out the DR and BDR 745 election process. The DR election process itself presents a possible 746 resource consumption vulnerability since it may be fooled into 747 electing a new DR at every run. When a new DR is elected all routers 748 on the network will have to use resources to establish adjacency 749 with this new DR; the same applies in the case of the BDR. 751 Number of Neighbors 752 OSPF routers create a neighbor data structure for each neighbor 753 discovered through the Hello protocol. The resources to store this 754 information could be exhausted on a broadcast or NBMA network with a 755 large host address range. 757 Message Size 758 Since a router must list all its current active neighbors in each of 759 its Hello messages, it may have to issue a Hello message bigger than 760 the Layer 2 media's MTU, e.g. bigger than the Ethernet frame's size. 761 Since this is usually a delicate area in implementation and design 762 all the necessary care should be exerted. 764 3.3.3. Link State Request Message 765 Any Link State Request message forces the destination router to 766 reply with a Link State Update message containing the requested LSA. 767 An insider attacker, or a faulty router, could mount a resource 768 consumption attack by continuously requesting Link State information 769 from its neighbors at any desired rate. 771 3.3.4. Link State Acknowledgment Message 772 Not acknowledging Link State Update messages forces the originating 773 peer to keep a copy of the LSU on the retransmission list; this 774 leads to re-transmission loops wasting resources on both sides. 776 3.3.5. Link State DB Overflow 777 Router/Network LSA 778 Router/Network LSAs received from non-existing OSPF peers will not 779 be used by the SPF algorithm and will not directly adverse the 780 routes nor the topology. Nonetheless, these LSAs will consume 781 resources in the Link State Database and will not be removed from 782 this database until they "naturally" expire after MaxAge (1 hour). 783 If the purpose of an attacker is to simply consume database 784 resources, then crafting LSAs on behalf of non-existing OSPF routers 785 is a good option since it makes the effects of the attack last 786 longer and triggers no fight back reaction at all. Finally, it is 787 important to highlight that Link State Database overflows produced 788 by Router and Network LSAs will not be limited by the mitigation 789 mechanism detailed in RFC1765 [10]. 791 External LSA 792 External LSAs may also be successfully exploited in the attempt to 793 fill Link State Database resources. If these LSAs are crafted on 794 behalf of non-existing ASBRs, their information will not be used by 795 any SPF algorithm; however they will be successfully installed in 796 the Link State Databases. Moreover, External LSAs are forwarded to 797 all routers in the domain (except routers located in Stub Areas), 798 expire only after MaxAge if no fight back is place, and are never 799 consolidated by OSPF. 801 Link State Database Description Messages 802 The Database Exchange process poses a resource consumption threat on 803 the slave router participating to the process. An insider attacker - 804 or a faulty router - capable of leading a victim into the Database 805 Exchange process could advertise a huge list of non-existing links 806 through Database Description messages. The victim will keep updating 807 this list and start asking for details via Link State Request 808 messages. The number of bogus links that the victim router will have 809 to store poses an immediate resource consumption threat, while the 810 prolonged request for details about the bogus LSAs will keep the 811 victim's retransmission list full and busy. 813 Retransmission List Exhaustion 814 Any LSU that is not acknowledged is put on a re-transmission list. 815 OSPF messages present in this list are sent over regular intervals 816 until they are acknowledged by the receivers. Failing to acknowledge 817 LSUs, accidentally or voluntarily, will trigger resource consumption 818 on the remote peer's retransmission mechanisms. 820 3.3.6 Others 821 Routing table size/performance issue 822 Increasing the size of the routing table could potentially move a 823 router into a very delicate state and eventually reach the limits 824 assigned to some resources. This could be achieved by using Router, 825 Network or External LSAs from existing peers and somehow disabling 826 the fight back from the legitimate owners. 828 Fragmentation 829 Fragmentation of OSPF messages due to Layer 2 MTU is a crucial 830 factor for any given implementation; any situation involving such 831 process should be carefully tested. For example in the case of a 832 router running the open source routing suite Zebra over Ethernet 833 links, receiving a forged Router LSA that claims to have more than 834 118 links will adversely impact the routing daemon. Even though the 835 LSA does not violate RFC2328, which states that a Router LSA must be 836 entirely contained into one single IP packet, a Router LSA listing 837 more than 118 links does exceed the Ethernet MTU and will be 838 fragmented over multiple Ethernet frames: this seems to have a 839 serious impact on the behavior of Zebra. 841 3.4. Vulnerabilities through Other Protocols 843 3.4.1. IP 844 OSPF runs directly over IP. Therefore, OSPF is subject to attack 845 through attacks on IP. Direct attacks against the IP stack of a 846 router, such as integrity and fragmentation attacks, will impact 847 OSPF but are clearly beyond the scope of this document. 849 3.4.2. Other Supporting Protocols (Management) 850 The security of OSPF is inherently dependent on the security of the 851 managing procedures. Critical examples are the configuration of the 852 state of any interface, the Manual Stop procedure and the Timer 853 Values. 855 Manual stop 856 A manual stop event causes the OSPF router to bring down all its 857 adjacencies, release all associated OSPF resources, and delete all 858 associated routes. If the mechanisms by which an OSPF router was 859 informed of a manual stop is not carefully protected, OSPF 860 connections could be destroyed by an attacker. Consequently, OSPF 861 security is secondarily dependent on the security of whatever 862 protocols are used to operate the platform. 864 Timer events 865 The RxmtInterval, InfTransDelay, RouterDeadInterval, HelloInterval 866 timers together with the RouterPriority parameter are critical to 867 OSPF operation. For example, if the HelloInterval timer value is 868 changed, all remote peers will refuse Hello messages from that 869 router and after RouterDeadInterval bring the adjacency down. 870 Consequently, OSPF security is secondarily dependent on the security 871 of the protocols by which the platform is managed and configured. 873 3.5. Residual Risk 874 OSPF Cryptographic Authentication assumes that the cryptographic 875 algorithms are secure, that the secrets used are protected from 876 exposure and are chosen well so as not to be guessable, that the 877 platforms are securely managed and operated to prevent break-ins, 878 etc. 880 Information theory states that the English language has about 1.3 881 bits of entropy for each 8-bit character. If an administrator were 882 to choose the secret key for the Cryptographic Authentication to be 883 any English word, the entropy associated to the secret key 884 protecting the session would be drastically reduced from 128 bits to 885 the point where it could be guessed in a matter of minutes or days. 886 On top of that, Common Line Interfaces (CLI) will generally limit 887 the key input to a specific subset of ASCII characters - letters and 888 number plus a few symbols - and will not accept a 128-bits number 889 value (for example in hexadecimal format). 891 This becomes crucial in all those cases where the secret defending 892 an OSPF adjacency is poorly chosen and changed once every three 893 months, or every year, or never. In all these scenarios an attacker 894 that somehow managed to obtain a copy of a single OSPF Hello message 895 may eventually be able to crack the secret key and attack the entire 896 routing domain for a prolonged period of time. 898 4. References 900 [1] J. Moy. "OSPF Version 2", STD 54, RFC2328, April 1998. 902 [2] P. Ferguson, D. Senie. "Network Ingress Filtering: Defeating 903 Denial of Service Attacks which employ IP Source Address 904 Spoofing", BCP 38, RFC2827, May 2000. 906 [3] A. Zinin. "Protecting Internet Routing Infrastructure from 907 Outsider CPU Attacks", work in progress, February 2003. 908 Available as at Internet-Draft 909 shadow sites. 911 [4] A. Babir, S. Murphy, Y. Yang. "Generic Threats to Routing 912 Protocols", work in progress, April 2004. Available as 913 at Internet-Draft 914 shadow sites. 916 [5] E. Rescorla, B. Korver. "Guidelines for Writing RFC Text on 917 Security Considerations", work in progress, January 2003. 918 Available as at Internet-Draft 919 shadow sites. 921 [6] F. Wang, S. Felix Wu. "On the Vulnerabilities and Protection of 922 OSPF Routing Protocols" In Proceedings 7th International 923 Conference on Computer Communications and Networks: 148-152. Los 924 Alamitos, CA: IEEE Comp. Soc., 1998. 926 [7] J. Etienne. "Flaws in Packet's Authentication of OSPFv2", work 927 in progress, November 2001. Available as 928 at Internet-Draft shadow 929 sites. 931 [8] S. Murphy, et al. "Retrofitting Security into Internet 932 Infrastructure Protocols." Proceedings of DARPA Information 933 Survivability Conference and Exposition (DISCEX'00), 2000. 935 [9] B. Vetter, F. Wang and S. F. Wu. "An Experimental Study of 936 Insider Attacks for the OSPF Routing Protocol", in 5th IEEE 937 International Conference on Network Protocols, Atlanta, GA, 938 Oct 28-31, 1997. 940 [10] J. Moy. "OSPF Database Overflow", Experimental, RFC1765, March 941 1995. 943 Authors' Addresses 945 Emanuele Jones 946 Alcatel 947 600 March Road - Kanata, ON, Canada K2K 2E6 948 EMail: emanuele.jones@alcatel.com 950 Olivier Le Moigne 951 Alcatel 952 600 March Road - Kanata, ON, Canada K2K 2E6 953 EMail: olivier.le_moigne@alcatel.com 955 Full Copyright Statement 957 Copyright (C) The Internet Society (date). All Rights Reserved. This 958 document and translations of it may be copied and furnished to 959 others, and derivative works that comment on or otherwise explain it 960 or assist in its implementation may be prepared, copied, published 961 and distributed, in whole or in part, without restriction of any 962 kind, provided that the above copyright notice and this paragraph 963 are included on all such copies and derivative works. However, this 964 document itself may not be modified in any way, such as by removing 965 the copyright notice or references to the Internet Society or other 966 Internet organizations, except as needed for the purpose of 967 developing Internet standards in which case the procedures for 968 copyrights defined in the Internet Standards process must be 969 followed, or as required to translate it into languages other than 970 English. 972 The limited permissions granted above are perpetual and will not be 973 revoked by the Internet Society or its successors or assigns. This 974 document and the information contained herein is provided on an "AS 975 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 976 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 977 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 978 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 979 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.