idnits 2.17.1 draft-herberg-manet-nhdp-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 12, 2012) is 4399 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-19) exists of draft-ietf-manet-olsrv2-14 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile Ad hoc Networking (MANET) U. Herberg 3 Internet-Draft Fujitsu Laboratories of America 4 Intended status: Informational J. Yi 5 Expires: September 13, 2012 T. Clausen 6 LIX, Ecole Polytechnique 7 March 12, 2012 9 Security Threats for NHDP 10 draft-herberg-manet-nhdp-sec-threats-01 12 Abstract 14 This document analyses common security threats of the Neighborhood 15 Discovery Protocol (NHDP), and describes their potential impacts on 16 MANET routing protocols using NHDP. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 13, 2012. 35 Copyright Notice 37 Copyright (c) 2012 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. NHDP Threat Overview . . . . . . . . . . . . . . . . . . . . . 4 55 4. Detailed Threat Description . . . . . . . . . . . . . . . . . 4 56 4.1. Jamming . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 4.2. Eavesdropping . . . . . . . . . . . . . . . . . . . . . . 5 58 4.3. Incorrect HELLO Message Generation . . . . . . . . . . . . 5 59 4.3.1. Identity Spoofing . . . . . . . . . . . . . . . . . . 6 60 4.3.2. Link Spoofing . . . . . . . . . . . . . . . . . . . . 6 61 4.4. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 7 62 4.5. Sequence Number Attack . . . . . . . . . . . . . . . . . . 8 63 4.6. Message Timing Attacks . . . . . . . . . . . . . . . . . . 8 64 4.6.1. Interval Time Attack . . . . . . . . . . . . . . . . . 8 65 4.6.2. Validity Time Attack . . . . . . . . . . . . . . . . . 8 66 4.7. Indirect Jamming . . . . . . . . . . . . . . . . . . . . . 9 67 5. Impact of inconsistent Information Bases on Protocols 68 using NHDP . . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 5.1. MPR Calculation . . . . . . . . . . . . . . . . . . . . . 10 70 5.1.1. Flooding Disruption due to Identity Spoofing . . . . . 10 71 5.1.2. Flooding Disruption due to Link Spoofing . . . . . . . 11 72 5.1.3. Broadcast Storm . . . . . . . . . . . . . . . . . . . 12 73 5.2. Routing Loops . . . . . . . . . . . . . . . . . . . . . . 13 74 5.3. Invalid or Non-Existing Paths to Destinations . . . . . . 13 75 5.4. Data Sinkhole . . . . . . . . . . . . . . . . . . . . . . 14 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 80 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 83 1. Introduction 85 The Neighborhood Discovery Protocol (NHDP) [RFC6130] allows routers 86 to acquire topological information up to two hops away from 87 themselves, by way of periodic HELLO message exchanges. The 88 information acquired by NHDP is used by other protocols, such as 89 OLSRv2 [OLSRv2] and SMF [SMF]. The topology information, acquired by 90 way of NHDP, serves these routing protocols for calculating paths to 91 all destinations in the MANET, for relay set selection for network- 92 wide transmissions, etc. 94 As NHDP is typically used in wireless environments, it is potentially 95 exposed to different kinds of security threats, some of which are of 96 particular significance as compared to wired networks. As wireless 97 radio waves can be captured as well as transmitted by any wireless 98 device within radio range, there is commonly no physical protection 99 as otherwise known for wired networks. [RFC6130] does not define any 100 explicit security measures for protecting the integrity of the 101 information it acquires, however suggests that this be addressed in a 102 fashion appropriate to the deployment of the network. 104 This document analyses possible attacks on NHDP and outlines the 105 consequences of such attacks to the state maintained by NHDP in each 106 router (and, thus, made available to protocols using this state). 108 2. Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 112 "OPTIONAL" in this document are to be interpreted as described in 113 [RFC2119]. 115 This document uses the terminology and notation defined in [RFC5444] 116 and [RFC6130]. 118 Additionally, this document introduces the following terminology: 120 NHDP Router: A MANET router, running NHDP as specified in [RFC6130]. 122 Attacker: A device, present in the network and which intentionally 123 seeks to compromise the information bases in NHDP routers. 125 Compromised NHDP Router: An attacker, present in the network and 126 which generates syntactically correct NHDP control messages. 127 Control messages emitted by a Compromised NHDP router may contain 128 additional information, or omit information, as compared to a 129 control message generated by a non-compromized NHDP router located 130 in the same topological position in the network. 132 Legitimate NHDP Router: An NHDP router, which is not a Compromised 133 NHDP Router. 135 3. NHDP Threat Overview 137 [RFC6130] defines a HELLO messages exchange, enabling each NHDP 138 router to acquire topological information describing its 1-hop and 139 2-hop neighbors, and specifies information bases for recording this 140 information. 142 An NHDP router running [RFC6130] periodically transmits HELLO 143 messages using a link-local multicast on each of its interfaces with 144 a hop-limit of 1 (i.e., HELLOs are never forwarded). In these HELLO 145 messages, an NHDP router announces the IP addresses as heard, 146 symmetric or lost neighbor interface addresses. 148 An adversary has several ways of harming this neighbor discovery 149 process: It can announce "wrong" information about its identity, 150 postulate non-existent links, and replay HELLO messages. These 151 attacks are presented in detail in Section 4. 153 The different ways of attacking an NHDP deployment may eventually 154 lead to inconsistent information bases, not accurately reflecting the 155 correct topology of the MANET. The consequence hereof is that 156 protocols using NHDP will base their operation on incorrect 157 information, causing routing protocols to not be able to calculate 158 correct (or any) paths, degrade the performance of flooding 159 operations based on reduced relay sets, etc. These consequences to 160 protocols using NHDP are described in detail in Section 5. 162 4. Detailed Threat Description 164 For each threat, described in the below, a description of the 165 mechanism of the corresponding attack is given, followed by a 166 description of how the attack affects NHDP. The impacts from each 167 attack on protocols using NHDP are given in Section 5. 169 For simplicity in the description, examples given assume that NHDP 170 routers have a single interface with a single IP address configured. 171 All the attacks apply, however, for NHDP routers with multiple 172 interfaces and multiple addresses as well. 174 4.1. Jamming 176 One vulnerability, common for all protocols operating a wireless ad 177 hoc network, is that of "jamming", i.e., that a device generates 178 massive amounts of interfering radio transmissions, which will 179 prevent legitimate traffic (e.g.,control traffic as well as data 180 traffic) on part of a network. 182 Depending on lower layers, this may not affect transmissions: HELLO 183 messages from an NHDP router with "jammed" interfaces may be received 184 by other NHDP routers. As [RFC6130] identifies and uses only bi- 185 directional links, a link from a jammed NHDP router to a non-jammed 186 NHDP router would not be considered, and the jammed NHDP router 187 appear simply as "disconnected" for the un-jammed part of the network 188 - which is able to maintain accurate topology maps. 190 If, due to a jamming attack, a considerable amount of HELLO messages 191 are lost or corrupted due to collisions, neighbor NHDP routers are 192 not able to establish links between them any more. Thus, NHDP will 193 present empty information bases to the protocols using it. 195 4.2. Eavesdropping 197 Eavesdropping is a common and easy passive attack in a wireless 198 environment. Once a packet is transmitted, any adjacent NHDP router 199 can potentially obtain a copy, for immediate or later processing. 200 Neither the source nor the intended destination can detect this. A 201 malicious NHDP router can eavesdrop on the NHDP message exchange and 202 thus learn the local topology. It may also eavesdrop on data traffic 203 to learn source and destination addresses of data packets, or other 204 header information, as well as the packet payload. 206 Eavesdropping does not pose a direct threat to the network nor to 207 NHDP, in as much as that it does not alter the information recorded 208 by NHDP in its information bases and presented to other protocols 209 using it, but it can provide network information required for 210 enabling other attacks, such as the identity of communicating NHDP 211 routers, link characteristic, NHDP router configuration, etc. 213 4.3. Incorrect HELLO Message Generation 215 An NHDP router running [RFC6130] performs two distinct tasks: it 216 periodically generates HELLO messages, and it processes incoming 217 HELLO messages from neighbor NHDP routers. This section describes 218 security attacks involving the HELLO generation. 220 4.3.1. Identity Spoofing 222 Identity spoofing implies that a Compromised NHDP router sends HELLO 223 messages, pretending to have the identity of another NHDP router. A 224 Compromised NHDP router can accomplish this by using another NHDP 225 router's IP address in an address block of a HELLO message, and 226 associating this address with a LOCAL_IF Address Block TLV. 228 An NHDP router receiving the HELLO message from a neighbor, will 229 assume that it originated from the NHDP router with the spoofed 230 interface address. As a consequence, it will add a Link Tuple to 231 that neighbor with the spoofed address, and include it in its next 232 HELLO messages as a heard neighbor (and possibly as symmetric 233 neighbor after another HELLO exchange). 235 Identity spoofing is particular harmful if a Compromised NHDP router 236 spoofs the identity of another NHDP router that exists in the same 237 routing domain. With respect to NHDP, such a duplicated, spoofed 238 address can lead to an inconsistent state up to two hops from an NHDP 239 router. Figure 1 depicts a simple example. In that example, NHDP 240 router A is in radio range of C, but not of the Compromised NHDP 241 router X. If X spoofs the address of A, that can lead to conflicts 242 for upper-layer routing protocols, and therefore for wrong path 243 calculations as well as incorrect data traffic forwarding. 245 .---. .---. .---. 246 | A |----| C |----| X | 247 '---' '---' '---' 249 Figure 1 251 Figure 2 depicts another example. In this example, A is two hops 252 away from NHDP router C, reachable through NHDP router B. If the 253 Compromised NHDP router X spoofs the address of A, C may think that A 254 is indeed reachable through NHDP router D. 256 .---. .---. .---. .---. .---. 257 | A |----| B |----| C |----| D |----| X | 258 '---' '---' '---' '---' '---' 260 Figure 2 262 4.3.2. Link Spoofing 264 Similar to identity spoofing, link spoofing implies that a 265 Compromised NHDP router sends HELLO messages, signaling an incorrect 266 set of neighbors. This may take either of two forms: 268 o A Compromised NHDP Router can postulate addresses of non-present 269 neighbor NHDP routers in an address block of a HELLO, associated 270 with LINK_STATUS TLVs. 272 o A Compromised NHDP router can "ignore" otherwise existing 273 neighbors by not advertising them in its HELLO messages. 275 The effect of link spoofing with respect to NHDP are twofold, 276 depending on the two cases mentioned above: If the Compromised NHDP 277 router ignores existing neighbors in its advertisements, links will 278 be missing in the information bases maintained by other routers, and 279 there may not be any connectivity to or from these NHDP routers to 280 others NHDP routers in the MANET. If, on the other hand, the 281 Compromised NHDP router advertises non-existing links, this will lead 282 to inclusion of topological information in the information base, 283 describing non-existing links in the network (which, then, may be 284 used by other protocols using NHDP in place of other, existing, 285 links). 287 4.4. Replay Attack 289 A replay attack implies that control traffic from one region of the 290 network is recorded and replayed in a different region (this type of 291 attack is also known as the Wormhole attack). This may, for example, 292 happen when two Compromised NHDP routers collaborate on an attack, 293 one recording traffic in its proximity and tunneling it to the other 294 Compromised NHDP router, which replays the traffic. In a protocol 295 where links are discovered by testing reception, this will result in 296 extraneous link creation (basically, a "virtual" link between the two 297 Compromised NHDP routers will appear in the information bases of 298 neighboring NHDP routers). 300 While this situation may result from an attack, it may also be 301 intentional: if data-traffic also is relayed over the "virtual" link, 302 the link being detected is indeed valid for use. This is, for 303 instance, used in wireless repeaters. If data traffic is not carried 304 over the virtual link, an imaginary, useless, link between the two 305 Compromised NHDP routers, has been advertised, and is being recorded 306 in the information bases of their neighboring NHDP routers. 308 Replay attacks can be especially damaging if coupled with spoofing 309 and tampering with sequence numbers in the replayed messages, 310 potentially destroying some important topology information in NHDP 311 routers all over the network, as described in Section 4.5. 313 4.5. Sequence Number Attack 315 [RFC6130] uses message sequence numbers, to avoid processing and 316 forwarding the same message more than once. An attack may consist of 317 a Compromised NHDP router, spoofing the identity of another 318 Legitimate NHDP router in the network and transmitting a large number 319 of HELLO messages, each with different message sequence numbers. 320 Subsequent HELLOs with the same sequence numbers, originating from 321 theLegitimate NHDP router whose identity was spoofed, would hence be 322 ignored, until eventually information concerning these "spoofed" 323 HELLO messages expires. 325 As illustrated in Figure 1, if the Compromised NHDP router X spoofs 326 the identify of NHDP router A, and broadcasts several HELLO messages, 327 all the valid HELLO messages sent by A with the same sequence numbers 328 will be discarded by C, until the information concerning these HELLOs 329 expire. 331 4.6. Message Timing Attacks 333 In [RFC6130], each HELLO message contains a "validity time" and may 334 contain an "interval time" field, identifying the time for which 335 information in that control message should be considered valid until 336 discarded, and the time until the next control message of the same 337 type should be expected [RFC5497]. 339 4.6.1. Interval Time Attack 341 A use of the expected interval between two successive HELLO messages 342 is for determining the link quality in [RFC6130]: if messages are not 343 received within the expected intervals (e.g., a certain fraction of 344 messages are missing), then this may be used to exclude a link from 345 being considered as useful, even if (some) bi-directional 346 communication has been verified. If a Compromised NHDP router X 347 spoofs the identity of an existing NHDP router A, and sends HELLOs 348 indicating a low interval time, an NHDP router B receiving this HELLO 349 will expect the following HELLO to arrive within the interval time 350 indicated - or otherwise, decrease the link quality for the link A-B. 351 Thus, X may cause NHDP router B's estimate of the link quality for 352 the link A-B to fall below the limit, where it is no longer 353 considered as useful and, thus, not used. 355 4.6.2. Validity Time Attack 357 A Compromised NHDP router X can spoof the identity of an NHDP router 358 A and send a HELLO using a low validity time (e.g.,1 ms). A 359 receiving NHDP router B will discard the information upon expiration 360 of that interval, i.e., a link between NHDP router A and B will be 361 "torn down" by X. 363 4.7. Indirect Jamming 365 Indirect jamming is when a Compromised NHDP router X by its actions 366 causes other legitimate NHDP routers to generate inordinate amounts 367 of control traffic. This increases channel occupation, and the 368 overhead in each receiving NHDP router processing this control 369 traffic. With this traffic originating from Legitimate NHDP routers, 370 the malicious device may remain undetected to the wider network. 372 Figure 3 illustrates indirect jamming of [RFC6130]. A Compromised 373 NHDP router X advertises a symmetric spoofed link to the non-existing 374 NHDP router B (at time t0). Router A selects X as MPR upon reception 375 of the HELLO, and will trigger a HELLO at t1. Overhearing this 376 triggered HELLO, the attacker sends another HELLO at t2, advertising 377 the link to B as lost, which leads to NHDP router A deselecting the 378 attacker as MPR, and another triggered message at t3. The cycle may 379 be repeated, alternating advertising the link X-B as LOST and SYM. 381 MPRs(X) MPRs() 382 .---. .---. .---. .---. 383 | A | | A | | A | | A | 384 '---' '---' '---' '---' 385 | | | | 386 | SYM(B) | | LOST(B) | 387 | | | | 388 .---. .---. .---. .---. 389 | X | | X | | X | | X | 390 '---' '---' '---' '---' 391 . . 392 . . 393 . . 394 ..... ..... 395 . B . . B . 396 ..... ..... 398 t0 t1 t2 t3 400 Figure 3 402 5. Impact of inconsistent Information Bases on Protocols using NHDP 404 This section describes the impact on protocols, using NHDP, of NHDP 405 failing to obtain and represent accurate information, possibly as a 406 consequence of the attacks described in Section 4. This description 407 emphasizes the impacts on the MANET protocols OLSRv2 [OLSRv2], and 408 SMF [SMF]. 410 5.1. MPR Calculation 412 MPR selection (as used in e.g., [OLSRv2] and [SMF]) uses information 413 about a router's 1-hop and 2-hop neighborhood, assuming that (i) this 414 information is accurate, and (ii) all 1-hop neighbors are apt to act 415 as as MPR, depending on the willingness they report. Thus, a 416 Compromised NHDP router will seek to manipulate the 1-hop and 2-hop 417 neighborhood information in a router such as to cause the MPR 418 selection to fail, leading to a flooding disruption of TC messages. 420 5.1.1. Flooding Disruption due to Identity Spoofing 422 A Compromised NHDP router can spoof the identify of other routers, to 423 disrupt the MPR selection, so as to cache certain parts of the 424 network from the flooding traffic. 426 In Figure 4, a Compromised NHDP router X spoofs the identity of B. 427 The link between X and C is correctly detected and listed in X's 428 HELLOs. Router A will receive HELLOs indicating links from, 429 respectively B:{B-E}, X:{X-C, X-E}, and D:{D-E, D-C}. For router A, 430 X and D are equal candidates for MPR selection. To make sure the X 431 can be selected as MPR for router A, X can set its willingness to the 432 maximum value. 434 .---. .---. .---. 435 | E |----| D |----| C | 436 '---' '---' '---' 437 | | . 438 | | . 439 .---. .---. .---. 440 | B |----| A |----| X | 441 '---' '---' '---' 442 spoofs B 444 Figure 4 446 If B and X (i) accept MPR selection and (ii) forward flooded traffic 447 as-if they were both B, identity spoofing by X is harmless. However, 448 if X does not forward flooded traffic (i.e., does not accept MPR 449 selection), its presence entails flooding disruption: selecting B 450 over D renders C unreachable by flooded traffic. 452 .---. 453 | D | 454 '---' 455 | 456 | 457 .---. .---. .---. .---. .---. 458 | X |----| A |----| B |----| C |----| E |... 459 '---' '---' '---' '---' '---' 460 spoofs E 462 Figure 5 464 In Figure 5, the Compromised NHDP router X spoofs the identity of E, 465 i.e.,router A and C both receive HELLOs from a router identifying as 466 E. For router B, A and C present the same neighbor sets, and are 467 equal candidates for MPR selection. If router B selects only router 468 A as MPR, C will not relay flooded traffic from or transiting via B, 469 and router X (and routers to the "right" of it) will not receive 470 flooded traffic. 472 5.1.2. Flooding Disruption due to Link Spoofing 474 A Compromised NHDP router can also spoof links to other NHDP routers, 475 and thereby makes itself appear as the most appealing candidate of 476 MPR for its neighbors, possibly to the exclusion of other NHDP 477 routers in the neighborhood (this, in particular, if the Compromised 478 NHDP router spoof links to all other NHDP routers in the 479 neighborhood, plus to one other NHDP router). By thus excluding 480 other legitimate NHDP routers from being selected as MPR, the 481 Compromised NHDP router will receive and be expected to relay all 482 flooded traffic (e.g., TC messages in OLSRv2 or data traffic in SMF) 483 - which it can then drop or otherwise manipulate. 485 In the network in Figure 6, the Compromised NHDP router X spoofs 486 links to the existing router C, as well as to a fictitious W. Router 487 A receives HELLOs from X and B, reporting X: {X-C, X-W}, b: {B-C}. 488 All else being equal, X appears a better choice as MPR than B, as X 489 appears to cover all neighbors of B, plus W. 491 ,---. ..... 492 | S | . C . 493 '---' ..... 494 | . 495 | . 496 .---. .---. .---. .---. .---. 497 | D |----| C |----| B |----| A |----| X | 498 '---' '---' '---' '---' '---' 499 . 500 . 501 ..... 502 . w . 503 ..... 505 Figure 6 507 As router A will not select B as MPR, B will not relay flooded 508 messages received from router A. The NHDP routers on the left of B 509 (starting with C) will, thus, not receive any flooded messages from 510 or transiting NHDP router A (e.g., a message originating from S). 512 5.1.3. Broadcast Storm 514 Compromised NHDP router may attack the network by attempting to 515 degrade the performance of optimized flooding algorithms so as to be 516 equivalent to classic flooding. This can be achieved by forcing an 517 NHDP router into choosing all its 1-hop neighbors as MPRs. In 518 MANETs, a broadcast storm caused by classic flooding is a serious 519 problem which can result in redundancy, contention and collisions 520 [broadcast-storm]. 522 As shown in Figure 7, the Compromised NHDP router X spoofs the 523 identity of NHDP router B and, spoofs a link to router Y {B-Y} (Y 524 does not have to be exist). By doing so, the legitimate NHDP router 525 A has to select the legitimate NHDP router B as its MPR, in order for 526 it to reach all its 2-hop neighbors. The Compromised NHDP router Y 527 can perform this identity+link spoofing for all of NHDP router A's 528 1-hop neighbors, thereby forcing NHDP router A to select all its 529 neighbors as MPR - disabling the optimization sought by the MPR 530 mechanism. 532 .---. 533 | B | 534 '---' 535 | 536 | 537 .---. .---. ..... 538 | A |----| X | . . . Y . 539 '---' '---' ..... 540 spoofs B 542 Figure 7 544 5.2. Routing Loops 546 Inconsistent information bases, provided by NHDP to other protocols, 547 can also cause routing loops. In Figure 8, the Compromised NHDP 548 router X spoofs the identity of NHDP router E. NHDP router D has data 549 traffic to send to NHDP router A. The topology recorded in the 550 information base of router D indicates that the shortest path to 551 router A is {D->E->A}, because of the link {A-E} reported by X. 552 Therefore, the data traffic will be routed to the NHDP router E. As 553 the link {A-E} does not exist in NHDP router E's information bases, 554 it will identify the next hop for data traffic to NHDP router A as 555 being NHDP router D. A loop between the NHDP routers D and E is thus 556 created. 558 .---. .---. .---. .---. .---. 559 | A |----| B |----| C |----| D |----| E | 560 '---' '---' '---' '---' '---' 561 | 562 | 563 .---. 564 | X | 565 '---' 566 spoofs E 568 Figure 8 570 5.3. Invalid or Non-Existing Paths to Destinations 572 By reporting inconsistent topology information in NHDP, the invalid 573 links/routers can be propagated as link state information with TC 574 messages and results in route failure. As illustrated in Figure 8, 575 if NHDP router B tries to send data packets to NHDP router E, it will 576 choose router A as its next hop, based on the information of non- 577 existing link {A-E} reported by the Compromised NHDP router X. 579 5.4. Data Sinkhole 581 With the ability to spoof multiple identities of legitimate NHDP 582 routers (by eavesdropping, for example), the Compromised NHDP router 583 can represent a "data sinkhole" for its 1-hop and 2-hop neighbors. 584 Data packets that come across its neighbors may be forwarded to the 585 Compromised NHDP router instead of to the real destination. The 586 packet can then be dropped, manipulated, duplicated, etc., by the 587 Compromised NHDP router. As shown in Figure 8, if the Compromised 588 NHDP router X spoofs the identity of NHDP router E, all the data 589 packets to E that cross NHDP routers A and B will be sent to NHDP 590 router X, instead of to E. 592 6. Security Considerations 594 This document does not specify a protocol or a procedure. The 595 document, however, reflects on security considerations for NHDP and 596 MANET routing protocols using NHDP for neighborhood discovery. 598 7. IANA Considerations 600 This document contains no actions for IANA. 602 8. References 604 8.1. Normative References 606 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 607 Requirement Levels", BCP 14, RFC 2119, March 1997. 609 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 610 "Generalized MANET Packet/Message Format", RFC 5444, 611 February 2009. 613 [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value 614 Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, 615 March 2009. 617 [RFC6130] Clausen, T., Dean, J., and C. Dearlove, "MANET 618 Neighborhood Discovery Protocol (NHDP)", RFC 6130, 619 April 2011. 621 8.2. Informative References 623 [OLSRv2] Clausen, T., Dearlove, C., Philippe, P., and U. Ulrich, 624 "The Optimized Link State Routing Protocol version 2", 625 work in progress draft-ietf-manet-olsrv2-14.txt, 626 March 2012. 628 [SMF] Macker, J., "Simplified Multicast Forwarding", work in 629 progress draft-ietf-manet-smf-14.txt, March 2012. 631 [broadcast-storm] 632 Ni, S., Tseng, Y., Chen, Y., and J. Sheu, "The Broadcast 633 Storm Problem in a Mobile Ad Hoc Network", Proceedings of 634 the 5th annual ACM/IEEE international conference on Mobile 635 computing and networking, 1999. 637 Authors' Addresses 639 Ulrich Herberg 640 Fujitsu Laboratories of America 641 1240 E Arques Ave 642 Sunnyvale, CA 94085 643 USA 645 Email: ulrich@herberg.name 646 URI: http://www.herberg.name/ 648 Jiazi Yi 649 LIX, Ecole Polytechnique 650 91128 Palaiseau Cedex, 651 France 653 Phone: +33 1 69 33 40 31 654 Email: jiazi@jiaziyi@com 655 URI: http://www.jiaziyi.com/ 657 Thomas Heide Clausen 658 LIX, Ecole Polytechnique 659 91128 Palaiseau Cedex, 660 France 662 Phone: +33 6 6058 9349 663 Email: T.Clausen@computer.org 664 URI: http://www.thomasclausen.org/