idnits 2.17.1 draft-ietf-manet-olsrv2-sec-threats-02.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 146: '...oyment of OLSRv2 SHOULD use the securi...' RFC 2119 keyword, line 147: '... specified in [RFC7183] but MAY use another mechanism if more...' RFC 2119 keyword, line 150: '... 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 (May 9, 2016) is 2907 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 6779 (Obsoleted by RFC 7939) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). 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: November 10, 2016 J. Yi 6 Ecole Polytechnique 7 May 9, 2016 9 Security Threats for the Optimized Link State Routing Protocol version 2 10 (OLSRv2) 11 draft-ietf-manet-olsrv2-sec-threats-02 13 Abstract 15 This document analyzes common security threats of the Optimized Link 16 State Routing Protocol version 2 (OLSRv2) and describes their 17 potential impacts on Mobile Ad Hoc Network (MANET) operations. It 18 then analyzes which of these security vulnerabilities can be 19 mitigated when using the mandatory-to-implement security mechanisms 20 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 November 10, 2016. 39 Copyright Notice 41 Copyright (c) 2016 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 Flooding . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . 7 68 3.2.2. Modifying the Hop Count . . . . . . . . . . . . . . . 8 69 4. Effective Topology . . . . . . . . . . . . . . . . . . . . . . 9 70 4.1. Incorrect Forwarding . . . . . . . . . . . . . . . . . . . 9 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) . . . . . . 11 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 . . . . . . 18 82 6.1. Inherent OLSRv2 Resilience . . . . . . . . . . . . . . . . 18 83 6.2. Resilience by using RFC7183 with OLSRv2 . . . . . . . . . 19 84 6.2.1. Topology Map Acquisition . . . . . . . . . . . . . . . 19 85 6.2.2. Effective Topology . . . . . . . . . . . . . . . . . . 20 86 6.2.3. Inconsistent Topology . . . . . . . . . . . . . . . . 20 87 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 89 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 90 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 91 9.2. Informative References . . . . . . . . . . . . . . . . . . 21 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 94 1. Introduction 96 The Optimized Link State Routing Protocol version 2 (OLSRv2) 97 [RFC5148], [RFC5444], [RFC5497], [RFC6130], [RFC7181], [RFC7182], 98 [RFC7183], [RFC7187], [RFC7188] is a successor to OLSR [RFC3626] as a 99 routing protocol for MANETs (Mobile Ad hoc NETworks). OLSRv2 retains 100 the same basic algorithms as its predecessor, however offers various 101 improvements, e.g., a modular and flexible architecture allowing 102 extensions, such as for security, to be developed as add-ons to the 103 basic protocol. 105 The developments reflected in OLSRv2 have been motivated by increased 106 real-world deployment experiences, e.g., from networks such as 107 FunkFeuer [FUNKFEUER], and the requirements presented for continued 108 successful operation of these networks. With participation in such 109 networks increasing (the FunkFeuer community network has, e.g., 110 roughly 400 individual participants at the time of publication of 111 this document), operating with the assumption, that participants can 112 be "trusted" to behave in a non-destructive way, is utopia. Taking 113 the Internet as an example, as participation in the network increases 114 and becomes more diverse, more efforts are required to preserve the 115 integrity and operation of the network. Most SMTP-servers were, 116 e.g., initially available for use by everyone on the Internet - with 117 an increased populace on the Internet, attacks and abuses caused the 118 recommended practice is today to require authentication and 119 accounting for users of such SMTP servers [RFC5068]. 121 As OLSRv2 often is used in wireless environments, it is potentially 122 exposed to different kinds of security threats, some of which are of 123 particular significance as compared to wired networks. As radio 124 signals can be received as well as transmitted by any compatible 125 wireless device within radio range, there is commonly no physical 126 protection as otherwise known for wired networks. 128 A first step towards hardening against attacks disrupting the 129 connectivity of a network, is to understand the vulnerabilities of 130 routing protocol, managing the connectivity. This document therefore 131 analyzes OLSRv2, to understand its inherent vulnerabilities and 132 resiliences. The authors do not claim completeness of the analysis, 133 but hope that the identified attacks, as presented, form a meaningful 134 starting-point for developing and deploying increasingly secured 135 OLSRv2 networks. 137 This document first describes security vulnerabilities to OLSRv2 when 138 it is used without the mandatory-to-implement security mechanisms, as 139 specified in Section 23.5 of [RFC7181]. It then analyzes which of 140 these security vulnerabilities can be mitigated when using the 141 mandatory-to-implement security mechanisms for OLSRv2, and how the 142 vulnerabilities are mitigated. This separation is important since 143 other security mechanisms than the mandatory-to-implement ones may be 144 used in a deployment, as explicitly stated in [RFC7181]: 146 "Any deployment of OLSRv2 SHOULD use the security mechanism 147 specified in [RFC7183] but MAY use another mechanism if more 148 appropriate in an OLSRv2 deployment. For example, for longer-term 149 OLSRv2 deployments, alternative security mechanisms (e.g., 150 rekeying) SHOULD be considered." 152 Moreover, this document is also based on the assumption that no 153 additional security mechanism such as IPsec is used in the IP layer 154 or other mechanisms on lower layers, as not all MANET deployments may 155 be able to accommodate such common protection mechanisms (e.g., 156 because of limited resources of MANET routers). 158 The threats related to NHDP (Neighborhood Discovery Protocol) have 159 been discussed in [RFC7186]. As NHDP is a fundamental block of 160 OLSRv2, the vulnerabilities of NHDP apply also to OLSRv2. 162 It should be noted that many OLSRv2 implementations are configurable, 163 and so an attack on the configuration system (such as [RFC6779] and 164 [RFC7184]) can be used to adversely affect the operation of an OLSRv2 165 implementation. 167 1.1. OLSRv2 Overview 169 OLSRv2 contains three basic processes: Neighborhood Discovery, MPR 170 Flooding and Link State Advertisements, described in the below with 171 sufficient details for elaborating the analyses in this document. 173 1.1.1. Neighborhood Discovery 175 Neighborhood Discovery is the process, whereby each router discovers 176 the routers which are in direct communication range of itself (1-hop 177 neighbors), and detects with which of these it can establish bi- 178 directional communication. Each router sends HELLO messages 179 periodically, listing the identifiers of all the routers from which 180 it has recently received a HELLO message, as well as the "status" of 181 the link (heard or verified bi-directional). A router A receiving a 182 HELLO message from a neighbor B, in which B indicates to have 183 recently received a HELLO message from A, considers the link A-B to 184 be bi-directional. As B lists identifiers of all its neighbors in 185 its HELLO message, A learns the "neighbors of its neighbors" (2-hop 186 neighbors) through this process. HELLO messages are sent 187 periodically, however certain events may trigger non-periodic HELLOs. 188 OLSRv2 [RFC7181] uses NHDP [RFC6130] as its neighborhood discovery 189 mechanism. The vulnerabilities of NHDP are analyzed in [RFC7186]. 191 1.1.2. MPR Flooding 193 Multi Point Relay (MPR) Flooding is the process whereby each router 194 is able to efficiently conduct network-wide broadcasts. Each router 195 designates, from among its bi-directional neighbors, a subset (MPR 196 set) such that a multicast message transmitted by the router and 197 relayed by the MPR set can received by all its 2-hop neighbors. MPR 198 selection is encoded in outgoing HELLO messages. 200 Routers may express, in their HELLO messages, their "willingness" (an 201 integer between 0 "will never" and 7 "will always") to be selected as 202 MPR, which is taken into consideration for the MPR calculation, and 203 which is useful for example when an OLSRv2 network is "planned". The 204 set of routers having selected a given router as MPR is the MPR- 205 selector-set of that router. A study of the MPR flooding algorithm 206 can be found in [MPR-FLOODING]. 208 1.1.3. Link State Advertisement 210 Link State Advertisement is the process whereby routers are 211 determining which link state information to advertise through the 212 network. Each router must advertise, at least, all links between 213 itself and its MPR selectors, in order to allow all routers to 214 calculate shortest paths. Such link state advertisements are carried 215 in Topology Control (TC) messages, broadcast through the network 216 using the MPR flooding process described above. As a router selects 217 MPRs only from among bi-directional neighbors, links advertised in TC 218 are also bi-directional and routing paths calculated by OLSRv2 219 contain only bi-directional links. TCs are sent periodically, 220 however certain events may trigger non-periodic TCs. 222 1.2. Link State Vulnerability Taxonomy 224 Proper functioning of OLSRv2 assumes that (i) each router signals its 225 presence in the network and the topology information that it obtained 226 honestly, (ii) each router can acquire and maintain a topology map, 227 accurately reflecting the effective network topology; and (iii) that 228 the network converges, i.e., that all routers in the network will 229 have sufficiently identical topology maps. 231 An OLSRv2 network can be disrupted by breaking either of these 232 assumptions, specifically (a) routers may be prevented from acquiring 233 a topology map of the network; (b) routers may acquire a topology map 234 that does not reflect the effective network topology; and (c) two or 235 more routers may acquire inconsistent topology maps. 237 1.3. OLSRv2 Attack Vectors 239 Besides "radio jamming", attacks on OLSRv2 consist of a compromised 240 OLSRv2 router injecting "correctly looking, but invalid, control 241 traffic" (TCs, HELLOs) into the network. A compromised OLSRv2 router 242 can either (a) lie about itself (its identification, its willingness 243 to serve as MPR), henceforth Identity Spoofing, or (b) lie about its 244 relationship to other routers (pretend existence of links to other 245 routers), henceforth Link Spoofing. Such attacks may disrupt the the 246 Link State Advertisement process, through targeting the MPR Flooding 247 mechanism, or by causing incorrect link state information to be 248 included in TCs, causing routers to have incomplete, inaccurate or 249 inconsistent topology maps. In a different class of attacks, a 250 compromised OLSRv2 router injects control traffic, designed so as to 251 cause an in-router resource exhaustion, e.g., by causing the 252 algorithms calculating routing tables or MPR sets to be invoked 253 continuously, preventing the internal state of a router from 254 converging. 256 2. Terminology 258 This document uses the terminology and notation defined in [RFC5444], 259 [RFC6130] and [RFC7181]. Additionally, it defines the following 260 terminology: 262 Compromised OLSRv2 router: - An attacker that is present in the 263 network and generates syntactically correct OLSRv2 control 264 messages. Control messages emitted by a compromised OLSRv2 router 265 may contain additional information, or omit information, as 266 compared to a control message generated by a non-compromised 267 OLSRv2 router located in the same topological position in the 268 network. 270 Legitimate OLSRv2 router: - An OLSRv2 router that is not a 271 compromised OLSRv2 router. 273 3. Topology Map Acquisition 275 Topology Map Acquisition relates to the ability for any given router 276 in the network to acquire a representation of the network 277 connectivity. A router, unable to acquire a topology map, is 278 incapable of calculating routing paths and participating in 279 forwarding data. Topology map acquisition can be hindered by (i) TCs 280 to not being delivered to (all) routers in the network, such as what 281 happens in case of Flooding Disruption, or (ii) in case of "jamming" 282 of the communication channel. 284 The jamming and flooding disruption due to identity spoofing and link 285 spoofing have been discussed in [RFC7186]. 287 3.1. Attack on Jittering 289 OLSRv2 incorporates a jittering: a random, but bounded, delay on 290 outgoing control traffic [RFC5148]. This may be necessary when link 291 layers (such as 802.11 [IEEE802.11]) are used that do not guarantee 292 collision-free delivery of frames, and where jitter can reduce the 293 probability of collisions of frames on lower layers. 295 In OLSRv2, TC forwarding is jittered by a value between 0 and 296 MAX_JITTER. In order to reduce the number of transmissions, when a 297 control message is due for transmission, OLSRv2 piggybacks all queued 298 messages into a single transmission. Thus, if a compromised OLSRv2 299 router sends many TCs within a very short time interval, the jitter 300 time of the attacked router tends to 0. This renders jittering 301 ineffective and can lead to collisions on the link layer. 303 In addition to causing more collisions, forwarding a TC with little 304 or no jittering can make sure that the TC message forwarded by a 305 compromised router arrives before the message forwarded by legitimate 306 routers. The compromised router can thus inject malicious content in 307 the TC, and the legitimate message will be discarded as duplicate 308 message. This preemptive action is important for some of the attacks 309 introduced in the following sections. 311 3.2. Hop-count and Hop-limit Attacks 313 The hop-count and hop-limit fields are the only parts of a TC that 314 are modified when forwarding. A compromised OLSRv2 router can modify 315 either of these when forwarding TCs. 317 3.2.1. Modifying the Hop Limit 319 A compromised OLSRv2 router can decrease the hop limit when 320 forwarding a TC. This will reduce the scope of forwarding the 321 message, and may lead to some routers in the network not receiving 322 that TC. Note that this is not necessarily the same as not relaying 323 the message (i.e., setting the hop limit to 0), as illustrated in 324 Figure 1. 326 .---. 327 | X | 328 --'---' __ 329 / \ 330 / \ 331 .---. .---. 332 TC -----> | A | | C | 333 '---' '---' 334 \ .---. / 335 \-- | B |__/ 336 '---' 338 Figure 1: Hop Limit Attack. 340 A TC arrives at and is forwarded by router A, such that it is 341 received by both B and the malicious X. X can forward the TC without 342 any delay (including without jitter) such that its transmissions 343 arrives before that of B at C. Before forwarding, it significantly 344 reduces the hop limit of the message. Router C receives the TC, 345 processes (and forwards) it, and marks it as already received - 346 causing it to discard further copies received from B. Thus, if the TC 347 is forwarded by C, it has a very low hop limit and will not reach the 348 whole network. 350 3.2.2. Modifying the Hop Count 352 A compromised OLSRv2 router can modify the hop count when forwarding 353 a TC. This may have two consequences: (i) if the hop count is set to 354 the maximum value, then the TC will be forwarded no further by, or 355 (ii) artificially manipulating the hop count may affect the validity 356 time as calculated by recipients, when using distance-dependent 357 validity times as defined in [RFC5497] (e.g., as part of a fish-eye 358 extension to OLSR2 [OLSR-FSR] [OLSR-FSR-Scaling]). 360 v_time(1hop)=2s v_time(2hops)=4s v_time(3hops)=6s 361 .---. .---. .---. .---. 362 | A |-------> | B | -------> | X |---------->| C | 363 `---' `---' `---' `---' 365 Figure 2: Different validity times based on the distance in hops. 367 In Figure 2, router A sends a TC with a validity time of two seconds 368 for neighbors that are one hop away, four seconds for routers in a 369 two-hop distance and six seconds in a three-hop distance. If X is a 370 compromised OLSRv2 router and modifies the hop count (say, by 371 decreasing it to 0), then C will calculate the validity time of 372 received information to two seconds - after which it expires unless 373 refreshed. If TCs from A are sent less frequently than that up to 3 374 hops, this causes links advertised in such TCs to be only 375 intermittently available to C. 377 4. Effective Topology 379 Link-state protocols assume that each router can acquire an accurate 380 topology map, reflecting the effective network topology. This 381 implies that the routing protocol, through its message exchange, 382 identifies a path from a source to a destination, and this path is 383 valid for forwarding data traffic. If an attacker disturbs the 384 correct protocol behavior, the perceived topology map of a router can 385 permanently differ from the effective topology. 387 Considering the example in Figure 3(a), which illustrates the 388 topology map as acquired by router S. This topology map indicates 389 that the routing protocol has identified that for S, a path exists to 390 D via B, which it therefore assumes can be used for transmitting 391 data. If, effectively, B does not forward data traffic from S, then 392 the topology map in S does not accurately reflect the effective 393 network topology. Rather, the effective network topology from the 394 point of view of S would be as indicated in Figure 3(b): D is not 395 part of the network reachable from router S. 397 .---. .---. .---. .---. .---. 398 | S |----| B |----| D | | S |----| B | 399 `---' `---' `---' `---' `---' 401 (a) (b) 403 Figure 3: Incorrect Data Traffic Forwarding. 405 Some of the attacks related to NHDP, such as message timing attack, 406 indirect channel overloading have been discussed in [RFC7186]. Other 407 threats specific to OLSRv2 are further detailed in this section. 409 4.1. Incorrect Forwarding 411 OLSRv2 routers exchange information using link-local transmissions 412 (link-local multicast or limited broadcast) for their control 413 messages, with the routing process in each router retransmitting 414 received messages destined for network-wide diffusion. Thus, if the 415 operating system in a router is not configured to enable forwarding, 416 this will not affect the operating of the routing protocol, or the 417 topology map acquired by the routing protocol. It will, however, 418 cause a discrepancy between the effective topology and the topology 419 map, as indicated in Figure 3(a) and Figure 3(b). 421 This situation is not hypothetical. A common error seen when 422 deploying OLSRv2-based networks using Linux-based computers as router 423 is to neglect enabling IP forwarding, which effectively becomes an 424 accidental attack of this type. 426 4.2. Wormholes 428 A wormhole, depicted in the example in Figure 4, may be established 429 between two collaborating devices, connected by an out-of-band 430 channel. These devices send traffic through the "tunnel" to their 431 alter-ego, which "replays" the traffic. Thus, routers D and S appear 432 as if direct neighbors and reachable from each other in 1 hop through 433 the tunnel, with the path through the MANET being 100 hops long. 435 .---. .---. 436 | S |---- ....100-hop long path ... ---| D | 437 `---. / `---' 438 \ / 439 \ / 440 \X=============================X 442 1-hop path via wormhole 444 Figure 4: Wormholing between two collaborating devices not 445 participating in the routing protocol. 447 The consequences of such a wormhole in the network depends on the 448 detailed behavior of the wormhole. If the wormhole relays only 449 control traffic, but not data traffic, the same considerations as in 450 Section 4.1 applies. If, however, the wormhole relays all traffic, 451 control and data alike, it is connectivity-wise identical to a usable 452 link - and the routing protocol will correctly generate a topology 453 map reflecting the effective network topology. The efficiency of the 454 topology so obtained depends on (i) the wormhole characteristics, 455 (ii) how the wormhole presents itself, and (iii) how paths are 456 calculated. 458 Assuming that paths are calculated with unit-cost for all links, 459 including the "link" presented by the wormhole: if the real 460 characteristics of the wormhole are as-if it was a path of more than 461 100 hops (e.g., with respect to delay, bandwidth, etc.), then the 462 presence of the wormhole results in a degradation in performance as 463 compared to using the non-wormhole path. Conversely, if the "link" 464 presented by the wormhole has better characteristics, the wormhole 465 results in improved performance. 467 If paths are calculated using non-unit-costs for all links, and if 468 the cost of the "link" presented by the wormhole correctly represents 469 the actual cost (e.g., if the cost is established through 470 measurements across the wormhole), then the wormhole may in the worst 471 case cause no degradation in performance, in the best case improve 472 performance by offering a better path. If the cost of the "link" 473 presented by the wormhole is misrepresented, then the same 474 considerations as for unit-cost links apply. 476 An additional consideration with regards to wormholes is, that such 477 may present topologically attractive paths for the network - however 478 it may be undesirable to have data traffic transit such a path: an 479 attacker could, by virtue of introducing a wormhole, acquire the 480 ability to record and inspect transiting data traffic. 482 4.3. Sequence Number Attacks 484 OLSRv2 uses two different sequence numbers in TCs, to (i) avoid 485 processing and forwarding the same message more than once (Message 486 Sequence Number), and (ii) to ensure that old information, arriving 487 late due to, e.g., long paths or other delays, is not allowed to 488 overwrite fresher information (Advertised Neighbor Sequence Number - 489 ANSN). 491 4.3.1. Message Sequence Number 493 An attack may consist of a compromised OLSRv2 router spoofing the 494 identity of another router in the network, and transmitting a large 495 number of TCs, each with different Message Sequence Numbers. 496 Subsequent TCs with the same sequence numbers, originating from the 497 router whose identity was spoofed, would hence be ignored, until 498 eventually information concerning these "spoofed" TCs expires. 500 4.3.2. Advertised Neighbor Sequence Number (ANSN) 502 An attack may consist of a compromised OLSRv2 router spoofing the 503 identity of another router in the network, and transmitting a single 504 TC, with an ANSN significantly larger than that which was last used 505 by the legitimate router. Routers will retain this larger ANSN as 506 "the most fresh information" and discard subsequent TCs with lower 507 sequence numbers as being "old". 509 4.4. Indirect Jamming 511 Indirect Jamming is an attack in which a compromised OLSRv2 router 512 is, by its actions, causing legitimate routers to generate inordinate 513 amounts of control traffic, thereby increasing both channel 514 occupation and the overhead incurred in each router for processing 515 this control traffic. This control traffic will be originated from 516 legitimate routers, thus to the wider network, the malicious device 517 may remain undetected. 519 The general mechanism whereby a malicious router can cause indirect 520 jamming is for it to participate in the protocol by generating 521 plausible control traffic, and to tune this control traffic to in 522 turn trigger receiving routers to generate additional traffic. For 523 OLSRv2, such an indirect attack can be directed at, respectively, the 524 Neighborhood Discovery mechanism and the Link State Advertisement 525 mechanism. 527 The most efficient indirect jamming attack in OLSRv2 is to target 528 control traffic, destined for network-wide diffusion. This is 529 illustrated in Figure 5. 531 The malicious router X selects router A as MPR at time t0 in a HELLO. 532 This causes X to appear as MPR selector for A and, consequently, A 533 sets X to be advertised in its "Neighbor Set" and increments the 534 associated "Advertised Neighbor Sequence Number" (ANSN). Router A 535 must, then, advertise the link between itself and X in subsequent 536 outgoing TCs (t1), also including the ANSN in such TCs. Upon X 537 having received this TC, it declares the link between itself and A as 538 no longer valid (t2) in a HELLO (indicating the link to a as LOST). 539 Since only symmetric links are advertised by OLSRv2 routers, A will 540 upon receipt hereof remove X from the set of advertised neighbors and 541 increment the ANSN. Router A will then in subsequent TCs advertise 542 the remaining set of advertised neighbors (i.e., with X removed) and 543 the corresponding ANSN (t3). Upon X having received this information 544 in another TC from A, it may repeat this cycle, alternating 545 advertising the link A-X as "LOST" and as "MPR". 547 broadcast TC ANS={} TC:() 548 (X-A) ANSN ANSN++ ANSN 549 .---. .---. .---. .---. 550 | A | | A | | A | | A | 551 '---' '---' '---' '---' 552 ^ | ^ | 553 | | | | 554 | select | |indicate | 555 | as MPR | |as LOST | 556 .---. .---. .---. .---. 557 | X | | X | | X | | X | 558 '---' '---' '---' '---' 560 t0 t1 t2 t3 562 Figure 5: Indirect Jamming in Link State Advertisement: the malicious 563 X flips between link status MPR and LOST. 565 Routers receiving a TC will parse and process this message, 566 specifically updating their topology map as a consequence of 567 successful receipt. If the ANSN between two successive TCs from the 568 same router has incremented, then the topology has changed and 569 routing sets are to be recalculated. This is a potentially 570 computationally costly operation. 572 A compromised OLSRv2 router may chose to conduct this attack against 573 all its neighbors, thus attaining maximum disruptive impact on the 574 network with relatively little overhead of its own: other than 575 participating in the Neighborhood Discovery procedure, the 576 compromised OLSRv2 router will monitor TCs generated by its neighbors 577 and alternate the advertised status for each such neighbor, between 578 "MPR" and "LOST". The compromised OLSRv2 router will indicate its 579 willingness to be zero (thus, avoid being selected as MPR) and may 580 ignore all other protocol operations, while still remaining effective 581 as an attacker. 583 The basic operation of OLSRv2 employs periodic message emissions, and 584 by this attack it can be ensured that each such periodic message will 585 entail routing table recalculation in all routers in the network. 587 If the routers in the network have "triggered TCs" enabled, this 588 attack may also cause an increased TC frequency. Triggered TCs are 589 intended to allow a (stable) network to have relatively low TC 590 emission frequencies, yet still allow link breakage or link emergence 591 to be advertised through the network rapidly. A minimum message 592 interval (typically much smaller than the regular periodic message 593 interval) is imposed, to rate-limit worst-case message emissions. 594 This attack can cause the TC interval to, permanently, become equal 595 to the minimum message interval. [RFC7181] proposes as default that 596 the minimum TC interval be 0.25 x TC interval. 598 Indirect Jamming by a compromised OLSRv2 router can thus have two 599 effects: it may cause increased frequency of TC generation and 600 transmission, and it will cause additional routing table 601 recalculation in all routers in the network. 603 5. Inconsistent Topology 605 Inconsistent topology maps can occur by a compromised OLSRv2 router 606 employing either of identity spoofing or link spoofing for conducting 607 an attack against an OLSRv2 network. The threats related to NHDP, 608 such as identity spoofing in NHDP, link spoofing in NHDP and creating 609 loops have been illustrated in [RFC7186]. This section mainly 610 addresses the vulnerabilities in [RFC7181]. 612 5.1. Identity Spoofing 614 Identity spoofing can be employed by a compromised OLSRv2 router via 615 the Neighborhood Discovery process and via the Link State 616 Advertisement process. Either of them causes inconsistent topology 617 maps in routers in the network. The inconsistent topology maps due 618 to neighborhood discovery has been discussed in [RFC7186]. For 619 OLSRv2, the attack on link state advertisements can also cause 620 inconsistent topology maps. 622 An inconsistent topology map may occur when the compromised OLSRv2 623 router takes part in the Link State Advertisement (LSA) procedure, by 624 selecting a neighbor as MPR, which in turn advertises the spoofed 625 identities of the compromised OLSRv2 router. This attack will alter 626 the topology maps of all routers of the network. 628 A -- B -- C -- D -- E -- F -- X 630 (X spoofs A) 632 Figure 6: Identity Spoofing: compromised OLSRv2 router X spoofs the 633 identity of A, leading to a wrongly perceived topology. 635 In Figure 6, router X spoofs the address of router A. If X selects F 636 as MPR, all routers in the network will be informed about the link 637 F-A by the TCs originating from F. Assuming that (the real) A selects 638 B as MPR, the link B-A will also be advertised in the network. 640 When calculating paths, B and C will calculate paths to A via B, as 641 illustrated in Figure 7(a); for these routers, the shortest path to A 642 is via B. E and F will calculate paths to A via F, as illustrated in 643 Figure 7(b); for these routers, the shortest path to A is via the 644 compromised OLSRv2 router X, and these are thus disconnected from the 645 real A. D will have a choice: the path calculated to A via B is of 646 the same length as the path via the compromised OLSRv2 router X, as 647 illustrated in Figure 7(b). 649 In general, the following observations can be made: 651 o The network will be split in two, with those routers closer to B 652 than to X reaching A, whereas those routers closer to X than to B 653 will be unable to reach A. 655 o Routers beyond B, i.e., routers beyond one hop away from A will be 656 unable to detect this identity spoofing. 658 The identity spoofing attack via the Link State Advertisement 659 procedure has a higher impact than the attack on the neighborhood 660 discovery procedure, since it alters the topology maps of all routers 661 in the network, and not only in the 2-hop neighborhood. However, the 662 attack is easier to detect by other routers in the network. Since 663 the compromised OLSRv2 router is advertised in the whole network, 664 routers whose identities are spoofed by the compromised OLSRv2 router 665 can detect the attack. For example, when a receives a TC from F 666 advertising the link F-A, it can deduce that some entity is injecting 667 incorrect Link State information as it does not have F as one of its 668 direct neighbors. 670 (X spoofs A) 672 A < ---- B < ---- C E ----> F ----> X 674 (a) Routers B and C (b) Routers E and F 676 A < --- B < --- C < --- D ---> E ---> F ----> X 678 (X spoofs A) 680 Figure 7: Routing paths towards A, as calculated by the different 681 routers in the network in presence of a compromised OLSRv2 router X, 682 spoofing the address of A. 684 As the compromised OLSRv2 router X does not itself send the TCs, but 685 rather, by virtue of MPR selection, ensures that the addresses it 686 spoofs are advertised in TCs from its MPR selector F, the attack may 687 be difficult to counter: simply ignoring TCs that originate from F 688 may also suppress the link state information for other, legitimate, 689 MPR selectors of F. 691 Identity spoofing by a compromised OLSRv2 router, participating in 692 the Link State Advertisement process by selecting MPRs only, thus, 693 creates a situation wherein two or more routers have substantially 694 inconsistent topology maps: traffic for an identified destination is, 695 depending on where in the network it appears, delivered to different 696 routers. 698 5.2. Link Spoofing 700 Link Spoofing is a situation in which a router advertises non- 701 existing links to another router (possibly not present in the 702 network). Essentially, TCs and HELLOs both advertise links to direct 703 neighbor routers, with the difference being the scope of the 704 advertisement. Thus, link spoofing consists of a compromised OLSRv2 705 router, reporting that it has neighbors routers which are, either, 706 not present in the network, or which are effectively not neighbors of 707 the compromised OLSRv2 router. 709 It can be noted that a situation similar to link spoofing may occur 710 temporarily in an OLSR or OLSRv2 network without compromised OLSRv2 711 routers: if A was, but is no more, a neighbor of B, then A may still 712 be advertising a link to B for the duration of the time it takes for 713 the the Neighborhood Discovery process to determine this changed 714 neighborhood. 716 In the context of this document, link spoofing refers to a persistent 717 situation where a compromised OLSRv2 router intentionally advertises 718 links to other routers, for which it is not a direct neighbor. 720 5.2.1. Inconsistent Topology Maps due to Link State Advertisements 722 Figure 8 illustrates a network, in which the compromised OLSRv2 723 router X spoofs links to a existing router A by participating in the 724 Link State Advertisement process and including this non-existing link 725 in its advertisements. 727 A --- B --- C --- D --- E --- F --- G --- H --- X 729 (X spoofs the link to A) 731 Figure 8: Link Spoofing: The compromised OLSRv2 router X advertises a 732 spoofed link to A in its TCs, thus all routers will record both of 733 the links X-A and B-A. 735 As TCs are flooded through the network, all routers will receive and 736 record information describing a link X-A in this link state 737 information. If A has selected router B as MPR, B will likewise 738 flood this link state information through the network, thus all 739 routers will receive and record information describing a link B-A. 741 When calculating routing paths, B, C and D will calculate paths to A 742 via B, as illustrated in Figure 9(a); for these routers, the shortest 743 path to A is via B. F and G will calculate paths to A via X, as 744 illustrated in Figure 9(b); for these routers, the shortest path to A 745 is via X, and these are thus disconnected from the real router A. E 746 will have a choice: the path calculated to A via B is of the same 747 length as the path via X, as illustrated in Figure 9(b). 749 A < --- B < --- C < --- D F ---> G ---> X ---> A 751 (a) Routers B, C, and D (b) Routers F and G 753 A < --- B < --- C < --- D < --- E ---> F ---> G ---> X ---> A 755 (c) Router E 757 Figure 9: Routing paths towards router A, as calculated by the 758 different routers in the network in presence of a compromised OLSRv2 759 router X, spoofing a link to router A. 761 In general, the following observations can be made: 763 o The network will be separated in two, with those routers closer to 764 B than to X reaching A, whereas those routers closer to X than to 765 B unable to reach A. 767 o Routers beyond B, i.e., routers beyond one hop away from A will be 768 unable to detect this link spoofing. 770 The impact of this attack is similar to that presented in 771 Section 5.2.1, however, is easier to detect as the compromised OLSRv2 772 router is generating control traffic reaching the entire network. 774 6. Mitigation of Security Vulnerabilities for OLSRv2 776 As described in Section 1, [RFC7183] specifies a security mechanism 777 for OLSRv2 that is mandatory to implement. However, deployments may 778 choose to use different security mechanisms if more appropriate. 779 Therefore, it is important to understand both the inherent resilience 780 of OLSRv2 against security vulnerabilities when not using the 781 mechanisms specified in [RFC7183], as well as the protection that 782 [RFC7183] provides when used in a deployment. 784 6.1. Inherent OLSRv2 Resilience 786 OLSRv2 (without the mandatory-to-implement security mechanisms in 787 [RFC7183]) provides some inherent resilience against part of the 788 attacks described in this document. In particular, it provides the 789 following resilience: 791 o Sequence numbers: OLSRv2 employs message sequence numbers, 792 specific per router identity and message type. Routers keep an 793 "information freshness" number (ANSN), incremented each time the 794 content of a Link State Advertisement from a router changes. This 795 allows rejecting "old" information and duplicate messages, and 796 provides some protection against "message replay". This, however, 797 also presents an attack vector (Section 4.3). 799 o Ignoring uni-directional links: The Neighborhood Discovery process 800 detects and admits only bi-directional links for use in MPR 801 selection and Link State Advertisement. Jamming attacks may 802 affect only reception of control traffic, however OLSRv2 will 803 correctly recognize, and ignore, such a link as not bi- 804 directional. 806 o Message interval bounds: The frequency of control messages, with 807 minimum intervals imposed for HELLO and TCs. This may limit the 808 impact from an indirect jamming attack (Section 4.4). 810 o Additional reasons for rejecting control messages: The OLSRv2 811 specification includes a list of reasons, for which an incoming 812 control message should be rejected as malformed - and allows that 813 a protocol extension may recognize additional reasons for OLSRv2 814 to consider a message malformed. This allows - together with the 815 flexible message format [RFC5444] - addition of security 816 mechanisms, such as digital signatures, while remaining compliant 817 with the OLSRv2 standard specification. 819 6.2. Resilience by using RFC7183 with OLSRv2 821 [RFC7183] specifies mechanisms for integrity and replay protection 822 for NHDP and OLSRv2, using the generalized packet/message format 823 described in [RFC5444] and the TLV definitions in [RFC7182]. The 824 specification describes how to add an Integrity Check Value (ICV) in 825 a TLV to each control message, providing a digital signature of the 826 content of the message using HMAC/SHA-256. In addition, a timestamp 827 TLV is added to the message prior to creating the ICV, enabling 828 replay protection of messages. The document specifies how to sign 829 outgoing messages and how to verify incoming messages, as well as 830 under which circumstances a non-valid message is rejected. Because 831 of the HMAC/SHA-256 ICV, a shared key between all routers in the 832 MANET is assumed. A router without valid credentials is not able to 833 create an ICV that can be correctly verified by other routers in the 834 MANET; therefore, such an incorrectly signed message will be rejected 835 by other MANET routers, and the router cannot participate in the 836 OLSRv2 routing process (i.e., the malicious router will be ignored by 837 other, legitimate routers). [RFC7183] does not address the case 838 where a router with valid credentials has been compromised. Such a 839 compromised router will not be excluded from the routing process, and 840 other means of detecting such a router are necessary if required in a 841 deployment (in addition to using asymmetric keys, allowing to revoke 842 access to one particular router instead of revoking the shared key 843 used by all routers in the MANET). 845 In the following sections, each of the vulnerabilities described 846 earlier in this document will be evaluated in terms of whether OLSRv2 847 with the mechanisms in [RFC7183] provides sufficient protection 848 against the attack. It is implicitly assumed in each of the 849 following sections that [RFC7183] is used with OLSRv2. 851 6.2.1. Topology Map Acquisition 853 Attack on Jittering - As only OLSRv2 routers with valid credentials 854 can participate in the routing process, a malicious router cannot 855 reduce the jitter time of an attacked router to 0 by sending many 856 TC messages in a short time. The attacked router would reject all 857 the incoming messages as "invalid" and not forward them. The same 858 applies for the case where a malicious router wants to assure that 859 by forcing a zero jitter interval, the message arrives before the 860 same message forwarded by legitimate routers. 862 Modifying the Hop Limit - As the hop limit is not protected by 863 [RFC7183] (since it is a mutual field, changing at every hop), 864 this attack is still feasible. 866 Modifying the Hop Count - Similarly to the hop limit, as the hop 867 count is not protected by [RFC7183] (since it is a mutual field, 868 changing at every hop), this attack is still feasible. 870 6.2.2. Effective Topology 872 Incorrect Forwarding - As only OLSRv2 routers with valid credentials 873 can participate in the routing process, a malicious router will 874 not be part of the topology of other legitimate OLSRv2 routers. 875 Therefore, no data traffic will be sent to the malicious router 876 for forwarding. 878 Wormholes - Since a wormhole consists of at least two devices 879 forwarding (unmodified) traffic, this attack is still feasible and 880 undetectable by the OLSRv2 routing process since the attack does 881 not involve the OLSRv2 protocol itself (but rather lower layers). 882 By using [RFC7183], it can at least be assured that the content of 883 the control messages is not modified while being forwarded via the 884 wormhole. Moreover, the timestamp TLV assures that the forwarding 885 can only be done in a short time window after the actual TC 886 message has been sent. 888 Message Sequence Number - As the message sequence number is included 889 in the ICV calculation, OLSRv2 is protected against this attack. 891 Advertised Neighbor Sequence Number (ANSN) - As the ANSN is included 892 in the ICV calculation, OLSRv2 is protected against this attack. 894 Indirect Jamming - Since the control messages of a malicious router 895 will be rejected by other legitimate OLSRv2 routers in the MANET, 896 this attack is mitigated. 898 6.2.3. Inconsistent Topology 900 Identity Spoofing - Since the control messages of a malicious router 901 will be rejected by other legitimate OLSRv2 routers in the MANET, 902 a router without valid credentials may spoof its identity (e.g., 903 IP source address or message originator address), but the messages 904 will be ignored by other routers. As the mandatory mechanism in 905 [RFC7183] uses shared keys amongst all MANET routers, a single 906 compromised router may spoof its identity and cause harm to the 907 network stability. Removing this one malicious router once 908 detected implies rekeying all other routers in the MANET. 909 Asymmetric keys, in particular when using identity based 910 signatures, such as specified in [IBS] may further allow to revoke 911 single routers and to verify their identity based on the ICV 912 itself. 914 Link Spoofing - Similar to identity spoofing, a malicious router 915 without valid credential may spoof links, but its control messages 916 will be rejected by other routers, thereby mitigating the attack. 918 Inconsistent Topology Maps due to Link State Advertisements - The 919 same considerations as for link spoofing apply. 921 7. Security Considerations 923 This document does not specify a protocol or a procedure. The 924 document, however, reflects on security considerations for OLSRv2, 925 and its constituent parts, including NHDP. 927 8. IANA Considerations 929 This document has no actions for IANA. 931 9. References 933 9.1. Normative References 935 [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, 936 "The Optimized Link State Routing Protocol Version 2", 937 RFC 7181, April 2014. 939 [RFC7186] Yi, J., Herberg, U., and T. Clausen, "Security Threats for 940 the Neighborhood Discovery Protocol (NHDP)", RFC 7186, 941 April 2014. 943 9.2. Informative References 945 [FUNKFEUER] 946 "http://www.funkfeuer.at/". 948 [IBS] Dearlove, C., "Identity-Based Signatures for MANET Routing 949 Protocols", work in progress draft-ietf-manet-ibs-05, 950 March 2016. 952 [IEEE802.11] 953 "IEEE 802.11: Wireless LAN Medium Access Control (MAC) and 954 Physical Layer (PHY) Spec.", 2007. 956 [MPR-FLOODING] 957 Qayyum, A., Viennot, L., and A. Laouiti, "Multipoint 958 relaying: An efficient technique for flooding in mobile 959 wireless networks.", 2001. 961 [OLSR-FSR] 962 Clausen, T., "Combining Temporal and Spatial Partial 963 Topology for MANET routing-Merging OLSR and FSR, 964 Proceedings of the 2003 IEEE Conference of Wireless 965 Personal Multimedia Communications (WPMC 03)", 2003. 967 [OLSR-FSR-Scaling] 968 Adjih, C., Baccelli, E., Clausen, T., Jacquet, P., and G. 969 Rodolakis, "Fish eye OLSR scaling properties, IEEE Journal 970 of Communication and Networks (JCN), Special Issue on 971 Mobile Ad Hoc Wireless Networks", 2004. 973 [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State 974 Routing Protocol", RFC 3626, October 2003. 976 [RFC5068] Hutzler, C., Crocker, D., Resnick, P., Allman, E., and T. 977 Finch, "Email Submission Operations: Access and 978 Accountability Requirements", RFC 5068, BCP 134, 979 October 2007. 981 [RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter 982 Considerations in Mobile Ad Hoc Networks (MANETs)", 983 RFC 5148, February 2008. 985 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 986 "Generalized MANET Packet/Message Format", RFC 5444, 987 February 2009. 989 [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value 990 Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, 991 March 2009. 993 [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc 994 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 995 RFC 6130, April 2011. 997 [RFC6779] Herberg, U., Cole, R., and I. Chakeres, "Definition of 998 Managed Objects for the Neighborhood Discovery Protocol", 999 RFC 6779, May 2012. 1001 [RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity 1002 Check Value and Timestamp TLV Definitions for Mobile Ad 1003 Hoc Networks (MANETs)", RFC 7182, April 2014. 1005 [RFC7183] Herberg, U., Dearlove, C., and T. Clausen, "Integrity 1006 Protection for the Neighborhood Discovery Protocol (NHDP) 1007 and Optimized Link State Routing Protocol Version 2 1008 (OLSRv2)", RFC 7183, April 2014. 1010 [RFC7184] Herberg, U., Cole, R., and T. Clausen, "Definition of 1011 Managed Objects for the Optimized Link State Routing 1012 Protocol Version 2", RFC 7184, April 2014. 1014 [RFC7187] Dearlove, C. and T. Clausen, "Routing Multipoint Relay 1015 Optimization for the Optimized Link State Routing Protocol 1016 Version 2 (OLSRv2)", RFC 7187, April 2014. 1018 [RFC7188] Dearlove, C. and T. Clausen, "Optimized Link State Routing 1019 Protocol Version 2 (OLSRv2) and MANET Neighborhood 1020 Discovery Protocol (NHDP) Extension TLVs", RFC 7188, 1021 April 2014. 1023 Authors' Addresses 1025 Thomas Clausen 1027 Phone: +33-6-6058-9349 1028 Email: T.Clausen@computer.org 1029 URI: http://www.thomasclausen.org 1031 Ulrich Herberg 1033 Email: ulrich@herberg.name 1034 URI: http://www.herberg.name 1036 Jiazi Yi 1037 Ecole Polytechnique 1038 91128 Palaiseau Cedex, 1039 France 1041 Phone: +33 1 77 57 80 85 1042 Email: jiazi@jiaziyi.com 1043 URI: http://www.jiaziyi.com/