idnits 2.17.1 draft-ietf-manet-olsrv2-sec-threats-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 148: '...oyment of OLSRv2 SHOULD use the securi...' RFC 2119 keyword, line 149: '... specified in [RFC7183] but MAY use another mechanism if more...' RFC 2119 keyword, line 152: '... rekeying) SHOULD be considered."...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 12, 2017) is 2633 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Clausen 3 Internet-Draft U. Herberg 4 Intended status: Informational 5 Expires: July 16, 2017 J. Yi 6 Ecole Polytechnique 7 January 12, 2017 9 Security Threats to the Optimized Link State Routing Protocol version 2 10 (OLSRv2) 11 draft-ietf-manet-olsrv2-sec-threats-04 13 Abstract 15 This document analyzes common security threats that might apply to 16 the Optimized Link State Routing Protocol version 2 (OLSRv2) and 17 describes their potential impacts on Mobile Ad Hoc Network (MANET) 18 operations. It then analyzes which of these security vulnerabilities 19 can be mitigated when using the mandatory-to-implement security 20 mechanisms for OLSRv2, and how the vulnerabilities are mitigated. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on July 16, 2017. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. OLSRv2 Overview . . . . . . . . . . . . . . . . . . . . . 4 58 1.1.1. Neighborhood Discovery . . . . . . . . . . . . . . . . 4 59 1.1.2. MPR Selection . . . . . . . . . . . . . . . . . . . . 5 60 1.1.3. Link State Advertisement . . . . . . . . . . . . . . . 5 61 1.2. Link State Vulnerability Taxonomy . . . . . . . . . . . . 5 62 1.3. OLSRv2 Attack Vectors . . . . . . . . . . . . . . . . . . 6 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 3. Topology Map Acquisition . . . . . . . . . . . . . . . . . . . 7 65 3.1. Attack on Jittering . . . . . . . . . . . . . . . . . . . 7 66 3.2. Hop-count and Hop-limit Attacks . . . . . . . . . . . . . 7 67 3.2.1. Modifying the Hop Limit . . . . . . . . . . . . . . . 8 68 3.2.2. Modifying the Hop Count . . . . . . . . . . . . . . . 8 69 4. Effective Topology . . . . . . . . . . . . . . . . . . . . . . 9 70 4.1. Incorrect Forwarding . . . . . . . . . . . . . . . . . . . 10 71 4.2. Wormholes . . . . . . . . . . . . . . . . . . . . . . . . 10 72 4.3. Sequence Number Attacks . . . . . . . . . . . . . . . . . 11 73 4.3.1. Message Sequence Number . . . . . . . . . . . . . . . 11 74 4.3.2. Advertised Neighbor Sequence Number (ANSN) . . . . . . 12 75 4.4. Indirect Jamming . . . . . . . . . . . . . . . . . . . . . 12 76 5. Inconsistent Topology . . . . . . . . . . . . . . . . . . . . 14 77 5.1. Identity Spoofing . . . . . . . . . . . . . . . . . . . . 14 78 5.2. Link Spoofing . . . . . . . . . . . . . . . . . . . . . . 16 79 5.2.1. Inconsistent Topology Maps due to Link State 80 Advertisements . . . . . . . . . . . . . . . . . . . . 16 81 6. Mitigation of Security Vulnerabilities for OLSRv2 . . . . . . 17 82 6.1. Inherent OLSRv2 Resilience . . . . . . . . . . . . . . . . 18 83 6.2. Resilience by using RFC7183 with OLSRv2 . . . . . . . . . 18 84 6.2.1. Topology Map Acquisition . . . . . . . . . . . . . . . 19 85 6.2.2. Effective Topology . . . . . . . . . . . . . . . . . . 19 86 6.2.3. Inconsistent Topology . . . . . . . . . . . . . . . . 20 87 6.3. Correct Deployment . . . . . . . . . . . . . . . . . . . . 20 88 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 89 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 90 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 91 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 92 9.2. Informative References . . . . . . . . . . . . . . . . . . 21 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 95 1. Introduction 97 The Optimized Link State Routing Protocol version 2 (OLSRv2) 98 [RFC7181] is a successor to OLSR [RFC3626] as a routing protocol for 99 MANETs (Mobile Ad hoc NETworks). OLSRv2 retains the same basic 100 algorithms as its predecessor, however offers various improvements, 101 e.g., a modular and flexible architecture allowing extensions, such 102 as for security, to be developed as add-ons to the basic protocol. 103 Such building-blocks and modules include [RFC5148], [RFC5444], 104 [RFC5497], [RFC6130], [RFC7182], [RFC7183], [RFC7187], [RFC7188], 105 [RFC7466], etc. 107 The developments reflected in OLSRv2 have been motivated by increased 108 real-world deployment experiences, e.g., from networks such as 109 FunkFeuer [FUNKFEUER], and the requirements to be addressed for 110 continued successful operation of these networks. With participation 111 in such networks increasing (the FunkFeuer community network has, 112 e.g., roughly 400 individual participants at the time of publication 113 of this document), operating with the assumption, that participants 114 can be "trusted" to behave in a non-destructive way, is utopian. 115 With deployent in the wider Internet, with a resultant increase in 116 user numbers, an increase in attacks and abuses has followed 117 necessitating a change in recommended practices. For example, SMTP 118 servers, which were initially available for use by everyone on the 119 Internet, require authentication and accounting for users today 120 [RFC5068]. 122 As OLSRv2 is often used in wireless environments, it is potentially 123 exposed to different kinds of security threats, some of which are of 124 greater significance as compared to wired networks. As radio signals 125 can be received as well as transmitted by any compatible wireless 126 device within radio range, there are commonly no physical constraints 127 on the conformation of nodes and communication links that make up the 128 network as could be expected for wired networks.. 130 A first step towards hardening against attacks disrupting the 131 connectivity of a network, is to understand the vulnerabilities of 132 the routing protocol, managing the connectivity. This document 133 therefore analyzes OLSRv2, to understand its inherent vulnerabilities 134 and resiliences. The authors do not claim completeness of the 135 analysis, but hope that the identified attacks, as presented, form a 136 meaningful starting-point for developing and deploying increasingly 137 well-secured OLSRv2 networks. 139 This document first describes security vulnerabilities of OLSRv2 when 140 it is used without the mandatory-to-implement security mechanisms, as 141 specified in Section 23.5 of [RFC7181]. It then analyzes which of 142 these security vulnerabilities can be mitigated when using the 143 mandatory-to-implement security mechanisms for OLSRv2, and how the 144 vulnerabilities are mitigated. This separation is important since 145 security mechanisms other than the mandatory-to-implement ones may be 146 used in a deployment, as explicitly stated in [RFC7181]: 148 "Any deployment of OLSRv2 SHOULD use the security mechanism 149 specified in [RFC7183] but MAY use another mechanism if more 150 appropriate in an OLSRv2 deployment. For example, for longer-term 151 OLSRv2 deployments, alternative security mechanisms (e.g., 152 rekeying) SHOULD be considered." 154 Moreover, this document is also based on the assumption that no 155 additional security mechanism such as IPsec is used in the IP layer 156 or other mechanisms on lower layers, as not all MANET deployments may 157 be able to accommodate such common protection mechanisms (e.g., 158 because of limited resources of MANET routers). 160 The threats related to NHDP (Neighborhood Discovery Protocol 161 [RFC6130]) have been discussed in [RFC7186]. As NHDP is a 162 fundamental block of OLSRv2, the vulnerabilities of NHDP apply also 163 to OLSRv2. 165 It should be noted that many OLSRv2 implementations are configurable, 166 and so an attack on the configuration system (such as [RFC7939] and 167 [RFC7184]) can be used to adversely affect the operation of an OLSRv2 168 implementation. 170 1.1. OLSRv2 Overview 172 OLSRv2 contains three basic processes: Neighborhood Discovery, MPR 173 Selection and Link State Advertisements. They are described in the 174 sections below with sufficient details to allow elaboration of the 175 analyses in this document. 177 1.1.1. Neighborhood Discovery 179 Neighborhood Discovery is the process, whereby each router discovers 180 the routers which are in direct communication range of itself (1-hop 181 neighbors), and detects with which of these it can establish bi- 182 directional communication. Each router sends HELLO messages 183 periodically, listing the identifiers of all the routers from which 184 it has recently received a HELLO message, as well as the "status" of 185 the link (heard or verified bi-directional). A router A receiving a 186 HELLO message from a neighbor B, in which B indicates to have 187 recently received a HELLO message from A, considers the link A-B to 188 be bi-directional. As B lists identifiers of all its neighbors in 189 its HELLO message, A learns the "neighbors of its neighbors" (2-hop 190 neighbors) through this process. HELLO messages are sent 191 periodically, however certain events may trigger non-periodic HELLOs. 192 OLSRv2 [RFC7181] uses NHDP [RFC6130] as its neighborhood discovery 193 mechanism. The vulnerabilities of NHDP are analyzed in [RFC7186]. 195 1.1.2. MPR Selection 197 Multi Point Relay (MPR) Selection is the process whereby each router 198 is able to identify a set of relays for efficiently conducting 199 network-wide broadcasts. Each router designates, from among its bi- 200 directional neighbors, a subset (MPR set) such that a OLSRv2 specific 201 multicast message transmitted by the router and relayed by the MPR 202 set can be received by all its 2-hop neighbors. MPR selection is 203 encoded in outgoing NHDP HELLO messages. 205 Routers may express, in their HELLO messages, their "willingness" (an 206 integer between 0 "will never" and 7 "will always") to be selected as 207 MPR, which is taken into consideration for the MPR calculation, and 208 which is useful for example when an OLSRv2 network is "planned". The 209 set of routers having selected a given router as MPR is the MPR- 210 selector-set of that router. A study of the MPR flooding algorithm 211 can be found in [MPR-FLOODING]. 213 1.1.3. Link State Advertisement 215 Link State Advertisement (LSA) is the process whereby routers 216 determine which link state information to advertise through the 217 network. Each router must advertise, at least, all links between 218 itself and its MPR selectors, in order to allow all routers to 219 calculate shortest paths. Such LSAs are carried in Topology Control 220 (TC) messages, broadcast through the network using the MPR flooding 221 process described above. As a router selects MPRs only from among 222 bi-directional neighbors, links advertised in TC are also bi- 223 directional and routing paths calculated by OLSRv2 contain only bi- 224 directional links. TCs are sent periodically, however certain events 225 may trigger non-periodic TCs. 227 1.2. Link State Vulnerability Taxonomy 229 Proper functioning of OLSRv2 assumes that: 231 o each router signals its presence in the network and the topology 232 information that it obtained correctly; 234 o each router can acquire and maintain a topology map, accurately 235 reflecting the effective network topology; 237 o the network converges, i.e., that all routers in the network will 238 have sufficiently identical topology maps. 240 An OLSRv2 network can be disrupted by breaking any of these 241 assumptions, specifically (a) routers may be prevented from acquiring 242 a topology map of the network; (b) routers may acquire a topology map 243 that does not reflect the effective network topology; and (c) two or 244 more routers may acquire inconsistent topology maps. 246 1.3. OLSRv2 Attack Vectors 248 Besides "radio jamming", attacks on OLSRv2 consist of a compromised 249 OLSRv2 router injecting "apparently correct, but invalid, control 250 traffic" (TCs, HELLOs) into the network. A compromised OLSRv2 router 251 can either (a) advertise erroneous information about itself (its 252 identification, its willingness to serve as MPR), henceforth 253 identified as Identity Spoofing, or (b) advertise erroneous 254 information about its relationship to other routers (pretend 255 existence of links to other routers), henceforth identified as Link 256 Spoofing. Such attacks may disrupt the LSA process, through 257 targeting the MPR Flooding mechanism, or by causing incorrect link 258 state information to be included in TCs, causing routers to have 259 incomplete, inaccurate or inconsistent topology maps. In a different 260 class of attacks, a compromised OLSRv2 router injects control 261 traffic, designed so as to cause an in-router resource exhaustion, 262 e.g., by causing the algorithms calculating routing tables or MPR 263 sets to be invoked continuously, preventing the internal state of a 264 router from converging, depleting the energy of battery-driven 265 routers, etc. 267 2. Terminology 269 This document uses the terminology and notation defined in [RFC5444], 270 [RFC6130] and [RFC7181]. Additionally, it defines the following 271 terminology: 273 Compromised OLSRv2 router: - An attacker that eavesdrops the network 274 traffic and/or generates syntactically correct OLSRv2 control 275 messages. Control messages emitted by a compromised OLSRv2 router 276 may contain additional information, or omit information, as 277 compared to a control message generated by a non-compromised 278 OLSRv2 router located in the same topological position in the 279 network. 281 Legitimate OLSRv2 router: - An OLSRv2 router that is not a 282 compromised OLSRv2 router. 284 3. Topology Map Acquisition 286 Topology Map Acquisition relates to the ability for any given router 287 in the network to acquire a representation of the network 288 connectivity. A router, unable to acquire a topology map, is 289 incapable of calculating routing paths and participating in 290 forwarding data. Topology map acquisition can be hindered by (i) TCs 291 not being delivered to (all) routers in the network, such as what 292 happens in case of Flooding Disruption, or (ii) in case of "jamming" 293 of the communication channel. 295 The jamming and flooding disruption due to identity spoofing and link 296 spoofing have been discussed in [RFC7186]. 298 3.1. Attack on Jittering 300 OLSRv2 incorporates a jittering mechanism: a random, but bounded, 301 delay on outgoing control traffic [RFC5148]. This may be necessary 302 when link layers (such as 802.11 [IEEE802.11]) are used that do not 303 guarantee collision-free delivery of frames, and where jitter can 304 reduce the probability of collisions of frames on lower layers. 306 In OLSRv2, TC forwarding is jittered by a value between 0 and 307 MAX_JITTER. In order to reduce the number of transmissions, when a 308 control message is due for transmission, OLSRv2 piggybacks all queued 309 messages into a single transmission. Thus, if a compromised OLSRv2 310 router sends many TCs within a very short time interval, the jitter 311 time of the attacked router tends to 0. This renders jittering 312 ineffective and can lead to collisions on the link layer. 314 In addition to causing more collisions, forwarding a TC with little 315 or no jittering can make sure that the TC message forwarded by a 316 compromised router arrives before the message forwarded by legitimate 317 routers. The compromised router can thus inject malicious content in 318 the TC: for example, if the message identification is spoofed, the 319 legitimate message will be discarded as a duplicate message. This 320 preemptive action is important for some of the attacks introduced in 321 the following sections. 323 3.2. Hop-count and Hop-limit Attacks 325 The hop-count and hop-limit fields are the only parts of a TC that 326 are modified when forwarding, and are therefore not protected by 327 integrity check mechanisms. A compromised OLSRv2 router can modify 328 either of these when forwarding TCs. 330 3.2.1. Modifying the Hop Limit 332 A compromised OLSRv2 router can decrease the hop limit when 333 forwarding a TC. This will reduce the scope of forwarding for the 334 message, and may lead to some routers in the network not receiving 335 that TC. Note that this is not necessarily the same as not relaying 336 the message (i.e., setting the hop limit to 0), as illustrated in 337 Figure 1. 339 .---. 340 | X | 341 --'---' __ 342 / \ 343 / \ 344 .---. .---. 345 TC -----> | A | | C | 346 '---' '---' 347 \ .---. / 348 \-- | B |__/ 349 '---' 351 Figure 1: Hop Limit Attack. 353 A TC arrives at and is forwarded by router A, such that it is 354 received by both B and the malicious X. X can forward the TC without 355 any delay (including without jitter) such that its transmissions 356 arrive before that of B at C. Before forwarding, it significantly 357 reduces the hop limit of the message. Router C receives the TC, 358 processes (and forwards) it, and marks it as already received - 359 causing it to discard further copies received from B. Thus, if the TC 360 is forwarded by C, it has a very low hop limit and will not reach the 361 whole network. 363 3.2.2. Modifying the Hop Count 365 A compromised OLSRv2 router can modify the hop count when forwarding 366 a TC. This may have two consequences: (i) if the hop count is set to 367 the maximum value, then the TC will be forwarded no further by, or 368 (ii) artificially manipulating the hop count may affect the validity 369 time as calculated by recipients, when using distance-dependent 370 validity times as defined in [RFC5497] (e.g., as part of a fish-eye 371 extension to OLSR2 [OLSR-FSR] [OLSR-FSR-Scaling]). 373 v_time(3hops)=9s v_time(4hops)=12s v_time(5hops)=15s 374 .---. .---. .---. .---. 375 | A |-- ... --> | B | -------> | X |---------->| C | 376 `---' `---' `---' `---' 378 Figure 2: Different validity times based on the distance in hops. 380 In Figure 2, router A sends a TC with a validity time of 9 seconds 381 for routers that are 3 hops away, 12 seconds for routers in a 4-hop 382 distance and 15 seconds in a a 5-hop distance. If X is a compromised 383 OLSRv2 router and modifies the hop count (say, by decreasing it to 384 3), then C will calculate the validity time of received information 385 to 9 seconds - after which it expires unless refreshed. If TCs from 386 A are sent less frequently than that up to 4 hops, this causes links 387 advertised in such TCs to be only intermittently available to C. 389 4. Effective Topology 391 Link-state protocols assume that each router can acquire an accurate 392 topology map, reflecting the effective network topology. This 393 implies that the routing protocol, through its message exchange, 394 identifies a path from a source to a destination, and this path is 395 valid for forwarding data traffic. If an attacker disturbs the 396 correct protocol behavior, the perceived topology map of a router can 397 permanently differ from the effective topology. 399 Considering the example in Figure 3(a), which illustrates the 400 topology map as acquired by router S. This topology map indicates 401 that the routing protocol has identified that for S, a path exists to 402 D via B, which it therefore assumes can be used for transmitting 403 data. If, effectively, B does not forward data traffic from S, then 404 the topology map in S does not accurately reflect the effective 405 network topology. Rather, the effective network topology from the 406 point of view of S would be as indicated in Figure 3(b): D is not 407 part of the network reachable from router S. 409 .---. .---. .---. .---. .---. 410 | S |----| B |----| D | | S |----| B | 411 `---' `---' `---' `---' `---' 413 (a) (b) 415 Figure 3: Incorrect Data Traffic Forwarding. 417 Some of the attacks related to NHDP, such as message timing attack, 418 indirect channel overloading have been discussed in [RFC7186]. Other 419 threats specific to OLSRv2 are further detailed in this section. 421 4.1. Incorrect Forwarding 423 OLSRv2 routers exchange information using link-local transmissions 424 (link-local multicast or limited broadcast) for their control 425 messages, with the routing process in each router retransmitting 426 received messages destined for network-wide diffusion. Thus, if the 427 operating system in a router is not configured to enable forwarding, 428 this will not affect the operating of the routing protocol, or the 429 topology map acquired by the routing protocol. It will, however, 430 cause a discrepancy between the effective topology and the topology 431 map, as indicated in Figure 3(a) and Figure 3(b). 433 This situation is not hypothetical. A common error seen when 434 deploying OLSRv2-based networks using Linux-based computers as router 435 is to neglect enabling IP forwarding, which effectively becomes an 436 accidental attack of this type. 438 4.2. Wormholes 440 A wormhole, depicted in the example in Figure 4, may be established 441 between two collaborating devices, connected by an out-of-band 442 channel. These devices send traffic through the "tunnel" to their 443 alter-ego, which "replays" the traffic. Thus, routers D and S appear 444 as if direct neighbors and reachable from each other in 1 hop through 445 the tunnel, with the path through the MANET being 100 hops long. 447 .---. .---. 448 | S |---- ....100-hop long path ... ---| D | 449 `---. / `---' 450 \ / 451 \ / 452 \X=============================X 454 1-hop path via wormhole 456 Figure 4: Wormholing between two collaborating devices not 457 participating in the routing protocol. 459 The consequences of such a wormhole in the network depends on the 460 detailed behavior of the wormhole. If the wormhole relays only 461 control traffic, but not data traffic, the same considerations as in 462 Section 4.1 applies. If, however, the wormhole relays all traffic, 463 control and data alike, it is connectivity-wise identical to a usable 464 link - and the routing protocol will correctly generate a topology 465 map reflecting the effective network topology. The efficiency of the 466 topology so obtained depends on (i) the wormhole characteristics, 467 (ii) how the wormhole presents itself, and (iii) how paths are 468 calculated. 470 Assuming that paths are calculated with unit-cost for all links, 471 including the "link" presented by the wormhole: if the real 472 characteristics of the wormhole are as-if it was a path of more than 473 100 hops (e.g., with respect to delay, bandwidth, etc.), then the 474 presence of the wormhole results in a degradation in performance as 475 compared to using the non-wormhole path. Conversely, if the "link" 476 presented by the wormhole has better characteristics, the wormhole 477 results in improved performance. 479 If paths are calculated using non-unit-costs for all links, and if 480 the cost of the "link" presented by the wormhole correctly represents 481 the actual cost (e.g., if the cost is established through 482 measurements across the wormhole), then the wormhole may in the worst 483 case cause no degradation in performance, in the best case improve 484 performance by offering a better path. If the cost of the "link" 485 presented by the wormhole is misrepresented, then the same 486 considerations as for unit-cost links apply. 488 An additional consideration with regards to wormholes is, that such 489 may present topologically attractive paths for the network - however 490 it may be undesirable to have data traffic transit such a path: an 491 attacker could, by virtue of introducing a wormhole, acquire the 492 ability to record and inspect transiting data traffic. 494 4.3. Sequence Number Attacks 496 OLSRv2 uses two different sequence numbers in TCs, to (i) avoid 497 processing and forwarding the same message more than once (Message 498 Sequence Number), and (ii) to ensure that old information, arriving 499 late due to, e.g., long paths or other delays, is not allowed to 500 overwrite more recent information generated (Advertised Neighbor 501 Sequence Number - ANSN). 503 4.3.1. Message Sequence Number 505 An attack may consist of a compromised OLSRv2 router spoofing the 506 identity of another router in the network, and transmitting a large 507 number of TCs, each with different Message Sequence Numbers. 508 Subsequent TCs with the same sequence numbers, originating from the 509 router whose identity was spoofed, would hence be ignored, until 510 eventually information concerning these "spoofed" TCs expires. 512 4.3.2. Advertised Neighbor Sequence Number (ANSN) 514 An attack may consist of a compromised OLSRv2 router spoofing the 515 identity of another router in the network, and transmitting a single 516 TC, with an ANSN significantly larger than that which was last used 517 by the legitimate router. Routers will retain this larger ANSN as 518 "the most recent information" and discard subsequent TCs with lower 519 sequence numbers as being "old". 521 4.4. Indirect Jamming 523 Indirect Jamming is an attack in which a compromised OLSRv2 router 524 is, by its actions, causing legitimate routers to generate inordinate 525 amounts of control traffic, thereby increasing both channel 526 occupation and the overhead incurred in each router for processing 527 this control traffic. This control traffic will be originated from 528 legitimate routers, thus to the wider network, the malicious device 529 may remain undetected. 531 The general mechanism whereby a malicious router can cause indirect 532 jamming is for it to participate in the protocol by generating 533 plausible control traffic, and to tune this control traffic to in 534 turn trigger receiving routers to generate additional traffic. For 535 OLSRv2, such an indirect attack can be directed at, respectively, the 536 Neighborhood Discovery mechanism and the LSA mechanism. 538 The most efficient indirect jamming attack in OLSRv2 is to target 539 control traffic, destined for network-wide diffusion. This is 540 illustrated in Figure 5. 542 The malicious router X selects router A as MPR at time t0 in a HELLO. 543 This causes X to appear as MPR selector for A and, consequently, A 544 sets X to be advertised in its "Neighbor Set" and increments the 545 associated "Advertised Neighbor Sequence Number" (ANSN). Router A 546 must, then, advertise the link between itself and X in subsequent 547 outgoing TCs (t1), also including the ANSN in such TCs. Upon X 548 having received this TC, it declares the link between itself and A as 549 no longer valid (t2) in a HELLO (indicating the link to a as LOST). 550 Since only symmetric links are advertised by OLSRv2 routers, A will 551 upon receipt hereof remove X from the set of advertised neighbors and 552 increment the ANSN. Router A will then in subsequent TCs advertise 553 the remaining set of advertised neighbors (i.e., with X removed) and 554 the corresponding ANSN (t3). Upon X having received this information 555 in another TC from A, it may repeat this cycle, alternating 556 advertising the link A-X as "LOST" and as "MPR". 558 broadcast TC ANS={} TC:() 559 (X-A) ANSN ANSN++ ANSN 560 .---. .---. .---. .---. 561 | A | | A | | A | | A | 562 '---' '---' '---' '---' 563 ^ | ^ | 564 | | | | 565 | select | |indicate | 566 | as MPR | |as LOST | 567 .---. .---. .---. .---. 568 | X | | X | | X | | X | 569 '---' '---' '---' '---' 571 t0 t1 t2 t3 573 Figure 5: Indirect Jamming in Link State Advertisement: the malicious 574 X flips between link status MPR and LOST. 576 Routers receiving a TC will parse and process this message, 577 specifically updating their topology map as a consequence of 578 successful receipt. If the ANSN between two successive TCs from the 579 same router has incremented, then the topology has changed and 580 routing sets are to be recalculated. This is a potentially 581 computationally costly operation. 583 A compromised OLSRv2 router may chose to conduct this attack against 584 all its neighbors, thus attaining maximum disruptive impact on the 585 network with relatively little overhead of its own: other than 586 participating in the Neighborhood Discovery procedure, the 587 compromised OLSRv2 router will monitor TCs generated by its neighbors 588 and alternate the advertised status for each such neighbor, between 589 "MPR" and "LOST". The compromised OLSRv2 router will indicate its 590 willingness to be selected as an MPR as zero (thus, avoid being 591 selected as MPR) and may ignore all other protocol operations, while 592 still remaining effective as an attacker. 594 The basic operation of OLSRv2 employs periodic message emissions, and 595 by this attack it can be ensured that each such periodic message will 596 entail routing table recalculation in all routers in the network. 598 If the routers in the network have "triggered TCs" enabled, this 599 attack may also cause an increased TC frequency. Triggered TCs are 600 intended to allow a (stable) network to have relatively low TC 601 emission frequencies, yet still allow link breakage or link emergence 602 to be advertised through the network rapidly. A minimum message 603 interval (typically much smaller than the regular periodic message 604 interval) is imposed, to rate-limit worst-case message emissions. 605 This attack can cause the TC interval to, permanently, become equal 606 to the minimum message interval. [RFC7181] proposes as default that 607 the minimum TC interval be 0.25 x TC interval. 609 Indirect Jamming by a compromised OLSRv2 router can thus have two 610 effects: it may cause increased frequency of TC generation and 611 transmission, and it will cause additional routing table 612 recalculation in all routers in the network. 614 5. Inconsistent Topology 616 Inconsistent topology maps can occur by a compromised OLSRv2 router 617 employing either of identity spoofing or link spoofing for conducting 618 an attack against an OLSRv2 network. The threats related to NHDP, 619 such as identity spoofing in NHDP, link spoofing in NHDP and creating 620 loops have been illustrated in [RFC7186]. This section mainly 621 addresses the vulnerabilities in [RFC7181]. 623 5.1. Identity Spoofing 625 Identity spoofing can be employed by a compromised OLSRv2 router via 626 the Neighborhood Discovery process and via the LSA process. Either 627 of them causes inconsistent topology maps in routers in the network. 628 The creation of inconsistent topology maps due to neighborhood 629 discovery has been discussed in [RFC7186]. For OLSRv2, the attack on 630 LSAs can also cause inconsistent topology maps. 632 An inconsistent topology map may occur when the compromised OLSRv2 633 router takes part in the LSA procedure, by selecting a neighbor as 634 MPR, which in turn advertises the spoofed identities of the 635 compromised OLSRv2 router. This attack will alter the topology maps 636 of all routers of the network. 638 A -- B -- C -- D -- E -- F -- X 640 (X spoofs A) 642 Figure 6: Identity Spoofing: compromised OLSRv2 router X spoofs the 643 identity of A, leading to a wrongly perceived topology. 645 In Figure 6, router X spoofs the address of router A. If X selects F 646 as MPR, all routers in the network will be informed about the link 647 F-A by the TCs originating from F. Assuming that (the real) A selects 648 B as MPR, the link B-A will also be advertised in the network. 650 When calculating paths, B and C will calculate paths to A via B, as 651 illustrated in Figure 7(a); for these routers, the shortest path to A 652 is via B. E and F will calculate paths to A via F, as illustrated in 653 Figure 7(b); for these routers, the shortest path to A is via the 654 compromised OLSRv2 router X, and these are thus disconnected from the 655 real A. D will have a choice: the path calculated to A via B is of 656 the same length as the path via the compromised OLSRv2 router X, as 657 illustrated in Figure 7(c). 659 In general, the following observations can be made: 661 o The network will be split in two, with those routers closer to B 662 than to X reaching A, whereas those routers closer to X than to B 663 will be unable to reach A. 665 o Routers beyond B, i.e., routers beyond one hop away from A will be 666 unable to detect this identity spoofing. 668 The identity spoofing attack via the LSA procedure has a higher 669 impact than the attack on the neighborhood discovery procedure, since 670 it alters the topology maps of all routers in the network, and not 671 only in the 2-hop neighborhood. However, the attack is easier to 672 detect by other routers in the network. Since the compromised OLSRv2 673 router is advertised in the whole network, routers whose identities 674 are spoofed by the compromised OLSRv2 router can detect the attack. 675 For example, when A receives a TC from F advertising the link F-A, it 676 can deduce that some entity is injecting incorrect Link State 677 information as it does not have F as one of its direct neighbors. 679 (X spoofs A) 681 A < ---- B < ---- C E ----> F ----> X 683 (a) Routers B and C (b) Routers E and F 685 A < --- B < --- C < --- D ---> E ---> F ----> X 687 (X spoofs A) 689 Figure 7: Routing paths towards A, as calculated by the different 690 routers in the network in presence of a compromised OLSRv2 router X, 691 spoofing the address of A. 693 As the compromised OLSRv2 router X does not itself send the TCs, but 694 rather, by virtue of MPR selection, ensures that the addresses it 695 spoofs are advertised in TCs from its MPR selector F, the attack may 696 be difficult to counter: simply ignoring TCs that originate from F 697 may also suppress the link state information for other, legitimate, 698 MPR selectors of F. 700 Identity spoofing by a compromised OLSRv2 router, participating in 701 the LSA process by selecting MPRs only, thus, creates a situation 702 wherein two or more routers have substantially inconsistent topology 703 maps: traffic for an identified destination is, depending on where in 704 the network it appears, delivered to different routers. 706 5.2. Link Spoofing 708 Link Spoofing is a situation in which a router advertises non- 709 existing links to another router (possibly not present in the 710 network). Essentially, TCs and HELLOs both advertise links to direct 711 neighbor routers, with the difference being the scope of the 712 advertisement. Thus, link spoofing consists of a compromised OLSRv2 713 router, reporting that it has neighbors routers which are, either, 714 not present in the network, or which are effectively not neighbors of 715 the compromised OLSRv2 router. 717 It can be noted that a situation similar to link spoofing may occur 718 temporarily in an OLSR or OLSRv2 network without compromised OLSRv2 719 routers: if A was, but is no more, a neighbor of B, then A may still 720 be advertising a link to B for the duration of the time it takes for 721 the the Neighborhood Discovery process to determine this changed 722 neighborhood. 724 In the context of this document, link spoofing refers to a persistent 725 situation where a compromised OLSRv2 router intentionally advertises 726 links to other routers, for which it is not a direct neighbor. 728 5.2.1. Inconsistent Topology Maps due to Link State Advertisements 730 Figure 8 illustrates a network, in which the compromised OLSRv2 731 router X spoofs links to a existing router A by participating in the 732 LSA process and including this non-existing link in its 733 advertisements. 735 A --- B --- C --- D --- E --- F --- G --- H --- X 737 (X spoofs the link to A) 739 Figure 8: Link Spoofing: The compromised OLSRv2 router X advertises a 740 spoofed link to A in its TCs, thus all routers will record both of 741 the links X-A and B-A. 743 As TCs are flooded through the network, all routers will receive and 744 record information describing a link X-A in this link state 745 information. If A has selected router B as MPR, B will likewise 746 flood this link state information through the network, thus all 747 routers will receive and record information describing a link B-A. 749 When calculating routing paths, B, C and D will calculate paths to A 750 via B, as illustrated in Figure 9(a); for these routers, the shortest 751 path to A is via B. F and G will calculate paths to A via X, as 752 illustrated in Figure 9(b); for these routers, the shortest path to A 753 is via X, and these are thus disconnected from the real router A. E 754 will have a choice: the path calculated to A via B is of the same 755 length as the path via X, as illustrated in Figure 9(b). 757 A < --- B < --- C < --- D F ---> G ---> X ---> A 759 (a) Routers B, C, and D (b) Routers F and G 761 A < --- B < --- C < --- D < --- E ---> F ---> G ---> X ---> A 763 (c) Router E 765 Figure 9: Routing paths towards router A, as calculated by the 766 different routers in the network in presence of a compromised OLSRv2 767 router X, spoofing a link to router A. 769 In general, the following observations can be made: 771 o The network will be separated in two, with those routers closer to 772 B than to X reaching A, whereas those routers closer to X than to 773 B unable to reach A. 775 o Routers beyond B, i.e., routers beyond one hop away from A will be 776 unable to detect this link spoofing. 778 6. Mitigation of Security Vulnerabilities for OLSRv2 780 As described in Section 1, [RFC7183] specifies a security mechanism 781 for OLSRv2 that is mandatory to implement. However, deployments may 782 choose to use different security mechanisms if more appropriate. 783 Therefore, it is important to understand both the inherent resilience 784 of OLSRv2 against security vulnerabilities when not using the 785 mechanisms specified in [RFC7183], as well as the protection that 787 [RFC7183] provides when used in a deployment. 789 6.1. Inherent OLSRv2 Resilience 791 OLSRv2 (without the mandatory-to-implement security mechanisms in 792 [RFC7183]) provides some inherent resilience against part of the 793 attacks described in this document. In particular, it provides the 794 following resilience: 796 o Sequence numbers: OLSRv2 employs message sequence numbers, 797 specific per router identity and message type. Routers keep an 798 "information freshness" number (ANSN), incremented each time the 799 content of a LSA from a router changes. This allows rejecting 800 "old" information and duplicate messages, and provides some 801 protection against "message replay". This, however, also presents 802 an attack vector (Section 4.3). 804 o Ignoring uni-directional links: The Neighborhood Discovery process 805 detects and admits only bi-directional links for use in MPR 806 selection and LSA. Jamming attacks may affect only reception of 807 control traffic, however OLSRv2 will correctly recognize, and 808 ignore, such a link as not bi-directional. 810 o Message interval bounds: The frequency of control messages, with 811 minimum intervals imposed for HELLO and TCs. This may limit the 812 impact from an indirect jamming attack (Section 4.4). 814 o Additional reasons for rejecting control messages: The OLSRv2 815 specification includes a list of reasons, for which an incoming 816 control message should be rejected as malformed - and allows that 817 a protocol extension may recognize additional reasons for OLSRv2 818 to consider a message malformed. This allows - together with the 819 flexible message format [RFC5444] - addition of security 820 mechanisms, such as digital signatures, while remaining compliant 821 with the OLSRv2 standard specification. 823 6.2. Resilience by using RFC7183 with OLSRv2 825 [RFC7183] specifies mechanisms for integrity and replay protection 826 for NHDP and OLSRv2, using the generalized packet/message format 827 described in [RFC5444] and the TLV definitions in [RFC7182]. The 828 specification describes how to add an Integrity Check Value (ICV) in 829 a TLV to each control message, providing integrity protection of the 830 content of the message using HMAC/SHA-256. In addition, a timestamp 831 TLV is added to the message prior to creating the ICV, enabling 832 replay protection of messages. The document specifies how to sign 833 outgoing messages and how to verify incoming messages, as well as 834 under which circumstances a non-valid message is rejected. Because 835 of the HMAC/SHA-256 ICV, a shared key between all routers in the 836 MANET is assumed. A router without valid credentials is not able to 837 create an ICV that can be correctly verified by other routers in the 838 MANET; therefore, such an incorrectly signed message will be rejected 839 by other MANET routers, and the router cannot participate in the 840 OLSRv2 routing process (i.e., the malicious router will be ignored by 841 other, legitimate routers). [RFC7183] does not address the case 842 where a router with valid credentials has been compromised. Such a 843 compromised router will not be excluded from the routing process, and 844 other means of detecting such a router are necessary if required in a 845 deployment: for example, using an asymmetric key extension to 846 [RFC7182] that allows to revoke access to one particular router. 848 In the following sections, each of the vulnerabilities described 849 earlier in this document will be evaluated in terms of whether OLSRv2 850 with the mechanisms in [RFC7183] provides sufficient protection 851 against the attack. It is implicitly assumed in each of the 852 following sections that [RFC7183] is used with OLSRv2. 854 6.2.1. Topology Map Acquisition 856 Attack on Jittering - As only OLSRv2 routers with valid credentials 857 can participate in the routing process, a malicious router cannot 858 reduce the jitter time of an attacked router to 0 by sending many 859 TC messages in a short time. The attacked router would reject all 860 the incoming messages as "invalid" and not forward them. The same 861 applies for the case where a malicious router wants to assure that 862 by forcing a zero jitter interval, the message arrives before the 863 same message forwarded by legitimate routers. 865 Modifying the Hop Limit and the Hop Count - As the hop limit and hop 866 count are not protected by [RFC7183] (since they are mutable 867 fields, changing at every hop), this attack is still feasible. It 868 is possible to apply [RFC5444] packet-level protection by using 869 ICV Packet TLV defined in [RFC7182] to provide hop-by-hop 870 integrity protection - at the expense of a requirement of pairwise 871 trust between all neighbor routers. 873 6.2.2. Effective Topology 875 Incorrect Forwarding - As only OLSRv2 routers with valid credentials 876 can participate in the routing process, a malicious router will 877 not be part of the topology of other legitimate OLSRv2 routers. 878 Therefore, no data traffic will be sent to the malicious router 879 for forwarding. 881 Wormholes - Since a wormhole consists of at least two devices 882 forwarding (unmodified) traffic, this attack is still feasible and 883 undetectable by the OLSRv2 routing process since the attack does 884 not involve the OLSRv2 protocol itself (but rather lower layers). 885 By using [RFC7183], it can at least be assured that the content of 886 the control messages is not modified while being forwarded via the 887 wormhole. Moreover, the timestamp TLV assures that the forwarding 888 can only be done in a short time window after the actual TC 889 message has been sent. 891 Message Sequence Number - As the message sequence number is included 892 in the ICV calculation, OLSRv2 is protected against this attack. 894 Advertised Neighbor Sequence Number (ANSN) - As the ANSN is included 895 in the ICV calculation, OLSRv2 is protected against this attack. 897 Indirect Jamming - Since the control messages of a malicious router 898 will be rejected by other legitimate OLSRv2 routers in the MANET, 899 this attack is mitigated. 901 6.2.3. Inconsistent Topology 903 Identity Spoofing - Since the control messages of a malicious router 904 will be rejected by other legitimate OLSRv2 routers in the MANET, 905 a router without valid credentials may spoof its identity (e.g., 906 IP source address or message originator address), but the messages 907 will be ignored by other routers. As the mandatory mechanism in 908 [RFC7183] uses shared keys amongst all MANET routers, a single 909 compromised router may spoof its identity and cause harm to the 910 network stability. Removing this one malicious router once 911 detected implies rekeying all other routers in the MANET. 912 Asymmetric keys, in particular when using identity based 913 signatures, such as specified in [RFC7859] may give possibility of 914 revoking single routers and to verify their identity based on the 915 ICV itself. 917 Link Spoofing - Similar to identity spoofing, a malicious router 918 without valid credential may spoof links, but its control messages 919 will be rejected by other routers, thereby mitigating the attack. 921 Inconsistent Topology Maps due to LSAs - The same considerations as 922 for link spoofing apply. 924 6.3. Correct Deployment 926 Other than implementing OLSRv2 itself and corresponding security 927 mechanisms, deploying the protocol correctly is also important to 928 guarantee the protocol functioning and mitigate security 929 vulnerabilities. For example, Section 4.1 and Section 4.2 discussed 930 the vulnerabilities because of incorrect forwarding policy setting 931 and wormholes. This requires the routers are deployed with IP 932 forwarding enabled and the wormholes (if exist) are managed 933 appropriately. 935 7. Security Considerations 937 This document does not specify a protocol or a procedure, but 938 reflects on security considerations for OLSRv2, and for its 939 constituent parts, including NHDP. The document initially analyses 940 threats to topology map acquisition, with the assumption that no 941 security mechanism (including the mandatory-to-implement mechanisms 942 from [RFC7182], [RFC7183]) is in use - then, proceeds to discuss how 943 the use of [RFC7182] and [RFC7183] mitigate the identified threats. 944 When [RFC7183] is used with routers using a single shared key, the 945 protection offered is not effective if a compromised router has valid 946 credentials. 948 8. IANA Considerations 950 This document has no actions for IANA. 952 9. References 954 9.1. Normative References 956 [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc 957 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 958 RFC 6130, April 2011. 960 [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, 961 "The Optimized Link State Routing Protocol Version 2", 962 RFC 7181, April 2014. 964 [RFC7186] Yi, J., Herberg, U., and T. Clausen, "Security Threats for 965 the Neighborhood Discovery Protocol (NHDP)", RFC 7186, 966 April 2014. 968 9.2. Informative References 970 [FUNKFEUER] 971 "http://www.funkfeuer.at/". 973 [IEEE802.11] 974 "IEEE 802.11: Wireless LAN Medium Access Control (MAC) and 975 Physical Layer (PHY) Spec.", 2007. 977 [MPR-FLOODING] 978 Qayyum, A., Viennot, L., and A. Laouiti, "Multipoint 979 relaying: An efficient technique for flooding in mobile 980 wireless networks.", 2001. 982 [OLSR-FSR] 983 Clausen, T., "Combining Temporal and Spatial Partial 984 Topology for MANET routing-Merging OLSR and FSR, 985 Proceedings of the 2003 IEEE Conference of Wireless 986 Personal Multimedia Communications (WPMC 03)", 2003. 988 [OLSR-FSR-Scaling] 989 Adjih, C., Baccelli, E., Clausen, T., Jacquet, P., and G. 990 Rodolakis, "Fish eye OLSR scaling properties, IEEE Journal 991 of Communication and Networks (JCN), Special Issue on 992 Mobile Ad Hoc Wireless Networks", 2004. 994 [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State 995 Routing Protocol", RFC 3626, October 2003. 997 [RFC5068] Hutzler, C., Crocker, D., Resnick, P., Allman, E., and T. 998 Finch, "Email Submission Operations: Access and 999 Accountability Requirements", RFC 5068, BCP 134, 1000 October 2007. 1002 [RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter 1003 Considerations in Mobile Ad Hoc Networks (MANETs)", 1004 RFC 5148, February 2008. 1006 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 1007 "Generalized MANET Packet/Message Format", RFC 5444, 1008 February 2009. 1010 [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value 1011 Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, 1012 March 2009. 1014 [RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity 1015 Check Value and Timestamp TLV Definitions for Mobile Ad 1016 Hoc Networks (MANETs)", RFC 7182, April 2014. 1018 [RFC7183] Herberg, U., Dearlove, C., and T. Clausen, "Integrity 1019 Protection for the Neighborhood Discovery Protocol (NHDP) 1020 and Optimized Link State Routing Protocol Version 2 1021 (OLSRv2)", RFC 7183, April 2014. 1023 [RFC7184] Herberg, U., Cole, R., and T. Clausen, "Definition of 1024 Managed Objects for the Optimized Link State Routing 1025 Protocol Version 2", RFC 7184, April 2014. 1027 [RFC7187] Dearlove, C. and T. Clausen, "Routing Multipoint Relay 1028 Optimization for the Optimized Link State Routing Protocol 1029 Version 2 (OLSRv2)", RFC 7187, April 2014. 1031 [RFC7188] Dearlove, C. and T. Clausen, "Optimized Link State Routing 1032 Protocol Version 2 (OLSRv2) and MANET Neighborhood 1033 Discovery Protocol (NHDP) Extension TLVs", RFC 7188, 1034 April 2014. 1036 [RFC7466] Dearlove, C. and T. Clausen, "An Optimization for the 1037 Mobile Ad Hoc Network (MANET) Neighborhood Discovery 1038 Protocol (NHDP)", RFC 7466, DOI 10.17487/RFC7466, 1039 March 2015, . 1041 [RFC7859] Dearlove, C., "Identity-Based Signatures for Mobile Ad Hoc 1042 Network (MANET) Routing Protocols", RFC 7859, 1043 DOI 10.17487/RFC7859, May 2016, 1044 . 1046 [RFC7939] Herberg, U., Cole, R., Chakeres, I., and T. Clausen, 1047 "Definition of Managed Objects for the Neighborhood 1048 Discovery Protocol", RFC 7939, DOI 10.17487/RFC7939, 1049 August 2016, . 1051 Authors' Addresses 1053 Thomas Clausen 1055 Phone: +33-6-6058-9349 1056 Email: T.Clausen@computer.org 1057 URI: http://www.thomasclausen.org 1059 Ulrich Herberg 1061 Email: ulrich@herberg.name 1062 URI: http://www.herberg.name 1063 Jiazi Yi 1064 Ecole Polytechnique 1065 91128 Palaiseau Cedex, 1066 France 1068 Phone: +33 1 77 57 80 85 1069 Email: jiazi@jiaziyi.com 1070 URI: http://www.jiaziyi.com/