idnits 2.17.1 draft-clausen-manet-olsrv2-sec-threats-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 12, 2014) is 3545 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-ietf-manet-ibs-02 -- Obsolete informational reference (is this intentional?): RFC 6779 (Obsoleted by RFC 7939) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 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 4 Intended status: Informational U. Herberg 5 Expires: February 13, 2015 Fujitsu Laboratories of America 6 J. Yi 7 LIX, Ecole Polytechnique 8 August 12, 2014 10 Security Threats for the Optimized Link State Routing Protocol version 2 11 (OLSRv2) 12 draft-clausen-manet-olsrv2-sec-threats-01 14 Abstract 16 This document analyzes common security threats of the Optimized Link 17 State Routing Protocol version 2 (OLSRv2) and describes their 18 potential impacts on Mobile Ad Hoc Network (MANET) operations. It 19 then analyzes which of these security vulnerabilities can be 20 mitigated when using the mandatory-to-implement security mechanisms 21 for OLSRv2, and how the vulnerabilities are mitigated. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on February 13, 2015. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. OLSRv2 Overview . . . . . . . . . . . . . . . . . . . . . 4 59 1.1.1. Neighborhood Discovery . . . . . . . . . . . . . . . . 4 60 1.1.2. MPR Flooding . . . . . . . . . . . . . . . . . . . . . 5 61 1.1.3. Link State Advertisement . . . . . . . . . . . . . . . 5 62 1.2. Link State Vulnerability Taxonomy . . . . . . . . . . . . 5 63 1.3. OLSRv2 Attack Vectors . . . . . . . . . . . . . . . . . . 6 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 3. Topology Map Acquisition . . . . . . . . . . . . . . . . . . . 7 66 3.1. Attack on Jittering . . . . . . . . . . . . . . . . . . . 7 67 3.2. Hop-count and Hop-limit Attacks . . . . . . . . . . . . . 7 68 3.2.1. Modifying the Hop Limit . . . . . . . . . . . . . . . 7 69 3.2.2. Modifying the Hop Count . . . . . . . . . . . . . . . 8 70 4. Effective Topology . . . . . . . . . . . . . . . . . . . . . . 9 71 4.1. Incorrect Forwarding . . . . . . . . . . . . . . . . . . . 10 72 4.2. Wormholes . . . . . . . . . . . . . . . . . . . . . . . . 10 73 4.3. Sequence Number Attacks . . . . . . . . . . . . . . . . . 11 74 4.3.1. Message Sequence Number . . . . . . . . . . . . . . . 11 75 4.3.2. Advertised Neighbor Sequence Number (ANSN) . . . . . . 12 76 4.4. Indirect Jamming . . . . . . . . . . . . . . . . . . . . . 12 77 5. Inconsistent Topology . . . . . . . . . . . . . . . . . . . . 14 78 5.1. Identity Spoofing . . . . . . . . . . . . . . . . . . . . 14 79 5.2. Link Spoofing . . . . . . . . . . . . . . . . . . . . . . 16 80 5.2.1. Inconsistent Topology Maps due to Link State 81 Advertisements . . . . . . . . . . . . . . . . . . . . 16 82 6. Mitigation of Security Vulnerabilities for OLSRv2 . . . . . . 18 83 6.1. Inherent OLSRv2 Resilience . . . . . . . . . . . . . . . . 18 84 6.2. Resilience by using RFC7183 with OLSRv2 . . . . . . . . . 19 85 6.2.1. Topology Map Acquisition . . . . . . . . . . . . . . . 19 86 6.2.2. Effective Topology . . . . . . . . . . . . . . . . . . 20 87 6.2.3. Inconsistent Topology . . . . . . . . . . . . . . . . 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 [RFC5148], [RFC5444], [RFC5497], [RFC6130], [RFC7181], [RFC7182], 99 [RFC7183], [RFC7187], [RFC7188] is a successor to OLSR [RFC3626] as a 100 routing protocol for MANETs (Mobile Ad hoc NETworks). OLSRv2 retains 101 the same basic algorithms as its predecessor, however offers various 102 improvements, e.g., a modular and flexible architecture allowing 103 extensions, such as for security, to be developed as add-ons to the 104 basic protocol. 106 The developments reflected in OLSRv2 have been motivated by increased 107 real-world deployment experiences, e.g., from networks such as 108 FunkFeuer [FUNKFEUER], and the requirements presented for continued 109 successful operation of these networks. With participation in such 110 networks increasing (the FunkFeuer community network has, e.g., 111 roughly 400 individual participants), operating with the assumption, 112 that participants can be "trusted" to behave in a non-destructive 113 way, is utopia. Taking the Internet as an example, as participation 114 in the network increases and becomes more diverse, more efforts are 115 required to preserve the integrity and operation of the network. 116 Most SMTP-servers were, e.g., initially available for use by everyone 117 on the Internet - with an increased populace on the Internet, attacks 118 and abuses caused the recommended practice is today to require 119 authentication and accounting for users of such SMTP servers 120 [RFC5068]. 122 As OLSRv2 often is used in wireless environments, it is potentially 123 exposed to different kinds of security threats, some of which are of 124 particular significance as compared to wired networks. As radio 125 signals can be received as well as transmitted by any compatible 126 wireless device within radio range, there is commonly no physical 127 protection as otherwise known for wired networks. 129 A first step towards hardening against attacks disrupting the 130 connectivity of a network, is to understand the vulnerabilities of 131 routing protocol, managing the connectivity. This document therefore 132 analyzes OLSRv2, to understand its inherent vulnerabilities and 133 resiliences. The authors do not claim completeness of the analysis, 134 but hope that the identified attacks, as presented, form a meaningful 135 starting-point for developing secured OLSRv2 networks. 137 This document first describes security vulnerabilities to OLSRv2 when 138 it is used without the mandatory-to-implement security mechanisms 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 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 NHDP 165 implementation. 167 The NHDP and OLSRv2 MIB modules [RFC6779] and [RFC7184] might help 168 monitoring some of the security attacks mentioned in this document. 169 [MGMT-SNAP] provides a snapshot of OLSRv2-routed MANET management as 170 currently deployed. 172 1.1. OLSRv2 Overview 174 OLSRv2 contains three basic processes: Neighborhood Discovery, MPR 175 Flooding and Link State Advertisements, described in the below with 176 sufficient details for elaborating the analyses in this document. 178 1.1.1. Neighborhood Discovery 180 Neighborhood Discovery is the process, whereby each router discovers 181 the routers which are in direct communication range of itself (1-hop 182 neighbors), and detects with which of these it can establish bi- 183 directional communication. Each router sends HELLO messages 184 periodically, listing the identifiers of all the routers from which 185 it has recently received a HELLO message, as well as the "status" of 186 the link (heard or verified bi-directional). A router a receiving a 187 HELLO message from a neighbor b, in which b indicates to have 188 recently received a HELLO message from a, considers the link a-b to 189 be bi-directional. As b lists identifiers of all its neighbors in 190 its HELLO message, a learns the "neighbors of its neighbors" (2-hop 191 neighbors) through this process. HELLO messages are sent 192 periodically, however certain events may trigger non-periodic HELLOs. 193 OLSRv2 [RFC7181] uses NHDP [RFC6130] as its neighborhood discovery 194 mechanism. The vulnerabilities of NHDP are analyzed in [RFC7186]. 196 1.1.2. MPR Flooding 198 Multi Point Relay (MPR) Flooding is the process whereby each router 199 is able to, efficiently, conduct network-wide broadcasts. Each 200 router designates, from among its bi-directional neighbors, a subset 201 (MPR set) such that a multicast message transmitted by the router and 202 relayed by the MPR set can received by all its 2-hop neighbors. MPR 203 selection is encoded in outgoing HELLO messages. 205 Routers may express, in their HELLO messages, their "willingness" 206 (integer between 1 "will never" and 7 "will always") to be selected 207 as MPR, which is taken into consideration for the MPR calculation, 208 and which is useful for example when an OLSRv2 network is "planned". 209 The 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 is the process whereby routers are 216 determining 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 link state advertisements are carried 220 in Topology Control (TC) messages, broadcast through the network 221 using the MPR flooding process described above. As a router selects 222 MPRs only from among bi-directional neighbors, links advertised in TC 223 are also bi-directional and routing paths calculated by OLSRv2 224 contain only bi-directional links. TCs are sent periodically, 225 however certain events may trigger non-periodic TCs. 227 1.2. Link State Vulnerability Taxonomy 229 Proper functioning of OLSRv2 assumes that (i) each router signals its 230 presence in the network and the topology information that it obtained 231 honestly, (ii) each router can acquire and maintain a topology map, 232 accurately reflecting the effective network topology; and (iii) that 233 the network converges, i.e., that all routers in the network will 234 have sufficiently identical topology maps. 236 An OLSRv2 network can be disrupted by breaking either of these 237 assumptions, specifically (a) routers may be prevented from acquiring 238 a topology map of the network; (b) routers may acquire a topology map 239 that does not reflect the effective network topology; and (c) two or 240 more routers may acquire inconsistent topology maps. 242 1.3. OLSRv2 Attack Vectors 244 Besides "radio jamming", attacks on OLSRv2 consist of a compromised 245 OLSRv2 router injecting "correctly looking, but invalid, control 246 traffic" (TCs, HELLOs) into the network. A compromised OLSRv2 router 247 can either (a) lie about itself (its identification, its willingness 248 to serve as MPR), henceforth Identity Spoofing, or (b) lie about its 249 relationship to other routers (pretend existence of links to other 250 routers), henceforth Link Spoofing. Such attacks may disrupt the the 251 Link State Advertisement process, through targeting the MPR Flooding 252 mechanism, or by causing incorrect link state information to be 253 included in TCs, causing routers to have incomplete, inaccurate or 254 inconsistent topology maps. In a different class of attacks, a 255 compromised OLSRv2 router injects control traffic, designed so as to 256 cause an in-router resource exhaustion, e.g., by causing the 257 algorithms calculating routing tables or MPR sets to be invoked 258 continuously, preventing the internal state of a router from 259 converging. 261 2. Terminology 263 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 264 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 265 "OPTIONAL" in this document are to be interpreted as described in 266 [RFC2119]. 268 This document uses the terminology and notation defined in [RFC5444], 269 [RFC6130] and [RFC7181]. Additionally, it defines the following 270 terminology: 272 Compromised OLSRv2 router: - An attacker that is present in the 273 network and generates syntactically correct OLSRv2 control 274 messages. Control messages emitted by a compromised OLSRv2 router 275 may contain additional information, or omit information, as 276 compared to a control message generated by a non-compromised 277 OLSRv2 router located in the same topological position in the 278 network. 280 Legitimate OLSRv2 router: - An OLSRv2 router that is not a 281 compromised OLSRv2 router. 283 3. Topology Map Acquisition 285 Topology Map Acquisition relates to the ability for any given router 286 in the network to acquire a representation of the network 287 connectivity. A router, unable to acquire a topology map, is 288 incapable of calculating routing paths and participating in 289 forwarding data. Topology map acquisition can be hindered by (i) TCs 290 to not being delivered to (all) routers in the network, such as what 291 happens in case of Flooding Disruption, or (ii) in case of "jamming" 292 of the communication channel. 294 The jamming and flooding disruption due to identity spoofing and link 295 spoofing have been discussed in [RFC7186]. 297 3.1. Attack on Jittering 299 OLSRv2 incorporates a jittering: a random, but bounded, delay on 300 outgoing control traffic [RFC5148]. This may be necessary when link 301 layers (such as 802.11 [IEEE802.11]) are used that do not guarantee 302 collision-free delivery of frames, and where jitter can reduce the 303 probability of collisions of frames on lower layers. 305 In OLSRv2, TC forwarding is jittered by a value between 0 and 306 MAX_JITTER. In order to reduce the number of transmissions, when a 307 control message is due for transmission, OLSRv2 piggybags all queued 308 messages into a single transmission. Thus, if a compromised OLSRv2 309 router sends many TCs within a very short time interval, the jitter 310 time of the attacked router tends to 0. This renders jittering 311 ineffective and can lead to collisions on the link layer. 313 In addition to causing more collisions, forwarding a TC with little 314 or no jittering can make sure that the TC message forwarded by a 315 compromised router arrives before the message forwarded by legitimate 316 routers. The compromised router can thus inject malicious content in 317 the TC, and the legitimate message will be discarded as duplicate 318 message. This preemptive action is important for some of the attacks 319 introduced in the following sections. 321 3.2. Hop-count and Hop-limit Attacks 323 The hop-count and hop-limit fields are the only parts of a TC that 324 are modified when forwarding. A compromised OLSRv2 router can modify 325 either of these when forwarding TCs. 327 3.2.1. Modifying the Hop Limit 329 A compromised OLSRv2 router can decrease the hop limit when 330 forwarding a TC. This will reduce the scope of forwarding the 331 message, and may lead to some routers in the network not receiving 332 that TC. Note that this is not necessarily the same as not relaying 333 the message (i.e., setting the hop limit to 0), as illustrated in 334 Figure 1. 336 .---. 337 | X | 338 --'---' __ 339 / \ 340 / \ 341 .---. .---. 342 TC -----> | A | | C | 343 '---' '---' 344 \ .---. / 345 \-- | B |__/ 346 '---' 348 Figure 1: Hop Limit Attack. 350 A TC arrives at and is forwarded by router A, such that it is 351 received by both B and the malicious X. X can forward the TC without 352 any delay (including without jitter) such that its transmissions 353 arrives before that of B at C. Before forwarding, it significantly 354 reduces the hop limit of the message. Router C receives the TC, 355 processes (and forwards) it, and marks it as already received - 356 causing it to discard further copies received from B. Thus, if the TC 357 is forwarded by C, it has a very low hop limit and will not reach the 358 whole network. 360 3.2.2. Modifying the Hop Count 362 A compromised OLSRv2 router can modify the hop count when forwarding 363 a TC. This may have two consequences: (i) if the hop count is set to 364 the maximum value, then the TC will be forwarded no further by, or 365 (ii) artificially manipulating the hop count may affect the validity 366 time as calculated by recipients, when using distance-dependent 367 validity times as defined in [RFC5497] (e.g., as part of a fish-eye 368 extension to OLSR2 [OLSR-FSR]). 370 v_time(1hop)=2s v_time(2hops)=4s v_time(3hops)=6s 371 .---. .---. .---. .---. 372 | A |-------> | B | -------> | X |---------->| C | 373 `---' `---' `---' `---' 375 Figure 2: Different validity times based on the distance in hops. 377 In Figure 2, router A sends a TC with a validity time of two seconds 378 for neighbors that are one hop away, four seconds for routers in a 379 two-hop distance and six seconds in a three-hop distance. If X is a 380 compromised OLSRv2 router and modifies the hop count (say, by 381 decreasing it to 0), then C will calculate the validity time of 382 received information to two seconds - after which it expires unless 383 refreshed. If TCs from A are sent less frequently than that up to 3 384 hops, this causes links advertised in such TCs to be only 385 intermittently available to C. 387 4. Effective Topology 389 Link-state protocols assume that each router can acquire an accurate 390 topology map, reflecting the effective network topology. This 391 implies that the routing protocol, through its message exchange, 392 identifies a path from a source to a destination, and this path is 393 valid for forwarding data traffic. If an attacker disturbs the 394 correct protocol behavior, the perceived topology map of a router can 395 permanently differ from the effective topology. 397 Considering the example in Figure 3(a), which illustrates the 398 topology map as acquired by router S. This topology map indicates 399 that the routing protocol has identified that for S, a path exists to 400 D via B, which it therefore assumes can be used for transmitting 401 data. If, effectively, B does not forward data traffic from S, then 402 the topology map in S does not accurately reflect the effective 403 network topology. Rather, the effective network topology from the 404 point of view of S would be as indicated in Figure 3(b): D is not 405 part of the network reachable from router S. 407 .---. .---. .---. .---. .---. 408 | S |----| B |----| D | | S |----| B | 409 `---' `---' `---' `---' `---' 411 (a) (b) 413 Figure 3: Incorrect Data Traffic Forwarding. 415 Some of the attacks related to NHDP, such as message timing attack, 416 indirect channel overloading have been discussed in [RFC7186]. Other 417 threats specific to OLSRv2 are further detailed in this section. 419 4.1. Incorrect Forwarding 421 OLSRv2 routers exchange information using link-local transmissions 422 (link-local multicast or limited broadcast) for their control 423 messages, with the routing process in each router retransmitting 424 received messages destined for network-wide diffusion. Thus, if the 425 operating system in a router is not configured to enable forwarding, 426 this will not affect the operating of the routing protocol, or the 427 topology map acquired by the routing protocol. It will, however, 428 cause a discrepancy between the effective topology and the topology 429 map, as indicated in Figure 3(a) and Figure 3(b). 431 This situation is not hypothetical. A common error seen when 432 deploying OLSRv2-based networks using Linux-based computers as router 433 is to neglect enabling IP forwarding, which effectively becomes an 434 accidental attack of this type. 436 4.2. Wormholes 438 A wormhole, depicted in the example in Figure 4, may be established 439 between two collaborating devices, connected by an out-of-band 440 channel. These devices send traffic through the "tunnel" to their 441 alter-ego, which "replays" the traffic. Thus, routers D and S appear 442 as if direct neighbors and reachable from each other in 1 hop through 443 the tunnel, with the path through the MANET being 100 hops long. 445 .---. .---. 446 | S |---- ....100-hop long path ... ---| D | 447 `---. / `---' 448 \ / 449 \ / 450 \X=============================X 452 1-hop path via wormhole 454 Figure 4: Wormholing between two collaborating devices not 455 participating in the routing protocol. 457 The consequences of such a wormhole in the network depends on the 458 detailed behavior of the wormhole. If the wormhole relays only 459 control traffic, but not data traffic, the same considerations as in 460 Section 4.1 applies. If, however, the wormhole relays all traffic, 461 control and data alike, it is connectivity-wise identical to a usable 462 link - and the routing protocol will correctly generate a topology 463 map reflecting the effective network topology. The efficiency of the 464 topology so obtained depends on (i) the wormhole characteristics, 465 (ii) how the wormhole presents itself, and (iii) how paths are 466 calculated. 468 Assuming that paths are calculated with unit-cost for all links, 469 including the "link" presented by the wormhole: if the real 470 characteristics of the wormhole are as-if it was a path of more than 471 100 hops (e.g., with respect to delay, bandwidth, etc.), then the 472 presence of the wormhole results in a degradation in performance as 473 compared to using the non-wormhole path. Conversely, if the "link" 474 presented by the wormhole has better characteristics, the wormhole 475 results in improved performance. 477 If paths are calculated using non-unit-costs for all links, and if 478 the cost of the "link" presented by the wormhole correctly represents 479 the actual cost (e.g., if the cost is established through 480 measurements across the wormhole), then the wormhole may in the worst 481 case cause no degradation in performance, in the best case improve 482 performance by offering a better path. If the cost of the "link" 483 presented by the wormhole is misrepresented, then the same 484 considerations as for unit-cost links apply. 486 An additional consideration with regards to wormholes is, that such 487 may present topologically attractive paths for the network - however 488 it may be undesirable to have data traffic transit such a path: an 489 attacker could, by virtue of introducing a wormhole, acquire the 490 ability to record and inspect transiting data traffic. 492 4.3. Sequence Number Attacks 494 OLSRv2 uses two different sequence numbers in TCs, to (i) avoid 495 processing and forwarding the same message more than once (Message 496 Sequence Number), and (ii) to ensure that old information, arriving 497 late due to, e.g., long paths or other delays, is not allowed to 498 overwrite fresher information (Advertised Neighbor Sequence Number - 499 ANSN). 501 4.3.1. Message Sequence Number 503 An attack may consist of a compromised OLSRv2 router spoofing the 504 identity of another router in the network, and transmitting a large 505 number of TCs, each with different Message Sequence Numbers. 506 Subsequent TCs with the same sequence numbers, originating from the 507 router whose identity was spoofed, would hence be ignored, until 508 eventually information concerning these "spoofed" TCs expires. 510 4.3.2. Advertised Neighbor Sequence Number (ANSN) 512 An attack may consist of a compromised OLSRv2 router spoofing the 513 identity of another router in the network, and transmitting a single 514 TC, with an ANSN significantly larger than that which was last used 515 by the legitimate router. Routers will retain this larger ANSN as 516 "the most fresh information" and discard subsequent TCs with lower 517 sequence numbers as being "old". 519 4.4. Indirect Jamming 521 Indirect Jamming is an attack in which a compromised OLSRv2 router 522 is, by its actions, causing legitimate routers to generate inordinate 523 amounts of control traffic, thereby increasing both channel 524 occupation and the overhead incurred in each router for processing 525 this control traffic. This control traffic will be originated from 526 legitimate routers, thus to the wider network, the malicious device 527 may remain undetected. 529 The general mechanism whereby a malicious router can cause indirect 530 jamming is for it to participate in the protocol by generating 531 plausible control traffic, and to tune this control traffic to in 532 turn trigger receiving routers to generate additional traffic. For 533 OLSRv2, such an indirect attack can be directed at, respectively, the 534 Neighborhood Discovery mechanism and the Link State Advertisement 535 mechanism. 537 The most efficient Indirect Jamming attack in OLSRv2 is to target 538 control traffic, destined for network-wide diffusion. This is 539 illustrated in Figure 5. 541 The malicious router X selects router A as MPR at time t0 in a HELLO. 542 This causes X to appear as MPR selector for A and, consequently, A 543 sets X to be advertised in its "Neighbor Set" and increments the 544 associated "Advertised Neighbor Sequence Number" (ANSN). A must, 545 then, advertise the link between itself and X in subsequent outgoing 546 TCs (t1), also including the ANSN in such TCs. Upon X having 547 received this TC, it declares the link between itself and A as no 548 longer valid (t2) in a HELLO (indicating the link to a as LOST). 549 Since only symmetric links are advertised by OLSRv2 routers, A will 550 upon receipt hereof remove X from the set of advertised neighbors and 551 increment the ANSN. A will then in subsequent TCs advertise the 552 remaining set of advertised neighbors (i.e., with X removed) and the 553 corresponding ANSN (t3). Upon X having received this information in 554 another TC from A, it may repeat this cycle, alternating advertising 555 the link A-X as "LOST" and as "MPR". 557 broadcast TC ANS={} TC:() 558 (X-a) ANSN ANSN++ ANSN 559 .---. .---. .---. .---. 560 | A | | A | | A | | A | 561 '---' '---' '---' '---' 562 ^ | ^ | 563 | | | | 564 | select | |indicate | 565 | as MPR | |as LOST | 566 .---. .---. .---. .---. 567 | X | | X | | X | | X | 568 '---' '---' '---' '---' 570 t0 t1 t2 t3 572 Figure 5: Indirect Jamming in Link State Advertisement: the malicious 573 X flips between link status MPR and LOST. 575 Routers receiving a TC will parse and process this message, 576 specifically updating their topology map as a consequence of 577 successful receipt. If the ANSN between two successive TCs from the 578 same router has incremented, then the topology has changed and 579 routing tables are to be recalculated. This is a potentially 580 computationally costly operation [DSP-OLSRv2]. 582 A compromised OLSRv2 router may chose to conduct this attack against 583 all its neighbors, thus attaining maximum disruptive impact on the 584 network with relatively little overhead of its own: other than 585 participating in the Neighborhood Discovery procedure, the 586 compromised OLSRv2 router will monitor TCs generated by its neighbors 587 and alternate the advertised status for each such neighbor, between 588 "MPR" and "LOST". The compromised OLSRv2 router will indicate its 589 willingness to be zero (thus, avoid being selected as MPR) and may 590 ignore all other protocol operations, while still remaining effective 591 as an attacker. 593 The basic operation of OLSRv2 employs periodic message emissions, and 594 by this attack it can be ensured that each such periodic message will 595 entail routing table recalculation in all routers in the network. 597 If the routers in the network have "triggered TCs" enabled, this 598 attack may also cause an increased TC frequency. Triggered TCs are 599 intended to allow a (stable) network to have relatively low TC 600 emission frequencies, yet still allow link breakage or link emergence 601 to be advertised through the network rapidly. A minimum message 602 interval (typically much smaller than the regular periodic message 603 interval) is imposed, to rate-limit worst-case message emissions. 604 This attack can cause the TC interval to, permanently, become equal 605 to the minimum message interval. [RFC7181] proposes as default that 606 the minimum TC interval be 0.25 x TC interval. 608 Indirect Jamming by a compromised OLSRv2 router can thus have two 609 effects: it may cause increased frequency of TC generation and 610 transmission, and it will cause additional routing table 611 recalculation in all routers in the network. 613 5. Inconsistent Topology 615 Inconsistent topology maps can occur by a compromised OLSRv2 router 616 employing either of identity spoofing or link spoofing for conducting 617 an attack against an OLSRv2 network. The threats related to NHDP, 618 such as identity spoofing in NHDP, link spoofing in NHDP and creating 619 loops have been illustrated in [RFC7186]. This section mainly 620 addresses the vulnerabilities in [RFC7181]. 622 5.1. Identity Spoofing 624 Identity spoofing can be employed by a compromised OLSRv2 router via 625 the Neighborhood Discovery process and via the Link State 626 Advertisement process. Either of them causes inconsistent topology 627 maps in routers in the network. The inconsistent topology maps due 628 to neighborhood discovery has been discussed in [RFC7186]. For 629 OLSRv2, the attack on link state advertisements can also cause 630 inconsistent topology maps. 632 An inconsistent topology map may occur when the compromised OLSRv2 633 router takes part in the Link State Advertisement (LSA) procedure, by 634 selecting a neighbor as MPR, which in turn advertises the spoofed 635 identities of the compromised OLSRv2 router. This attack will alter 636 the topology maps 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(b). 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 Link State Advertisement 669 procedure has a higher impact than the attack on the neighborhood 670 discovery procedure, since it alters the topology maps of all routers 671 in the network, and not only in the 2-hop neighborhood. However, the 672 attack is easier to detect by other routers in the network. Since 673 the compromised OLSRv2 router is advertised in the whole network, 674 routers whose identities are spoofed by the compromised OLSRv2 router 675 can detect the attack. For example, when a receives a TC from F 676 advertising the link F-A, it can deduce that some entity is injecting 677 incorrect Link State information as it does not have F as one of its 678 direct neighbors. 680 (X spoofs A) 682 A < ---- B < ---- C E ----> F ----> X 684 (a) Routers B and C (b) Routers E and F 686 A < --- B < --- C < --- D ---> E ---> F ----> X 688 (X spoofs A) 690 Figure 7: Routing paths towards A, as calculated by the different 691 routers in the network in presence of a compromised OLSRv2 router X, 692 spoofing the address of A. 694 As the compromised OLSRv2 router X does not itself send the TCs, but 695 rather, by virtue of MPR selection, ensures that the addresses it 696 spoofs are advertised in TCs from its MPR selector F, the attack may 697 be difficult to counter: simply ignoring TCs that originate from F 698 may also suppress the link state information for other, legitimate, 699 MPR selectors of F. 701 Identity spoofing by a compromised OLSRv2 router, participating in 702 the Link State Advertisement process by selecting MPRs only, thus, 703 creates a situation wherein two or more routers have substantially 704 inconsistent topology maps: traffic for an identified destination is, 705 depending on where in the network it appears, delivered to different 706 routers. 708 5.2. Link Spoofing 710 Link Spoofing is a situation in which a router advertises non- 711 existing links to another router (possibly not present in the 712 network). Essentially, TCs and HELLOs both advertise links to direct 713 neighbor routers, with the difference being the scope of the 714 advertisement. Thus, link spoofing consists of a compromised OLSRv2 715 router, reporting that it has as as neighbors routers which are, 716 either, not present in the network, or which are effectively not 717 neighbors of the compromised OLSRv2 router. 719 It can be noted that a situation similar to Link Spoofing may occur 720 temporarily in an OLSR or OLSRv2 network without compromised OLSRv2 721 routers: if a was, but is no more, a neighbor of B, then A may still 722 be advertising a link to B for the duration of the time it takes for 723 the the Neighborhood Discovery process to determine this changed 724 neighborhood. 726 In the context of this document, Link Spoofing refers to a persistent 727 situation where a compromised OLSRv2 router intentionally advertises 728 links to other routers, for which it is not a direct neighbor. 730 5.2.1. Inconsistent Topology Maps due to Link State Advertisements 732 Figure 8 illustrates a network, in which the compromised OLSRv2 733 router X spoofs links to the existing router A by participating in 734 the Link State Advertisement process and including this non-existing 735 link in its advertisements. 737 A --- B --- C --- D --- E --- F --- G --- H --- X 739 (X spoofs the link to A) 741 Figure 8: Link Spoofing: The compromised OLSRv2 router X advertises a 742 spoofed link to A in its TCs, thus all routers will record both of 743 the links X-A and B-A. 745 As TCs are flooded through the network, all routers will receive and 746 record information describing a link X-A in this link state 747 information. If A has selected router B as MPR, A will likewise 748 flood this link state information through the network, thus all 749 routers will receive and record information describing a link B-A. 751 When calculating routing paths, B, C and D will calculate paths to A 752 via B, as illustrated in Figure 9(a); for these routers, the shortest 753 path to A is via B. F and G will calculate paths to A via X, as 754 illustrated in Figure 9(b); for these routers, the shortest path to A 755 is via X, and these are thus disconnected from the real router A. E 756 will have a choice: the path calculated to A via B is of the same 757 length as the path via X, as illustrated in Figure 9(b). 759 A < --- B < --- C < --- D F ---> G ---> X ---> A 761 (a) Routers B, C, and D (b) Routers F and G 763 A < --- B < --- C < --- D < --- E ---> F ---> G ---> X ---> A 765 (c) Router E 767 Figure 9: Routing paths towards router A, as calculated by the 768 different routers in the network in presence of a compromised OLSRv2 769 router X, spoofing a link to router A. 771 In general, the following observations can be made: 773 o The network will be separated in two, with those routers closer to 774 B than to X reaching A, whereas those routers closer to X than to 775 B unable to reach A. 777 o Routers beyond B, i.e., routers beyond one hop away from A will be 778 unable to detect this link spoofing. 780 The impact of this attack is similar to that presented in 781 Section 5.2.1, however, is easier to detect as the compromised OLSRv2 782 router is generating control traffic reaching the entire network. 784 6. Mitigation of Security Vulnerabilities for OLSRv2 786 As described in Section 1, [RFC7183] specifies a security mechanism 787 for OLSRv2 that is mandatory to implement. However, deployments may 788 choose to use different security mechanisms if more appropriate. 789 Therefore, it is important to understand both the inherent resilience 790 of OLSRv2 against security vulnerabilities when not using the 791 mechanisms specified in [RFC7183], as well as the protection that 792 [RFC7183] provides when used in a deployment. 794 6.1. Inherent OLSRv2 Resilience 796 OLSRv2 (without the mandatory-to-implement security mechanisms in 797 [RFC7183]) provides some inherent resilience against part of the 798 attacks described in this document. In particular, it provides the 799 following resilience: 801 o Sequence numbers: OLSRv2 employs message sequence numbers, 802 specific per router identity and message type. Routers keep an 803 "information freshness" number (ANSN), incremented each time the 804 content of a Link State Advertisement from a router changes. This 805 allows rejecting "old" information and duplicate messages, and 806 provides some protection against "message replay". This, however, 807 also presents an attack vector (Section 4.3). 809 o Ignoring uni-directional links: The Neighborhood Discovery process 810 detects and admits only bi-directional links for use in MPR 811 selection and Link State Advertisement. Jamming attacks may 812 affect only reception of control traffic, however OLSRv2 will 813 correctly recognize, and ignore, such a link as not bi- 814 directional. 816 o Message interval bounds: The frequency of control messages, with 817 minimum intervals imposed for HELLO and TCs. This may limit the 818 impact from an indirect jamming attack (Section 4.4). 820 o Additional reasons for rejecting control messages: The OLSRv2 821 specification includes a list of reasons, for which an incoming 822 control message should be rejected as malformed - and allows that 823 a protocol extension may recognize additional reasons for OLSRv2 824 to consider a message malformed. This allows - together with the 825 flexible message format [RFC5444] - addition of security 826 mechanisms, such as digital signatures, while remaining compliant 827 with the OLSRv2 standard specification. 829 6.2. Resilience by using RFC7183 with OLSRv2 831 [RFC7183] specifies mechanisms for integrity and replay protection 832 for NHDP and OLSRv2, using the generalized packet/message format 833 described in [RFC5444] and the TLV definitions in [RFC7182]. The 834 specification describes how to add an Integrity Check Value (ICV) in 835 a TLV to each control message, providing a digital signature of the 836 content of the message using HMAC/SHA-256. In addition, a timestamp 837 TLV is added to the message prior to creating the ICV, enabling 838 replay protection of messages. The document specifies how to sign 839 outgoing messages and how to verify incoming messages, as well as 840 under which circumstances a non-valid message is rejected. Because 841 of the HMAC/SHA-256 ICV, a shared key between all routers in the 842 MANET is assumed. A router without valid credentials is not able to 843 create an ICV that can be correctly verified by other routers in the 844 MANET; therefore, such an incorrectly signed message will be rejected 845 by other MANET routers, and the router cannot participate in the 846 OLSRv2 routing process (i.e., the malicious router will be ignored by 847 other, legitimate routers). [RFC7183] does not address the case 848 where a router with valid credentials has been compromised. Such a 849 compromised router will not be excluded from the routing process, and 850 other means of detecting such a router are necessary if required in a 851 deployment (in addition to using asymmetric keys, allowing to revoke 852 access to one particular router instead of revoking the shared key 853 used by all routers in the MANET). 855 In the following sections, each of the vulnerabilities described 856 earlier in this document will be evaluated in terms of whether OLSRv2 857 with the mechanisms in [RFC7183] provides sufficient protection 858 against the attack. It is implicitly assumed in each of the 859 following sections that [RFC7183] is used with OLSRv2. 861 6.2.1. Topology Map Acquisition 863 Attack on Jittering - As only OLSRv2 routers with valid credentials 864 can participate in the routing process, a malicious router cannot 865 reduce the jitter time of an attacked router to 0 by sending many 866 TC messages in a short time. The attacked router would reject all 867 the incoming messages as "invalid" and not forward them. The same 868 applies for the case where a malicious routers wants to assure 869 that by forcing a zero jitter interval, the message arrives before 870 the same message forwarded by legitimate routers. 872 Modifying the Hop Limit - As the hop limit is not protected by 873 [RFC7183] (since it is a mutual field, changing at every hop), 874 this attack is still feasible. 876 Modifying the Hop Count - Similarly to the hop limit, as the hop 877 count is not protected by [RFC7183] (since it is a mutual field, 878 changing at every hop), this attack is still feasible. 880 6.2.2. Effective Topology 882 Incorrect Forwarding - As only OLSRv2 routers with valid credentials 883 can participate in the routing process, a malicious router will 884 not be part of the topology of other legitimate OLSRv2 routers. 885 Therefore, no data traffic will be sent to the malicious router 886 for forwarding. 888 Wormholes - Since a wormhole consists of at least two devices 889 forwarding (unmodified) traffic, this attack is still feasible and 890 undetectable by the OLSRv2 routing process since the attack does 891 not involve the OLSRv2 protocol itself (but rather lower layers). 892 By using [RFC7183], it can at least be assured that the content of 893 the control messages is not modified while being forwarded via the 894 wormhole. Moreover, the timestamp TLV assures that the forwarding 895 can only be done in a short time window after the actual TC 896 message has been sent. 898 Message Sequence Number - As the message sequence number is included 899 in the ICV calculation, OLSRv2 is protected against this attack. 901 Advertised Neighbor Sequence Number (ANSN) - As the ANSN is included 902 in the ICV calculation, OLSRv2 is protected against this attack. 904 Indirect Jamming - Since the control messages of a malicious router 905 will be rejected by other legitimate OLSRv2 routers in the MANET, 906 this attack is mitigated. 908 6.2.3. Inconsistent Topology 910 Identity Spoofing - Since the control messages of a malicious router 911 will be rejected by other legitimate OLSRv2 routers in the MANET, 912 a router without valid credentials may spoof its identity (e.g., 913 IP source address or message originator address), but the messages 914 will be ignored by other routers. As [RFC7183] uses shared keys 915 amongst all MANET routers, a single compromised router may spoof 916 its identify and cause harm to the network stability. Removing 917 this one malicious router once detected implies rekeying all other 918 routers in the MANET. Asymmetric keys, in particular when using 919 identity based signatures, such as specified in [IBS] may further 920 allow to revoke single routers and to verify their identity based 921 on the ICV itself. 923 Link Spoofing - Similar to identity spoofing, a malicious router 924 without valid credential may spoof links, but its control messages 925 will be rejected by other routers, thereby mitigating the attack. 927 Inconsistent Topology Maps due to Link State Advertisements - The 928 same considerations as for link spoofing apply. 930 7. Security Considerations 932 This document does not specify a protocol or a procedure. The 933 document, however, reflects on security considerations for OLSRv2, 934 and its constituent parts, including NHDP. 936 8. IANA Considerations 938 This document has no actions for IANA. 940 9. References 942 9.1. Normative References 944 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 945 Requirement Levels", RFC 2119, BCP 14, March 1997. 947 [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, 948 "The Optimized Link State Routing Protocol Version 2", 949 RFC 7181, April 2014. 951 [RFC7186] Yi, J., Herberg, U., and T. Clausen, "Security Threats for 952 the Neighborhood Discovery Protocol (NHDP)", RFC 7186, 953 April 2014. 955 9.2. Informative References 957 [DSP-OLSRv2] 958 Herberg, U., "Performance Evaluation of using a Dynamic 959 Shortest Path Algorithm in OLSRv2, Proceedings of the 8th 960 Eighth Annual Conference on Communication Networks and 961 Services Research", 2010. 963 [FUNKFEUER] 964 "http://www.funkfeuer.at/". 966 [IBS] Dearlove, C., "Identity-Based Signatures for MANET Routing 967 Protocols", work in progress draft-ietf-manet-ibs-02, 968 July 2014. 970 [IEEE802.11] 971 "IEEE 802.11: Wireless LAN Medium Access Control (MAC) and 972 Physical Layer (PHY) Spec.", 2007. 974 [MGMT-SNAP] 975 Herberg, U. and T. Clausen, "Snapshot of OLSRv2-Routed 976 MANET Management", work in 977 progress draft-ietf-manet-olsrv2-management-snapshot, 978 July 2014. 980 [MPR-FLOODING] 981 Qayyum, A., Viennot, L., and A. Laouiti, "Multipoint 982 relaying: An efficient technique for flooding in mobile 983 wireless networks.", 2001. 985 [OLSR-FSR] 986 Adjih, C., Baccelli, E., Clausen, T., Jacquet, P., and G. 987 Rodolakis, "Fish eye OLSR scaling properties, IEEE Journal 988 of Communication and Networks (JCN), Special Issue on 989 Mobile Ad Hoc Wireless Networks", 2004. 991 [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State 992 Routing Protocol", RFC 3626, October 2003. 994 [RFC5068] Hutzler, C., Crocker, D., Resnick, P., Allman, E., and T. 995 Finch, "Email Submission Operations: Access and 996 Accountability Requirements", RFC 5068, BCP 134, 997 October 2007. 999 [RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter 1000 Considerations in Mobile Ad Hoc Networks (MANETs)", 1001 RFC 5148, February 2008. 1003 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 1004 "Generalized MANET Packet/Message Format", RFC 5444, 1005 February 2009. 1007 [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value 1008 Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, 1009 March 2009. 1011 [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc 1012 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 1013 RFC 6130, April 2011. 1015 [RFC6779] Herberg, U., Cole, R., and I. Chakeres, "Definition of 1016 Managed Objects for the Neighborhood Discovery Protocol", 1017 RFC 6779, May 2012. 1019 [RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity 1020 Check Value and Timestamp TLV Definitions for Mobile Ad 1021 Hoc Networks (MANETs)", RFC 7182, April 2014. 1023 [RFC7183] Herberg, U., Dearlove, C., and T. Clausen, "Integrity 1024 Protection for the Neighborhood Discovery Protocol (NHDP) 1025 and Optimized Link State Routing Protocol Version 2 1026 (OLSRv2)", RFC 7183, April 2014. 1028 [RFC7184] Herberg, U., Cole, R., and T. Clausen, "Definition of 1029 Managed Objects for the Optimized Link State Routing 1030 Protocol Version 2", RFC 7184, April 2014. 1032 [RFC7187] Dearlove, C. and T. Clausen, "Routing Multipoint Relay 1033 Optimization for the Optimized Link State Routing Protocol 1034 Version 2 (OLSRv2)", RFC 7187, April 2014. 1036 [RFC7188] Dearlove, C. and T. Clausen, "Optimized Link State Routing 1037 Protocol Version 2 (OLSRv2) and MANET Neighborhood 1038 Discovery Protocol (NHDP) Extension TLVs", RFC 7188, 1039 April 2014. 1041 Authors' Addresses 1043 Thomas Clausen 1045 Phone: +33-6-6058-9349 1046 Email: T.Clausen@computer.org 1047 URI: http://www.thomasclausen.org 1049 Ulrich Herberg 1050 Fujitsu Laboratories of America 1051 1240 E Arques Ave 1052 Sunnyvale CA 94086, 1053 US 1055 Phone: 1056 Email: ulrich@herberg.name 1057 URI: http://www.herberg.name 1058 Jiazi Yi 1059 LIX, Ecole Polytechnique 1060 91128 Palaiseau Cedex, 1061 France 1063 Phone: +33 1 77 57 80 85 1064 Email: jiazi@jiaziyi.com 1065 URI: http://www.jiaziyi.com/