idnits 2.17.1 draft-ietf-manet-nhdp-sec-threats-06.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 484: '...ty is a mechanism whereby a router MAY...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 17, 2013) is 3959 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-ietf-manet-nhdp-olsrv2-sec-02 -- Obsolete informational reference (is this intentional?): RFC 6779 (Obsoleted by RFC 7939) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile Ad hoc Networking (MANET) J. Yi 3 Internet-Draft LIX, Ecole Polytechnique 4 Intended status: Informational U. Herberg 5 Expires: December 19, 2013 Fujitsu Laboratories of America 6 T. Clausen 7 LIX, Ecole Polytechnique 8 June 17, 2013 10 Security Threats for NHDP 11 draft-ietf-manet-nhdp-sec-threats-06 13 Abstract 15 This document analyzes common security threats of the Neighborhood 16 Discovery Protocol (NHDP), and describes their potential impacts on 17 MANET routing protocols using NHDP. This document is not intended to 18 propose solutions to the threats described. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on December 19, 2013. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. NHDP Threat Overview . . . . . . . . . . . . . . . . . . . . . 4 57 4. Detailed Threat Description . . . . . . . . . . . . . . . . . 5 58 4.1. Jamming . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4.2. Denial of Service Attack . . . . . . . . . . . . . . . . . 5 60 4.3. Eavesdropping and Traffic Analysis . . . . . . . . . . . . 6 61 4.4. Incorrect HELLO Message Generation . . . . . . . . . . . . 7 62 4.4.1. Identity Spoofing . . . . . . . . . . . . . . . . . . 7 63 4.4.2. Link Spoofing . . . . . . . . . . . . . . . . . . . . 8 64 4.5. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 9 65 4.6. Message Timing Attacks . . . . . . . . . . . . . . . . . . 9 66 4.6.1. Interval Time Attack . . . . . . . . . . . . . . . . . 9 67 4.6.2. Validity Time Attack . . . . . . . . . . . . . . . . . 10 68 4.7. Indirect Channel Overloading . . . . . . . . . . . . . . . 10 69 4.8. Attack on Link Quality Update . . . . . . . . . . . . . . 11 70 5. Impact of inconsistent Information Bases on Protocols 71 using NHDP . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 5.1. MPR Calculation . . . . . . . . . . . . . . . . . . . . . 12 73 5.1.1. Flooding Disruption due to Identity Spoofing . . . . . 12 74 5.1.2. Flooding Disruption due to Link Spoofing . . . . . . . 13 75 5.1.3. Broadcast Storm . . . . . . . . . . . . . . . . . . . 14 76 5.2. Routing Loops . . . . . . . . . . . . . . . . . . . . . . 15 77 5.3. Invalid or Non-Existing Paths to Destinations . . . . . . 15 78 5.4. Data Sinkhole . . . . . . . . . . . . . . . . . . . . . . 16 79 6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 16 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 82 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 84 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 85 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 88 1. Introduction 90 The Neighborhood Discovery Protocol (NHDP) [RFC6130] allows routers 91 to acquire topological information up to two hops away from 92 themselves, by way of periodic HELLO message exchanges. The 93 information acquired by NHDP is used by other protocols, such as 94 OLSRv2 [I-D.ietf-manet-olsrv2] and SMF [RFC6621]. The topology 95 information, acquired by way of NHDP, serves these routing protocols 96 by detecting and maintaining local 1-hop and 2-hop neighborhood 97 information. 99 As NHDP is typically used in wireless environments, it is potentially 100 exposed to different kinds of security threats, some of which are of 101 particular significance as compared to wired networks. As radio 102 signals can be received as well as transmitted by any compatible 103 wireless device within radio range, there is commonly no physical 104 protection as otherwise known for wired networks. NHDP does not 105 define any explicit security measures for protecting the integrity of 106 the information it acquires, however suggests that the integrity 107 protection be addressed in a fashion appropriate to the deployment of 108 the network. 110 This document is based on the assumption that no additional security 111 mechanism such as IPsec is used in the IP layer, as not all MANET 112 deployments may be suitable to deploy common IP protection mechanisms 113 (e.g., because of limited resources of MANET routers to support the 114 IPsec stack). The document analyzes possible attacks on and mis- 115 configurations of NHDP and outlines the consequences of such attacks/ 116 mis-configurations to the state maintained by NHDP in each router 117 (and, thus, made available to protocols using this state). 119 This document is not intended to propose solutions to the threats 120 described. [I-D.ietf-manet-nhdp-olsrv2-sec] provides further 121 information on how to enable integrity protection to NHDP, which can 122 help mitigating the threats described related to identity spoofing. 124 It should be noted that many NHDP implementations are configurable 125 and so an attack on the configuration system (such as [RFC6779]) can 126 be used to adversely affect the operation of an NHDP implementation. 128 The NHDP MIB module [RFC6779] might help monitoring some of the 129 security attacks mentioned in this document. Note that, 130 [I-D.nguyen-manet-management] contains specific guidelines on MANET 131 network management, taking into account the specific nature of 132 MANETs. 134 2. Terminology 136 This document uses the terminology and notation defined in [RFC5444], 137 NHDP [RFC6130] and [RFC4949]. 139 Additionally, this document introduces the following terminology: 141 NHDP Router: A MANET router, running NHDP as specified in [RFC6130]. 143 Attacker: A device, present in the network and which intentionally 144 seeks to compromise the information bases in NHDP routers. 146 Compromised NHDP Router: An attacker, present in the network and 147 which generates syntactically correct NHDP control messages. 148 Control messages emitted by a Compromised NHDP router may contain 149 additional information, or omit information, as compared to a 150 control message generated by a non-compromized NHDP router located 151 in the same topological position in the network. 153 Legitimate NHDP Router: An NHDP router, which is not a Compromised 154 NHDP Router. 156 3. NHDP Threat Overview 158 NHDP defines a HELLO messages exchange, enabling each NHDP Router to 159 acquire topological information describing its 1-hop and 2-hop 160 neighbors, and specifies information bases for recording this 161 information. 163 An NHDP Router periodically transmits HELLO messages using a link- 164 local multicast on each of its interfaces with a hop-limit of 1 165 (i.e., HELLOs are never forwarded). In these HELLO messages, an NHDP 166 Router announces the IP addresses as heard, symmetric or lost 167 neighbor interface addresses. 169 An Attacker has several ways of harming this neighbor discovery 170 process: It can announce "wrong" information about its identity, 171 postulate non-existent links, and replay HELLO messages. These 172 attacks are presented in detail in Section 4. 174 The different ways of attacking an NHDP deployment may eventually 175 lead to inconsistent information bases, not accurately reflecting the 176 correct topology of the MANET. The consequence hereof is that 177 protocols using NHDP will base their operation on incorrect 178 information, causing routing protocols to not be able to calculate 179 correct (or any) paths, degrade the performance of flooding 180 operations based on reduced relay sets, etc. These consequences to 181 protocols using NHDP are described in detail in Section 5. 183 4. Detailed Threat Description 185 For each threat, described in the below, a description of the 186 mechanism of the corresponding attack is given, followed by a 187 description of how the attack affects NHDP. The impacts from each 188 attack on protocols using NHDP are given in Section 5. 190 For simplicity in the description, examples given assume that NHDP 191 Routers have a single interface with a single IP address configured. 192 All the attacks apply, however, for NHDP Routers with multiple 193 interfaces and multiple addresses as well. 195 4.1. Jamming 197 One vulnerability, common for all protocols operating a wireless ad 198 hoc network, is that of "jamming", i.e., that a device generates 199 massive amounts of interfering radio transmissions, which will 200 prevent legitimate traffic (e.g.,control traffic as well as data 201 traffic) on part of a network. Jamming is a form of Interference and 202 Overload with threat consequences of Disruption [RFC4593]. 204 Depending on lower layers, this may not affect transmissions: HELLO 205 messages from an NHDP Router with "jammed" interfaces may be received 206 by other NHDP Routers. As NHDP identifies whether a link to a 207 neighbor is uni-directional or bi-directional, a routing protocol 208 that uses NHDP for neighborhood discovery may ignore a link from a 209 jammed NHDP Router to a non-jammed NHDP Router. The jammed router (a 210 router with jammed carrier) would appear simply as "disconnected" for 211 the un-jammed part of the network - which is able to maintain 212 accurate topology maps. 214 If, due to a jamming attack, a considerable amount of HELLO messages 215 are lost or corrupted due to collisions, neighbor NHDP Routers are 216 not able to establish links between themselves any more. Thus, NHDP 217 will present empty information bases to the protocols using it. 219 4.2. Denial of Service Attack 221 A Denial of Service (DoS) attack can be a result of misconfiguration 222 of Legitimate NHDP Routers (e.g., very short HELLO transmission 223 interval) or malicious behavior of Compromised NHDP Routers 224 [ACCT2012], so called byzantine routers [RFC4593]. DoS is a form of 225 Interference and Overload with threat consequences of Disruption 226 [RFC4593]. 228 By transmitting a huge amount of HELLO messages in a short period of 229 time, NHDP Routers can increase channel occupation as introduced in 230 Section 4.1. Furthermore, a Compromised NHDP Router can spoof a 231 large amount of different IP addresses, and send HELLOs to its 232 neighbors to fill their Link/Neighbor Sets. This may result in 233 memory overflow, and makes the processing of legitimate HELLO 234 messages impossible. A Compromised NHDP Router can also use link 235 spoofing in its HELLO messages, generating huge 2-hop Sets in 236 adjacent NHDP Routers and therefore potentially a memory overflow. 237 Moreover, protocols such as SMF and OLSRv2, using the 2-hop 238 information for MPR calculation, may exhaust the available 239 computational resources of the router if the Neighbor Set and 2-hop 240 Sets have too many entries. 242 By exhausting the memory, CPU, or (and) channel resources of a router 243 in a DoS attack or a misconfiguration, NHDP Routers may not be able 244 to accomplish their specified tasks of exchanging 1-hop and 2-hop 245 neighborhood information, and thereby disturbing the operation of 246 routing protocols using NHDP. 248 In some MANETs, the routers are powered by battery. Another 249 consequence of DoS attack in such networks is that the power will be 250 drained quickly by unnecessary message processing, transmission and 251 receiving. 253 4.3. Eavesdropping and Traffic Analysis 255 Eavesdropping, sometimes referred as sniffing, is a common and easy 256 passive attack in a wireless environment. Once a packet is 257 transmitted, any adjacent NHDP Router can potentially obtain a copy, 258 for immediate or later processing. Neither the source nor the 259 intended destination can detect this. A malicious NHDP Router can 260 eavesdrop on the NHDP message exchange and thus learn the local 261 topology. It may also eavesdrop on data traffic to learn source and 262 destination addresses of data packets, or other header information, 263 as well as the packet payload. 265 Eavesdropping does not pose a direct threat to the network nor to 266 NHDP, in as much as that it does not alter the information recorded 267 by NHDP in its information bases and presented to other protocols 268 using it, but it can provide network information required for 269 enabling other attacks, such as the identity of communicating NHDP 270 Routers, detection of link characteristic, and NHDP Router 271 configuration. The compromised NHDP Routers may use the obtained 272 information to launch subsequent attacks, and they may also share 273 NHDP routing information with other NHDP or non-NHDP entities. 274 [RFC4593] would categorize the threat consequence as Disclosure. 276 Traffic analysis normally comes along with eavesdropping, which is 277 the process of intercepting messages in order to deduce information 278 from communication patterns. It can be performed even HELLO messages 279 are encrypted (encryption is not a part of NHDP), for example: 281 o Triggered HELLO messages: an attacker could figure out that 282 messages are triggered and determine that there was a change of 283 symmetric neighbors of an NHDP Router sending the HELLO (as well 284 get the frequency). 286 o Message size: the message grows exactly by x bytes per neighbor. 287 Depending on which cipher is used for the encryption, some 288 information about the size could be inferred and thus the number 289 of neighbors guessed. 291 [RFC4593] would categorize the threat consequence as Disclosure. 293 4.4. Incorrect HELLO Message Generation 295 An NHDP Router performs two distinct tasks: it periodically generates 296 HELLO messages, and it processes incoming HELLO messages from 297 neighbor NHDP Routers. This section describes security attacks 298 involving the HELLO generation. 300 4.4.1. Identity Spoofing 302 Identity spoofing implies that a Compromised NHDP Router sends HELLO 303 messages, pretending to have the identity of another NHDP Router, or 304 even a router that does not exist in the networks. A Compromised 305 NHDP Router can accomplish this by using another IP address in an 306 address block of a HELLO message, and associating this address with a 307 LOCAL_IF Address Block TLV [IJNSIA2010]. 309 An NHDP Router receiving the HELLO message from a neighbor, will 310 assume that it originated from the NHDP Router with the spoofed 311 interface address. As a consequence, it will add a Link Tuple to 312 that neighbor with the spoofed address, and include it in its next 313 HELLO messages as a heard neighbor (and possibly as symmetric 314 neighbor after another HELLO exchange). 316 Identity spoofing is particular harmful if a Compromised NHDP Router 317 spoofs the identity of another NHDP Router that exists in the same 318 routing domain. With respect to NHDP, such a duplicated, spoofed 319 address can lead to an inconsistent state up to two hops from an NHDP 320 Router. [RFC4593] would categorize the threat consequence as 321 Disclosure and Deception. 323 Figure 1 depicts a simple example. In that example, NHDP Router A is 324 in radio range of C, but not of the Compromised NHDP Router X. If X 325 spoofs the address of A, that can lead to conflicts for routing 326 protocol that uses NHDP, and therefore for wrong path calculations as 327 well as incorrect data traffic forwarding. 329 .---. .---. .---. 330 | A |----| C |----| X | 331 '---' '---' '---' 333 Figure 1 335 Figure 2 depicts another example. In this example, A is two hops 336 away from NHDP Router C, reachable through NHDP Router B. If the 337 Compromised NHDP Router X spoofs the address of A, D will take A as 338 its one hop neighbor, and C may think that A is indeed reachable 339 through NHDP Router D. 341 .---. .---. .---. .---. .---. 342 | A |----| B |----| C |----| D |----| X | 343 '---' '---' '---' '---' '---' 345 Figure 2 347 4.4.2. Link Spoofing 349 Similar to identity spoofing, link spoofing implies that a 350 Compromised NHDP Router sends HELLO messages, signaling an incorrect 351 set of neighbors, sometimes referred to as Falsification [RFC4593]. 352 This may take either of two forms: 354 o A Compromised NHDP Router can postulate addresses of non-present 355 neighbor NHDP Routers in an address block of a HELLO, associated 356 with LINK_STATUS TLVs. 358 o A Compromised NHDP Router can "ignore" otherwise existing 359 neighbors by not advertising them in its HELLO messages. 361 The effect of link spoofing with respect to NHDP are twofold, 362 depending on the two cases mentioned above: If the Compromised NHDP 363 Router ignores existing neighbors in its advertisements, links will 364 be missing in the information bases maintained by other routers, and 365 there may not be any connectivity to or from these NHDP Routers to 366 others NHDP Routers in the MANET. If, on the other hand, the 367 Compromised NHDP Router advertises non-existing links, this will lead 368 to inclusion of topological information in the information base, 369 describing non-existing links in the network (which, then, may be 370 used by other protocols using NHDP in place of other, existing, 371 links). [RFC4593] would categorize the threat consequence as 372 Usurpation, Deception and Disruption. 374 4.5. Replay Attack 376 A replay attack implies that control traffic from one region of the 377 network is recorded and replayed in a different region at (almost) 378 the same time, or in the same region at a different time. This may, 379 for example, happen when two Compromised NHDP Routers collaborate on 380 an attack, one recording traffic in its proximity and tunneling it to 381 the other Compromised NHDP Router, which replays the traffic. In a 382 protocol where links are discovered by testing reception, this will 383 result in extraneous link creation (basically, a "virtual" link 384 between the two Compromised NHDP Routers will appear in the 385 information bases of neighboring NHDP Routers). [RFC4593] would 386 categorize this as a Falsification and Interference threat with a 387 threat consequence of Usurpation, Deception, and Disruption. 389 While this situation may result from an attack, it may also be 390 intentional: if data-traffic also is relayed over the "virtual" link, 391 the link being detected is indeed valid for use. This is, for 392 instance, used in wireless repeaters. If data traffic is not carried 393 over the virtual link, an imaginary, useless, link between the two 394 Compromised NHDP Routers, has been advertised, and is being recorded 395 in the information bases of their neighboring NHDP Routers. 397 Compared to Incorrect HELLO Message attacks described in Section 4.4, 398 the messages used in Replay attack are legitimate messages sent out 399 by (non-malicious) NHDP Routers and replayed at a later time or 400 different locality by malicious routers. This makes this kind of 401 attack harder to be detect and to counteract: integrity checks cannot 402 help in this case as the original message ICV (Integrity Check 403 Values) was correctly calculated. 405 4.6. Message Timing Attacks 407 In NHDP, each HELLO message contains a "validity time" and may 408 contain an "interval time" field, identifying the time for which 409 information in that control message should be considered valid until 410 discarded, and the time until the next control message of the same 411 type should be expected [RFC5497]. 413 4.6.1. Interval Time Attack 415 A use of the expected interval between two successive HELLO messages 416 is for determining the link quality in NHDP: if messages are not 417 received within the expected intervals (e.g., a certain fraction of 418 messages are missing), then this may be used to exclude a link from 419 being considered as useful, even if (some) bi-directional 420 communication has been verified. If a Compromised NHDP Router X 421 spoofs the identity of an existing NHDP Router A, and sends HELLOs 422 indicating a low interval time, an NHDP Router B receiving this HELLO 423 will expect the following HELLO to arrive within the interval time 424 indicated - or otherwise, decrease the link quality for the link A-B. 425 Thus, X may cause NHDP Router B's estimate of the link quality for 426 the link A-B to fall below the limit, where it is no longer 427 considered as useful and, thus, not used [CPSCOM2011]. [RFC4593] 428 would categorize the threat consequence as Usurpation. 430 4.6.2. Validity Time Attack 432 A Compromised NHDP Router X can spoof the identity of an NHDP Router 433 A and send a HELLO using a low validity time (e.g.,1 ms). A 434 receiving NHDP Router B will discard the information upon expiration 435 of that interval, i.e., a link between NHDP Router A and B will be 436 "torn down" by X. It can be caused by intended malicious behaviors, 437 or simply mis-configuration in the NHDP Routers. [RFC4593] would 438 categorize the threat consequence as Usurpation. 440 4.7. Indirect Channel Overloading 442 Indirect Channel Overloading is when a Compromised NHDP Router X by 443 its actions causes other legitimate NHDP Routers to generate 444 inordinate amounts of control traffic. This increases channel 445 occupation, and the overhead in each receiving NHDP Router processing 446 this control traffic. With this traffic originating from Legitimate 447 NHDP Routers, the malicious device may remain undetected to the wider 448 network. It is a form of Interference and Overload with threat 449 consequences of Disruption [RFC4593]. 451 Figure 3 illustrates Indirect Channel Overloading with NHDP. A 452 Compromised NHDP Router X advertises a symmetric spoofed link to the 453 non-existing NHDP Router B (at time t0). Router A selects X as MPR 454 upon reception of the HELLO, and will trigger a HELLO at t1. 455 Overhearing this triggered HELLO, the attacker sends another HELLO at 456 t2, advertising the link to B as lost, which leads to NHDP Router A 457 deselecting the attacker as MPR, and another triggered message at t3. 458 The cycle may be repeated, alternating advertising the link X-B as 459 LOST and SYM. 461 MPRs(X) MPRs() 462 .---. .---. .---. .---. 463 | A | | A | | A | | A | 464 '---' '---' '---' '---' 465 | | | | 466 | SYM(B) | | LOST(B) | 467 | | | | 468 .---. .---. .---. .---. 469 | X | | X | | X | | X | 470 '---' '---' '---' '---' 471 . . 472 . . 473 . . 474 ..... ..... 475 . B . . B . 476 ..... ..... 478 t0 t1 t2 t3 480 Figure 3 482 4.8. Attack on Link Quality Update 484 According to NHDP, "Link quality is a mechanism whereby a router MAY 485 take considerations other than message exchange into account for 486 determining when a link is and is not a candidate for being 487 considered as HEARD or SYMMETRIC. As such, it is a link admission 488 mechanism.". 490 Section 14.4 of NHDP [RFC6130] then lists several examples of which 491 information can be used to update link quality. One of the listed 492 examples is to update link quality based on [RFC5444] packet 493 exchanges between neighbor routers, e.g., an NHDP Router may update 494 the link quality of a neighbor based on receipt or loss of packets if 495 they include a sequential packet sequence number. 497 NHDP does not specify how to acquire link quality updates 498 normatively, however, attack vectors may be introduced if an 499 implementation chooses to calculate link quality based on packet 500 sequence numbers. The consequences of such threats would depend on 501 specific implementations. For example, if the link quality update is 502 based on sequential packet sequence number from neighbor routers, a 503 Comprised NDHP Router can spoof packets appearing to be from another 504 Legitimate NHDP Router that skips some packet sequence numbers. The 505 NHDP Router receiving the spoofed packets may degrade the link 506 quality as it appears that several packets have been dropped. 507 Eventually, the router remove the neighbor when the link quality 508 drops below HYST_REJECT. 510 5. Impact of inconsistent Information Bases on Protocols using NHDP 512 This section describes the impact on protocols, using NHDP, of NHDP 513 failing to obtain and represent accurate information, possibly as a 514 consequence of the attacks described in Section 4. This description 515 emphasizes the impacts on the MANET protocols OLSRv2 516 [I-D.ietf-manet-olsrv2], and SMF [RFC6621]. 518 5.1. MPR Calculation 520 MPR selection (as used in e.g., [I-D.ietf-manet-olsrv2] and 521 [RFC6621]) uses information about a router's 1-hop and 2-hop 522 neighborhood, assuming that (i) this information is accurate, and 523 (ii) all 1-hop neighbors are apt to act as as MPR, depending on the 524 willingness they report. Thus, a Compromised NHDP router may seek to 525 manipulate the 1-hop and 2-hop neighborhood information in a router 526 such as to cause the MPR selection to fail, leading to a flooding 527 disruption of TC messages, which can result in incomplete topology 528 advertisement, or degrade the optimized flooding to classical 529 flooding. 531 5.1.1. Flooding Disruption due to Identity Spoofing 533 A Compromised NHDP router can spoof the identify of other routers, to 534 disrupt the MPR selection, so as to cache certain parts of the 535 network from the flooding traffic [IJNSIA2010]. 537 In Figure 4, a Compromised NHDP router X spoofs the identity of B. 538 The link between X and C is correctly detected and listed in X's 539 HELLOs. Router A will receive HELLOs indicating links from, 540 respectively B:{B-E}, X:{X-C, X-E}, and D:{D-E, D-C}. For router A, 541 X and D are equal candidates for MPR selection. To make sure the X 542 can be selected as MPR for router A, X can set its willingness to the 543 maximum value. 545 .---. .---. .---. 546 | E |----| D |----| C | 547 '---' '---' '---' 548 | | . 549 | | . 550 .---. .---. .---. 551 | B |----| A |----| X | 552 '---' '---' '---' 553 spoofs B 555 Figure 4 557 If B and X (i) accept MPR selection and (ii) forward flooded traffic 558 as-if they were both B, identity spoofing by X is harmless. However, 559 if X does not forward flooded traffic (i.e., does not accept MPR 560 selection), its presence entails flooding disruption: selecting B 561 over D renders C unreachable by flooded traffic. 563 .---. 564 | D | 565 '---' 566 | 567 | 568 .---. .---. .---. .---. .---. 569 | X |----| A |----| B |----| C |----| E |... 570 '---' '---' '---' '---' '---' 571 spoofs E 573 Figure 5 575 In Figure 5, the Compromised NHDP router X spoofs the identity of E, 576 i.e.,router A and C both receive HELLOs from a router identifying as 577 E. For router B, A and C present the same neighbor sets, and are 578 equal candidates for MPR selection. If router B selects only router 579 A as MPR, C will not relay flooded traffic from or transiting via B, 580 and router X (and routers to the "right" of it) will not receive 581 flooded traffic. 583 5.1.2. Flooding Disruption due to Link Spoofing 585 A Compromised NHDP router can also spoof links to other NHDP routers, 586 and thereby makes itself appear as the most appealing candidate of 587 MPR for its neighbors, possibly to the exclusion of other NHDP 588 routers in the neighborhood (this, in particular, if the Compromised 589 NHDP router spoof links to all other NHDP routers in the 590 neighborhood, plus to one other NHDP router). By thus excluding 591 other legitimate NHDP routers from being selected as MPR, the 592 Compromised NHDP router will receive and be expected to relay all 593 flooded traffic (e.g., TC messages in OLSRv2 or data traffic in SMF) 594 - which it can then drop or otherwise manipulate. 596 In the network in Figure 6, the Compromised NHDP router X spoofs 597 links to the existing router C, as well as to a fictitious W. Router 598 A receives HELLOs from X and B, reporting X: {X-C, X-W}, b: {B-C}. 599 All else being equal, X appears a better choice as MPR than B, as X 600 appears to cover all neighbors of B, plus W. 602 ,---. ..... 603 | S | . C . 604 '---' ..... 605 | . 606 | . 607 .---. .---. .---. .---. .---. 608 | D |----| C |----| B |----| A |----| X | 609 '---' '---' '---' '---' '---' 610 . 611 . 612 ..... 613 . w . 614 ..... 616 Figure 6 618 As router A will not select B as MPR, B will not relay flooded 619 messages received from router A. The NHDP routers on the left of B 620 (starting with C) will, thus, not receive any flooded messages from 621 or transiting NHDP router A (e.g., a message originating from S). 623 5.1.3. Broadcast Storm 625 Compromised NHDP router may attack the network by attempting to 626 degrade the performance of optimized flooding algorithms so as to be 627 equivalent to classic flooding. This can be achieved by forcing an 628 NHDP router into choosing all its 1-hop neighbors as MPRs. In 629 MANETs, a broadcast storm caused by classic flooding is a serious 630 problem which can result in redundancy, contention and collisions 631 [MOBICOM99]. 633 As shown in Figure 7, the Compromised NHDP router X spoofs the 634 identity of NHDP router B and, spoofs a link to router Y {B-Y} (Y 635 does not have to be exist). By doing so, the legitimate NHDP router 636 A has to select the legitimate NHDP router B as its MPR, in order for 637 it to reach all its 2-hop neighbors. The Compromised NHDP router Y 638 can perform this identity+link spoofing for all of NHDP router A's 639 1-hop neighbors, thereby forcing NHDP router A to select all its 640 neighbors as MPR - disabling the optimization sought by the MPR 641 mechanism. 643 .---. 644 | B | 645 '---' 646 | 647 | 648 .---. .---. ..... 649 | A |----| X | . . . Y . 650 '---' '---' ..... 651 spoofs B 653 Figure 7 655 5.2. Routing Loops 657 Inconsistent information bases, provided by NHDP to other protocols, 658 can also cause routing loops. In Figure 8, the Compromised NHDP 659 router X spoofs the identity of NHDP router E. NHDP router D has data 660 traffic to send to NHDP router A. The topology recorded in the 661 information base of router D indicates that the shortest path to 662 router A is {D->E->A}, because of the link {A-E} reported by X. 663 Therefore, the data traffic will be routed to the NHDP router E. As 664 the link {A-E} does not exist in NHDP router E's information bases, 665 it will identify the next hop for data traffic to NHDP router A as 666 being NHDP router D. A loop between the NHDP routers D and E is thus 667 created. 669 .---. .---. .---. .---. .---. 670 | A |----| B |----| C |----| D |----| E | 671 '---' '---' '---' '---' '---' 672 | 673 | 674 .---. 675 | X | 676 '---' 677 spoofs E 679 Figure 8 681 5.3. Invalid or Non-Existing Paths to Destinations 683 By reporting inconsistent topology information in NHDP, the invalid 684 links/routers can be propagated as link state information with TC 685 messages and results in route failure. As illustrated in Figure 8, 686 if NHDP router B tries to send data packets to NHDP router E, it will 687 choose router A as its next hop, based on the information of non- 688 existing link {A-E} reported by the Compromised NHDP router X. 690 5.4. Data Sinkhole 692 With the ability to spoof multiple identities of legitimate NHDP 693 routers (by eavesdropping, for example), the Compromised NHDP router 694 can represent a "data sinkhole" for its 1-hop and 2-hop neighbors. 695 Data packets that come across its neighbors may be forwarded to the 696 Compromised NHDP router instead of to the real destination. The 697 packet can then be dropped, manipulated, duplicated, etc., by the 698 Compromised NHDP router. As shown in Figure 8, if the Compromised 699 NHDP router X spoofs the identity of NHDP router E, all the data 700 packets to E that cross NHDP routers A and B will be sent to NHDP 701 router X, instead of to E. 703 6. Future Work 705 This document does not propose solutions to mitigate the security 706 threats described in Section 4. However, this section aims at 707 driving new work by suggesting which threats discussed in Section 4 708 could be addressed in new protocol work, which in deployment, and 709 which by applications: 711 o Section 4.1: Jamming - If a single router or a small area of the 712 MANET is jammed, protocols could be specified that increase link 713 metrics in NHDP for the jammed links. When a routing protocol, 714 such as OLSRv2, uses NHDP for neighborhood discovery, other paths 715 leading "around" the jammed area would be preferred, and therefore 716 mitigate the threat to some extent. 718 o Section 4.2: DoS - DoS using a massive amount of HELLO messages 719 can be mitigated by admitting only trusted routers to the network. 720 [I-D.ietf-manet-nhdp-olsrv2-sec] specifies a mechanism for adding 721 Integrity Check Values (ICVs) to HELLO messages and therefore 722 providing an admittance mechanism for NHDP Routers to a MANET. 723 (Note that adding ICVs adds itself a new DoS attack vector, as ICV 724 verification requires CPU and memory resources.) Using ICVs does 725 however not address the problem of compromised routers. Detecting 726 compromised routers could be addressed in new work. 727 [I-D.ietf-manet-nhdp-olsrv2-sec] mandates to implement a security 728 mechanism based on shared keys, which makes excluding single 729 compromised routers difficult; work could be done to facilitate 730 revocation mechanisms in certain MANET use cases where routers 731 have sufficient capabilities to support asymmetric keys. 733 o Section 4.3: Eavesdropping - [I-D.ietf-manet-nhdp-olsrv2-sec] adds 734 ICVs to HELLO messages, but does not encrypt them. Therefore, 735 eavesdropping of control traffic is not mitigated. Future work 736 could provide encryption of control traffic for sensitive MANET 737 topologies. Note that, other than using a single shared secret 738 key, encryption to a potentially a priori unknown set of 739 neighbors, especially without multiplying overheads, is non- 740 trivial. By traffic analyzing, attackers could still deduce the 741 network information like HELLO message triggering, and HELLO 742 message size, even HELLO messages are encrypted. 744 o Section 4.4.2: Link spoofing - [I-D.ietf-manet-nhdp-olsrv2-sec] 745 provides certain protection against link spoofing, but an NHDP 746 Router has to "trust" the originator of a HELLO that the 747 advertized links are correct. For example, if a router A reports 748 a link to B, routers receiving HELLOs from A have to trust that B 749 is actually a (symmetric) neighbor of A. New protocol work could 750 address protection of links without overly increasing space and 751 time overheads. An immediate suggestion for deployments is to 752 protect routers against being compromised and distributing keys 753 only to trusted routers. 755 o Section 4.5: Replay Attacks - [I-D.ietf-manet-nhdp-olsrv2-sec] 756 provides certain protection against replay attacks, using ICVs and 757 timestamps. It is still feasible to replay control messages 758 within limited time. A suggestion for deployments is to provide 759 time synchronization between routers. New work could provide time 760 synchronization mechanisms for certain MANET use cases, or specify 761 a mechanism using nonces instead of time stamps in HELLO messages. 763 o Section 4.4.1: Identity spoofing, Section 4.6: Message timing 764 attacks, Section 4.7: Indirect channel overloading, and 765 Section 4.8: Attack on link quality update - 766 [I-D.ietf-manet-nhdp-olsrv2-sec] provides protection against these 767 attacks, assuming that routers are not compromised. 769 7. Security Considerations 771 This document does not specify a protocol or a procedure. The 772 document, however, reflects on security considerations for NHDP and 773 MANET routing protocols using NHDP for neighborhood discovery. 775 8. IANA Considerations 777 This document contains no actions for IANA. 779 9. Acknowledgments 781 The authors would like to gratefully acknowledge the following people 782 for valuable comments and technical discussions: Teco Boot, Henning 783 Rogge, Christopher Dearlove, John Dowdell, Joseph Macker, and the all 784 the other participants of IETF MANET working group. 786 10. References 788 10.1. Normative References 790 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 791 "Generalized Mobile Ad Hoc Network (MANET) Packet/Message 792 Format", RFC 5444, February 2009. 794 [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value 795 Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, 796 March 2009. 798 [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc 799 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 800 RFC 6130, April 2011. 802 10.2. Informative References 804 [ACCT2012] 805 Jhaveri, R. and S. Patel, "DoS Attacks in Mobile Ad Hoc 806 Networks: A Survey", Second International Conference 807 on Advanced Computing & Communication Technologies (ACCT), 808 Jan 2012. 810 [CPSCOM2011] 811 Yi, J., Clausen, T., and U. Herberg, "Vulnerability 812 Analysis of the Simple Multicast Forwarding (SMF) Protocol 813 for Mobile Ad Hoc Networks", Proceedings of the IEEE 814 International Conference on Cyber, Physical, and Social 815 Computing (CPSCom), October 2011. 817 [I-D.ietf-manet-nhdp-olsrv2-sec] 818 Herberg, U., Dearlove, C., and T. Clausen, "Integrity 819 Protection for Control Messages in NHDP and OLSRv2", 820 draft-ietf-manet-nhdp-olsrv2-sec-02 (work in progress), 821 April 2013. 823 [I-D.ietf-manet-olsrv2] 824 Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, 825 "The Optimized Link State Routing Protocol version 2", 826 draft-ietf-manet-olsrv2-19 (work in progress), March 2013. 828 [I-D.nguyen-manet-management] 829 Nguyen, J., Cole, R., Herberg, U., Yi, J., and J. Dean, 830 "Network Management of Mobile Ad hoc Networks (MANET): 831 Architecture, Use Cases, and Applicability", 832 draft-nguyen-manet-management-00 (work in progress), 833 February 2013. 835 [IJNSIA2010] 836 Herberg, U. and T. Clausen, "Security Issues in the 837 Optimized Link State Routing Protocol version 2", 838 International Journal of Network Security & Its 839 Applications, April 2010. 841 [MOBICOM99] 842 Ni, S., Tseng, Y., Chen, Y., and J. Sheu, "The Broadcast 843 Storm Problem in a Mobile Ad Hoc Network", Proceedings of 844 the 5th annual ACM/IEEE international conference on Mobile 845 computing and networking, 1999. 847 [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to 848 Routing Protocols", RFC 4593, October 2006. 850 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 851 RFC 4949, August 2007. 853 [RFC6621] Macker, J., "Simplified Multicast Forwarding", RFC 6621, 854 May 2012. 856 [RFC6779] Herberg, U., Cole, R., and I. Chakeres, "Definition of 857 Managed Objects for the Neighborhood Discovery Protocol", 858 RFC 6779, October 2012. 860 Authors' Addresses 862 Jiazi Yi 863 LIX, Ecole Polytechnique 864 91128 Palaiseau Cedex, 865 France 867 Phone: +33 1 77 57 80 85 868 Email: jiazi@jiaziyi.com 869 URI: http://www.jiaziyi.com/ 870 Ulrich Herberg 871 Fujitsu Laboratories of America 872 1240 E Arques Ave 873 Sunnyvale, CA 94085 874 USA 876 Email: ulrich@herberg.name 877 URI: http://www.herberg.name/ 879 Thomas Heide Clausen 880 LIX, Ecole Polytechnique 881 91128 Palaiseau Cedex, 882 France 884 Phone: +33 6 6058 9349 885 Email: T.Clausen@computer.org 886 URI: http://www.thomasclausen.org/