RFC 7186
Security Threats for the Neighborhood Discovery Protocol (NHDP)
RFC 7186: Security Threats for the Neighborhood Discovery Protocol (NHDP) 💖
okay so bestie, this is RFC 7186 and it's giving security analysis 🔍. It's an Informational doc, not a Standards Track spec 🎀. It was published in April 2014 under ISSN 2070-1721 🌸. The authors are J. Yi (LIX, Ecole Polytechnique), U. Herberg (Fujitsu Laboratories of America), and T. Clausen (LIX, Ecole Polytechnique) ✨. The header doesn't list anything it obsoletes or updates, so it's standing on its own 💅.
Internet Engineering Task Force (IETF) J. Yi
Request for Comments: 7186 LIX, Ecole Polytechnique
Category: Informational U. Herberg
ISSN: 2070-1721 Fujitsu Laboratories of America
T. Clausen
LIX, Ecole Polytechnique
April 2014Abstract ✨
this doc is all about the security threats that can hit NHDP and what those attacks do to MANET routing protocols that rely on NHDP 🧚. It's specifically NOT trying to fix any of them. It's just the "here's what goes wrong" breakdown 💀.
Status of This Memo 📜
okay so this one is informational only. It is not an Internet Standards Track specification 🦋.
It's an IETF product and represents the consensus of the IETF community 🫶. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is eligible for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious 🤓.
For errata, status updates, or to give feedback, go to http://www.rfc-editor.org/info/rfc7186 💌.
Copyright Notice ©️
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved 🌈.
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, as they read on the publication date (http://trustee.ietf.org/license-info). Please actually read those, bestie, because they spell out your rights and restrictions 📖. Any Code Components pulled out of this doc have to include the Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, same as that license says 🔥.
Table of Contents 🗂️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. NHDP Threat Overview . . . . . . . . . . . . . . . . . . . . 4
4. Detailed Threat Description . . . . . . . . . . . . . . . . . 5
4.1. Jamming . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Denial-of-Service Attack . . . . . . . . . . . . . . . . 5
4.3. Eavesdropping and Traffic Analysis . . . . . . . . . . . 6
4.4. Incorrect HELLO Message Generation . . . . . . . . . . . 7
4.4.1. Identity Spoofing . . . . . . . . . . . . . . . . . . 7
4.4.2. Link Spoofing . . . . . . . . . . . . . . . . . . . . 8
4.5. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 9
4.6. Message Timing Attacks . . . . . . . . . . . . . . . . . 9
4.6.1. Interval Time Attack . . . . . . . . . . . . . . . . 10
4.6.2. Validity Time Attack . . . . . . . . . . . . . . . . 10
4.7. Indirect Channel Overloading . . . . . . . . . . . . . . 10
4.8. Attack on Link Quality Update . . . . . . . . . . . . . . 11
5. Impact of Inconsistent Information Bases on Protocols using
NHDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. MPR Calculation . . . . . . . . . . . . . . . . . . . . . 12
5.1.1. Flooding Disruption due to Identity Spoofing . . . . 12
5.1.2. Flooding Disruption due to Link Spoofing . . . . . . 13
5.1.3. Broadcast Storm . . . . . . . . . . . . . . . . . . . 14
5.2. Routing Loops . . . . . . . . . . . . . . . . . . . . . . 15
5.3. Invalid or Nonexistent Paths to Destinations . . . . . . 16
5.4. Data Sinkhole . . . . . . . . . . . . . . . . . . . . . . 16
6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . 181. Introduction 🎀
okay so NHDP [RFC6130] lets routers learn about their topology up to two hops away, using periodic HELLO message exchanges 🫧. Other protocols use that info, like OLSRv2 [RFC7181] and Simplified Multicast Forwarding (SMF) [RFC6621]. NHDP keeps tabs on your local 1-hop and 2-hop neighborhood so the routing protocols can do their thing 👑.
NHDP is usually running over wireless, which means it's way more exposed to threats than wired networks are ⚡. Any compatible wireless device in range can receive and transmit radio signals, so there's basically no physical protection like you'd get with a cable 🙈. NHDP doesn't define any explicit security measures for protecting the integrity of the info it collects. It does suggest that integrity protection gets handled in a way that fits how the network is deployed 💅.
This doc assumes that no extra security mechanism like IPsec is running at the IP layer 🔐. Not every MANET can handle those common IP protections (for example, MANET routers can have limited resources) 🥺. The doc looks at possible attacks on NHDP and misconfigurations, and what those do to the state NHDP keeps in each router. That state is also what protocols using NHDP end up relying on 🧠.
Again, this doc is not trying to propose solutions 🙅♀️. [RFC7185] explains how to turn on integrity protection for NHDP, which can help with the identity spoofing threats 🛡️.
Heads up: lots of NHDP implementations are configurable, so an attack on the configuration system (such as [RFC6779]) can also mess with how NHDP runs 🚨.
The NHDP MIB module [RFC6779] might help you monitor some of the security attacks in this doc 📊. [MGMT-SNAP] is a snapshot of OLSRv2-routed MANET management as it's currently deployed 📸. [MANET-MGMT] is meant to give specific guidelines for MANET network management, covering the various MIB modules that have been written 🗺️.
2. Terminology 📚
this doc uses the terminology and notation from "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format" [RFC5444], "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)" [RFC6130], and "Internet Security Glossary, Version 2" [RFC4949] 🤓.
It also adds a few of its own terms:
- NHDP router: A MANET router that runs NHDP as specified in [RFC6130] 🛜.
- Attacker: A device that's present in the network and deliberately tries to compromise the information bases in NHDP routers 😈.
- Compromised NHDP router: An attacker that's present in the network and generates syntactically correct NHDP control messages. Control messages from a compromised NHDP router may include extra info, or leave info out, compared with what a non-compromised NHDP router in the same spot in the network would send 🫣.
- Legitimate NHDP router: An NHDP router that is not a compromised NHDP router ✅.
3. NHDP Threat Overview 🕵️♀️
NHDP defines a HELLO messages exchange, which lets each NHDP router learn topological info about its 1-hop and 2-hop neighbors. It also specifies the information bases where that info gets recorded 📝.
An NHDP router periodically sends HELLO messages using a link-local multicast on each of its interfaces, with a hop-limit of 1 (so HELLOs are never forwarded, bestie 🙅♀️). In these HELLOs, the router announces the IP addresses it has heard, along with its symmetric or lost neighbor interface addresses 📣.
An Attacker has several ways to mess with this neighbor discovery process. It can announce "wrong" info about its identity, make up nonexistent links, and replay HELLO messages 🫠. Section 4 goes into the details of each of these attacks.
Attacking an NHDP deployment can end up leaving the information bases inconsistent, so they don't accurately reflect the real topology of the MANET 🌀. That's a big deal because protocols using NHDP base their operation on bad info. Routing protocols might not be able to calculate correct paths (or any paths at all), and flooding based on reduced relay sets can get slower 🐌. Section 5 breaks down these consequences for protocols using NHDP.
4. Detailed Threat Description 🔎
For each threat, the doc describes how the attack works, then how it affects NHDP 🧩. The impacts of each attack on protocols using NHDP are in Section 5.
To keep things simple, the examples assume NHDP routers have a single interface with a single IP address configured 🫶. All the attacks still apply to NHDP routers with multiple interfaces and multiple addresses, though 💜.
4.1. Jamming 📡
okay so jamming is a vulnerability that every protocol running on a wireless ad hoc network shares 🚫. A device blasts a massive amount of interfering radio transmissions, which blocks legitimate traffic (both control traffic and data traffic) in part of the network. Jamming is a form of interference and overload, and its threat consequence is disruption [RFC4593] 😤.
Depending on the lower layers, transmissions might still get through. HELLO messages from an NHDP router with "jammed" interfaces can still be received by other NHDP routers 🙃. NHDP tells apart unidirectional and bidirectional links to a neighbor, so a routing protocol using NHDP for neighborhood discovery may ignore a link from a jammed NHDP router to a non-jammed NHDP router 🙈. The jammed router, which has a jammed carrier, just looks "disconnected" to the unjammed part of the network. That unjammed part can still keep accurate topology maps 🗺️✨.
Plot twist: if a lot of HELLO messages get lost or corrupted from collisions caused by a jamming attack, neighbor NHDP routers can't establish links with each other anymore 💀. So NHDP ends up presenting empty information bases to the protocols that use it 🫥.
4.2. Denial-of-Service Attack 💥
okay so a denial-of-service (DoS) attack can happen because of misconfiguration on a legit NHDP router (like a super short HELLO transmission interval, bestie 😭) or because a compromised NHDP router is acting up [ACCT2012], aka a so-called Byzantine router [RFC4593]. DoS is a form of interference and overload, and the threat consequence is disruption [RFC4593] 🫠.
By sending a HUGE pile of HELLO messages in a short amount of time, NHDP routers can eat up channel occupation, as described in Section 4.1 📡. And it gets worse: a compromised NHDP router can spoof a large number of different IP addresses and send HELLOs to its neighbors to fill up their Link/Neighbor Sets. This may cause a memory overflow, and then processing legit HELLO messages becomes impossible 💀. A compromised NHDP router can also use link spoofing in its HELLO messages to generate huge 2-hop Sets in adjacent NHDP routers, which could potentially mean a memory overflow too 🙈. Plus, protocols like SMF and OLSRv2 use the 2-hop information for multipoint relay (MPR) calculation, so they may run out of computational resources on the router if the Neighbor Set and 2-hop Sets have too many entries 🧮.
So basically, when a router runs out of memory, CPU, and/or channel resources (whether from a DoS attack or a misconfiguration), NHDP routers may not be able to do their jobs of exchanging 1-hop and 2-hop neighborhood information. That throws off the operation of any routing protocols using NHDP 😩.
In some MANETs, the routers are powered by battery. In those networks, a DoS attack has another nasty side effect: the power gets drained fast by unnecessary processing, transmitting, and receiving of messages 🔋⚡
4.3. Eavesdropping and Traffic Analysis 👀
Eavesdropping, sometimes called sniffing, is a common and easy passive attack in a wireless environment. Once a packet is transmitted, any adjacent NHDP router can potentially grab a copy for immediate or later processing. Neither the source nor the intended destination can detect this 🕵️♀️. A malicious NHDP router can eavesdrop on the NHDP message exchange and learn the local topology. It can also eavesdrop on data traffic to learn source and destination addresses of data packets, other header information, and the packet payload 📦.
Eavesdropping isn't a direct threat to the network or to NHDP, since it doesn't alter the information NHDP records in its information bases or presents to other protocols. HOWEVER, eavesdropping can hand over network information that enables other attacks, like the identity of communicating NHDP routers, link characteristics, and NHDP router configuration 🧩. Compromised NHDP routers may use that info to launch follow-up attacks, and they may also share NHDP routing information with other NHDP or non-NHDP entities. [RFC4593] would categorize the threat consequence as disclosure 🫣.
Traffic analysis normally follows eavesdropping. It's the process of intercepting messages in order to deduce information from communication patterns. It can still work even when HELLO messages are encrypted (and encryption is not part of NHDP), for example:
- Triggered HELLO messages: an attacker could figure out that messages are triggered and determine that there was a change of symmetric neighbors of an NHDP router sending the HELLO (as well get the frequency) 👀.
- Message size: the message grows exactly by x bytes per neighbor. Depending on which cipher is used for the encryption, some information about the size could be inferred, and thus the number of neighbors could be guessed 🔢.
[RFC4593] would categorize the threat consequence as disclosure.
4.4. Incorrect HELLO Message Generation 🎀
An NHDP router does two distinct tasks: it periodically generates HELLO messages, and it processes incoming HELLO messages from neighbor NHDP routers. This section covers security attacks involving HELLO generation 🫶.
4.4.1. Identity Spoofing 🎭
Identity spoofing means a compromised NHDP router sends HELLO messages pretending to be another NHDP router, or even a router that doesn't exist in the network. To pull this off, the compromised router uses an IP address that isn't its own in an address block of a HELLO message, and associates that address with a LOCAL_IF Address Block TLV [IJNSIA2010] 🥸.
An NHDP router that gets that HELLO from a neighbor will assume it came from the NHDP router with the spoofed interface address. So it adds a Link Tuple to that neighbor with the spoofed address, and includes it in its next HELLO messages as a heard neighbor (and possibly as a symmetric neighbor after another HELLO exchange) 😵💫.
Identity spoofing is especially harmful if a compromised NHDP router spoofs the identity of another NHDP router that exists in the same routing domain. With respect to NHDP, a duplicated, spoofed address like that can lead to an inconsistent state up to two hops away from an NHDP router. [RFC4593] would categorize the threat consequences as disclosure and deception 🚨.
Figure 1 shows a simple example. In it, NHDP router A is in radio range of NHDP router C, but not of the compromised NHDP router X. If X spoofs the address of A, that can cause conflicts for a routing protocol that uses NHDP, and therefore lead to wrong path calculations and incorrect data traffic forwarding 🗺️.
.---. .---. .---.
| A |----| C |----| X |
'---' '---' '---' Figure 1Figure 2 shows another example. Here, NHDP router A is two hops away from NHDP router C, reachable through NHDP router B. If the compromised NHDP router X spoofs the address of A, NHDP router D will take A as its 1-hop neighbor, and C may think A is indeed reachable through D 🤯.
.---. .---. .---. .---. .---.
| A |----| B |----| C |----| D |----| X |
'---' '---' '---' '---' '---' Figure 24.4.2. Link Spoofing 🕸️
Similar to identity spoofing, link spoofing means a compromised NHDP router sends HELLO messages signaling an incorrect set of neighbors. This is sometimes called falsification [RFC4593], and in NHDP it can take either of two forms:
- A compromised NHDP router can postulate addresses of non-present neighbor NHDP routers in an address block of a HELLO, associated with LINK_STATUS TLVs.
- A compromised NHDP router can "ignore" otherwise existing neighbors by not advertising them in its HELLO messages.
The effects of link spoofing on NHDP are twofold, depending on which of the two cases above is happening:
- If the compromised NHDP router ignores existing neighbors in its advertisements, links will be missing from the information bases maintained by other routers, and there may not be any connectivity for these NHDP routers to or from other NHDP routers in the MANET 🥲.
- On the other hand, if the compromised NHDP router advertises nonexistent links, this leads to topological information in the information base describing links that don't exist in the network. Other protocols using NHDP may then use those fake links in place of other, existing, links 👻.
[RFC4593] would categorize the threat consequences as usurpation, deception, and disruption.
4.5. Replay Attack 🔁
A replay attack means control traffic from one region of the network is recorded and replayed in a different region at (almost) the same time, or in the same region at a different time. This might happen when two compromised NHDP routers team up: one records traffic in its proximity and tunnels it to the other compromised NHDP router, which replays it. In a protocol where links are discovered by testing reception, this results in extraneous link creation. Basically, a "virtual" link between the two compromised NHDP routers will show up in the information bases of neighboring NHDP routers 🫣. [RFC4593] would categorize this as a falsification and interference threat, with threat consequences of usurpation, deception, and disruption.
BUT this situation doesn't always come from an attack. It can also be intentional: if data traffic is also relayed over the "virtual" link, the link being detected is actually valid for use. This is used in wireless repeaters, for instance 📶. If data traffic is NOT carried over the virtual link, then an imaginary, useless link between the two compromised NHDP routers has been advertised and is getting recorded in the information bases of their neighboring NHDP routers 🫠.
Compared to the incorrect HELLO message attacks described in Section 4.4, the messages used in replay attacks are legitimate messages sent out by (non-malicious) NHDP routers and replayed later, or from a different locality, by malicious routers. This makes this kind of attack harder to detect and counteract. Integrity checks can't help here, because the original message's Integrity Check Value (ICV) was calculated correctly 😤.
4.6. Message Timing Attacks ⏰
In NHDP, each HELLO message contains a "validity time" (the amount of time that information in that control message should be considered valid before being discarded) and may contain an "interval time" field (the amount of time until the next control message of the same type should be expected) [RFC5497] 🕰️.
4.6.1. Interval Time Attack 🐢
NHDP uses the expected interval between two successive HELLO messages to determine link quality. If messages don't arrive within the expected intervals (for example, a certain fraction of messages are missing), that can be used to exclude a link from being considered useful, even if (some) bidirectional communication has been verified 📉.
Here's how it goes: if a compromised NHDP router X spoofs the identity of an existing NHDP router A and sends HELLOs indicating a low interval time, an NHDP router B receiving this HELLO will expect the following HELLO to arrive within the interval time indicated. If that expectation isn't met, the link quality for the link A-B will decrease. So X can make NHDP router B's estimate of the link quality for the link A-B fall below the minimum considered useful, and the link wouldn't be used [CPSCOM2011]. [RFC4593] would categorize the threat consequence as usurpation 🥀.
4.6.2. Validity Time Attack ⌛
A compromised NHDP router X can spoof the identity of an NHDP router A and send a HELLO using a low validity time (e.g., 1 ms). A receiving NHDP router B will discard the information when that interval expires, meaning a link between NHDP routers A and B gets "torn down" by X 💥. Sending a low validity time can be caused by intended malicious behavior, or simply by misconfiguration in the NHDP routers. [RFC4593] would categorize the threat consequence as usurpation.
4.7. Indirect Channel Overloading 💅
Okay so Indirect Channel Overloading is when a compromised NHDP router X does sneaky stuff that makes other totally legit NHDP routers blast out an inordinate amount of control traffic 😭. That eats up channel occupation and piles extra overhead onto every receiving NHDP router that has to process all that traffic. And since the traffic is coming from legit routers, the malicious device can lowkey stay undetected in the wider network 🫣. It's a form of interference and overload, and the threat consequence is disruption [RFC4593] 💀.
Figure 3 shows how it goes down with NHDP 🎀. At t0, compromised NHDP router X advertises a symmetric spoofed link to the nonexistent NHDP router B. Router A picks X as its MPR as soon as it gets that HELLO, then triggers a HELLO at t1. The attacker overhears that triggered HELLO and sends another HELLO at t2, this time advertising the link to B as lost 🙃. Router A then deselects the attacker as its MPR and sends another triggered message at t3. The cycle can keep repeating, with the link X-B getting advertised alternately as LOST and SYM 🔁.
MPRs(X) MPRs()
.---. .---. .---. .---.
| A | | A | | A | | A |
'---' '---' '---' '---'
| | | |
| SYM(B) | | LOST(B) |
| | | |
.---. .---. .---. .---.
| X | | X | | X | | X |
'---' '---' '---' '---'
. .
. .
. .
..... .....
. B . . B .
..... .....
t0 t1 t2 t3
Figure 34.8. Attack on Link Quality Update 🌈
So according to NHDP [RFC6130], link quality is a whole mechanism that lets a router look at stuff besides message exchange when deciding whether a link is even a candidate to be HEARD or SYMMETRIC:
Link quality is a mechanism whereby a router MAY take considerations other than message exchange into account for determining when a link is and is not a candidate for being considered as HEARD or SYMMETRIC. As such, it is a "link admission" mechanism.
Section 14.4 of NHDP [RFC6130] then lists a few examples of what info can be used to update link quality ✨. One of them uses packet exchanges between neighbor routers (as described in [RFC5444]). For instance, an NHDP router might update a neighbor's link quality based on whether packets are received or lost, as long as those packets carry a sequential packet sequence number 🧠.
Here's the tea 🍵: NHDP doesn't normatively specify how to get link quality updates. Still, attack vectors can show up if an implementation chooses to calculate link quality from packet sequence numbers 👀. What the consequences look like depends on the specific implementation. For example, if the update is based on a sequential packet sequence number from neighbor routers, a compromised NHDP router can spoof packets that look like they came from another legit NHDP router, and that spoofed router skips some sequence numbers 🎭. The NHDP router receiving those spoofed packets may then degrade the link quality, because it looks like several packets got dropped. Eventually, it might remove the neighbor once the link quality falls below HYST_REJECT 😩.
5. Impact of Inconsistent Information Bases on Protocols using NHDP 🌸
This section is all about the fallout for protocols that use NHDP when NHDP fails to get and represent accurate info, possibly because of the attacks from Section 4 🥺. We're focusing on the MANET protocols OLSRv2 [RFC7181] and SMF [RFC6621], so buckle up 🎢.
5.1. MPR Calculation 🦋
MPR selection (as used in [RFC7181] and [RFC6621], for example) relies on info about a router's 1-hop and 2-hop neighborhood. It assumes that (i) this info is accurate, and (ii) each 1-hop neighbor is apt to act as MPR, depending on the willingness it reports 🤞. So a compromised NHDP router can mess with the 1-hop and 2-hop neighborhood info in a router to make MPR selection fail. That can lead to a flooding disruption of traffic control messages 🚫. The result could be an incomplete topology advertisement, or optimized flooding getting degraded all the way back to classical flooding 📉.
5.1.1. Flooding Disruption due to Identity Spoofing 🎭
A compromised NHDP router can spoof the identity of other routers to disrupt MPR selection, so that certain parts of the network stop getting flooded traffic [IJNSIA2010] 😤.
In Figure 4, compromised NHDP router X spoofs the identity of B. The link between X and C is correctly detected and listed in X's HELLOs. Router A receives HELLOs indicating links from B:{B-E}, X:{X-C, X-E}, and D:{D-E, D-C}, respectively. For router A, X and D are equal candidates for MPR selection. To make sure X gets picked as MPR for router A, X can set its willingness to the maximum value 💪.
.---. .---. .---.
| E |----| D |----| C |
'---' '---' '---'
| | .
| | .
.---. .---. .---.
| B |----| A |----| X |
'---' '---' '---'
spoofs B
Figure 4If B and X (i) accept MPR selection and (ii) forward flooded traffic as if they were both B, the identity spoofing by X is harmless 😌. But if X doesn't forward flooded traffic (i.e., it doesn't accept MPR selection), its presence causes flooding disruption. Selecting B over D makes C unreachable by flooded traffic 🚧.
.---.
| D |
'---'
|
|
.---. .---. .---. .---. .---.
| X |----| A |----| B |----| C |----| E |...
'---' '---' '---' '---' '---'
spoofs E
Figure 5In Figure 5, the compromised NHDP router X spoofs the identity of E. That means routers A and C both get HELLOs from a router identifying itself as E 👻. For router B, routers A and C present the same neighbor sets and are equal candidates for MPR selection. If router B selects only router A as MPR, then C won't relay flooded traffic from B or traffic transiting via B. Router X (and the routers to the "right" of it) won't receive flooded traffic at all 😱.
5.1.2. Flooding Disruption due to Link Spoofing 🕸️
A compromised NHDP router can also spoof links to other NHDP routers. That makes it look like the most appealing MPR candidate for its neighbors, possibly leaving out all the other NHDP routers in the neighborhood 💅. (This can especially happen if the compromised NHDP router spoofs links to all other NHDP routers in the neighborhood, plus one NHDP router outside the neighborhood.) By shutting out other legit NHDP routers from being selected as MPR, the compromised router ends up receiving, and being expected to relay, all the flooded traffic (like traffic control messages in OLSRv2 or data traffic in SMF). Then it can drop that traffic or manipulate it however it wants 👀.
In the network in Figure 6, compromised NHDP router X spoofs links to the existing router C, as well as to a fictitious W. Router A receives HELLOs from X and B, reporting X: {X-C, X-W} and B: {B-C}. All else being equal, X looks like a better MPR choice than B, since X seems to cover all of B's neighbors plus W 🫠.
,---. .....
| S | . C .
'---' .....
| .
| .
.---. .---. .---. .---. .---.
| D |----| C |----| B |----| A |----| X |
'---' '---' '---' '---' '---'
.
.
.....
. W .
.....
Figure 6Since router A won't select B as MPR, B won't relay flooded messages it gets from router A. The NHDP routers on the left of B (starting with C) therefore won't receive any flooded messages from router A, or from any router transiting through A (for example, a message originating from S) 🥲.
5.1.3. Broadcast Storm 🌪️
A compromised NHDP router may attack the network by trying to degrade the performance of optimized flooding algorithms until they're equivalent to classic flooding 😈. It can do this by forcing an NHDP router to choose all of its 1-hop neighbors as MPRs. In MANETs, a broadcast storm caused by classic flooding is a seriously big problem that can cause redundancy, contention, and collisions [MOBICOM99] 🚨.
As shown in Figure 7, compromised NHDP router X spoofs the identity of NHDP router B and also spoofs a link to router Y {B-Y} (Y doesn't have to exist). Because of that, the legitimate NHDP router A has to select the legitimate NHDP router B as its MPR so it can reach all of its 2-hop neighbors. The compromised NHDP router Y can do this identity-and-link spoofing for all of NHDP router A's 1-hop neighbors. That forces NHDP router A to select all of its neighbors as MPRs, which switches off the optimization the MPR mechanism is supposed to give 🙅.
.---.
| B |
'---'
|
|
.---. .---. .....
| A |----| X | . . . Y .
'---' '---' .....
spoofs B
Figure 75.2. Routing Loops 🔁
Inconsistent information bases that NHDP hands off to other protocols can also cause routing loops 😵💫. In Figure 8, compromised NHDP router X spoofs the identity of NHDP router E. NHDP router D has data traffic to send to NHDP router A. The topology recorded in router D's information base says the shortest path to router A is {D->E->A}, because of the link {A-E} that X reported. So the data traffic gets routed to NHDP router E. But the link {A-E} doesn't exist in NHDP router E's information bases, so E identifies the next hop for data traffic to NHDP router A as NHDP router D. Boom, a loop between NHDP routers D and E is created 🌀.
.---. .---. .---. .---. .---.
| A |----| B |----| C |----| D |----| E |
'---' '---' '---' '---' '---'
|
|
.---.
| X |
'---'
spoofs E
Figure 85.3. Invalid or Nonexistent Paths to Destinations 🚫
By reporting inconsistent topology info in NHDP, invalid links and routers can get propagated as link state information along with traffic control messages, and that results in route failure 💔. As Figure 8 illustrates, if NHDP router B tries to send data packets to NHDP router E, it will choose router A as its next hop. That's based on the info about the nonexistent link {A-E} that the compromised NHDP router X reported 🤦♀️.
5.4. Data Sinkhole 🕳️
With the ability to spoof multiple identities of legitimate NHDP routers (by eavesdropping, for example), a compromised NHDP router can act as a "data sinkhole" for its 1-hop and 2-hop neighbors 🌊. Data packets coming across its neighbors may get forwarded to the compromised NHDP router instead of the real destination. Then the packet can be dropped, manipulated, duplicated, and so on by the compromised NHDP router 😭. As shown in Figure 8, if the compromised NHDP router X spoofs the identity of NHDP router E, all the data packets to E that cross NHDP routers A and B will be sent to NHDP router X instead of to E 🙈.
6. Future Work 🔮
okay bestie, so this doc doesn't actually propose fixes for the threats in Section 4 😤 but this section is basically a to-do list for future work, pointing at which of those threats could be tackled by deployments or applications 💅
- Section 4.1: Jamming 📡 If a single router or a small area of the MANET gets jammed, protocols could be specified that increase link metrics in NHDP for the jammed links. When a routing protocol such as OLSRv2 uses NHDP for neighborhood discovery, other paths leading "around" the jammed area would be preferred, and that would mitigate the threat to some extent 🫶
- Section 4.2: DoS 🚨 A DoS attack using a massive amount of HELLO messages can be mitigated by only admitting trusted routers to the network. [RFC7185] specifies a mechanism for adding Integrity Check Values (ICVs) to HELLO messages, which gives NHDP routers an admittance mechanism for joining a MANET. (Note that adding ICVs creates a new DoS attack vector, since ICV verification requires CPU and memory resources. 💀) However, using ICVs does not address the problem of compromised routers. Detecting compromised routers could be addressed in new work. [RFC7185] mandates implementation of a security mechanism that is based on shared keys and makes excluding single compromised routers difficult. Work could be done to facilitate revocation mechanisms in certain MANET use cases where routers have sufficient capabilities to support asymmetric keys 🔑
- Section 4.3: Eavesdropping 👀 [RFC7185] adds ICVs to HELLO messages but does not encrypt them, so eavesdropping of control traffic is not mitigated. Future work could provide encryption of control traffic for sensitive MANET topologies. Note that, other than using a single shared secret key, providing encryption of traffic among a set of neighbors (when that set is potentially undetermined) is nontrivial, especially without multiplying overheads 😩 With traffic analysis, attackers could still deduce network information like HELLO message triggering and HELLO message size, even though the HELLO messages are encrypted 🙈
- Section 4.4.2: Link spoofing 🎭 [RFC7185] provides certain protection against link spoofing, but an NHDP router has to "trust" the originator of a HELLO that the advertised links are correct. For example, if a router A reports a link to B, routers receiving HELLOs from A have to trust that B is actually a (symmetric) neighbor of A. New protocol work could address protection of links without overly increasing the space and time overheads ✨ An immediate suggestion for deployments is to protect routers against being compromised and to distribute keys only to trusted routers 🛡️
- Section 4.5: Replay Attacks 🔁 [RFC7185] uses ICVs and timestamps to provide some protection against replay attacks, but it is still feasible to replay control messages within a limited time. A suggestion for deployments is to provide time synchronization between routers ⏰ New work could provide time synchronization mechanisms for certain MANET use cases, or specify a mechanism using nonces instead of timestamps in HELLO messages 🧚
- Section 4.4.1: Identity spoofing; Section 4.6: Message timing attacks; Section 4.7: Indirect channel overloading; and Section 4.8: Attack on link quality update 🎀 [RFC7185] provides protection against these attacks, assuming the routers are not compromised. Iconic, honestly 👑
7. Security Considerations 🔐
okay this part is SO serious and I'm not going to pretend otherwise 😭 This document doesn't specify a protocol or a procedure. It does, however, reflect on security considerations for NHDP and for MANET routing protocols that use NHDP for neighborhood discovery. Read the whole thing before you build anything, bestie 🫶
8. Acknowledgments 🌸
The authors want to give a huge thank you 💖 to the following people for valuable comments and technical discussions: Teco Boot, Henning Rogge, Christopher Dearlove, John Dowdell, Joseph Macker, and all the other participants of the IETF MANET working group. You all ate 🍓
9. References 📚
9.1. Normative References
[RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
"Generalized Mobile Ad Hoc Network (MANET) Packet/Message
Format", RFC 5444, February 2009.
[RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value
Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, March
2009.
[RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
Network (MANET) Neighborhood Discovery Protocol (NHDP)",
RFC 6130, April 2011.9.2. Informative References
[ACCT2012] Jhaveri, R. and S. Patel, "DoS Attacks in Mobile Ad Hoc
Networks: A Survey", Second International Conference on
Advanced Computing & Communication Technologies (ACCT),
January 2012.
[CPSCOM2011]
Yi, J., Clausen, T., and U. Herberg, "Vulnerability
Analysis of the Simple Multicast Forwarding (SMF) Protocol
for Mobile Ad Hoc Networks", Proceedings of the IEEE
International Conference on Cyber, Physical, and Social
Computing (CPSCom), October 2011.
[IJNSIA2010]
Herberg, U. and T. Clausen, "Security Issues in the
Optimized Link State Routing Protocol version 2",
International Journal of Network Security & Its
Applications, April 2010.
[MANET-MGMT]
Nguyen, J., Cole, R., Herberg, U., Yi, J., and J. Dean,
"Network Management of Mobile Ad hoc Networks (MANET):
Architecture, Use Cases, and Applicability", Work in
Progress, February 2013.
[MGMT-SNAP]
Clausen, T. and U. Herberg, "Snapshot of OLSRv2-Routed
MANET Management", Work in Progress, February 2014.
[MOBICOM99]
Ni, S., Tseng, Y., Chen, Y., and J. Sheu, "The Broadcast
Storm Problem in a Mobile Ad Hoc Network", Proceedings of
the 5th annual ACM/IEEE international conference on Mobile
computing and networking, 1999.
[RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to
Routing Protocols", RFC 4593, October 2006.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC
4949, August 2007.
[RFC6621] Macker, J., "Simplified Multicast Forwarding", RFC 6621,
May 2012.
[RFC6779] Herberg, U., Cole, R., and I. Chakeres, "Definition of
Managed Objects for the Neighborhood Discovery Protocol",
RFC 6779, October 2012.
[RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
"The Optimized Link State Routing Protocol Version 2", RFC
7181, April 2014.
[RFC7185] Herberg, U., Dearlove, C., and T. Clausen, "Integrity
Protection for the Neighborhood Discovery Protocol (NHDP)
and Optimized Link State Routing Protocol Version 2
(OLSRv2)", RFC 7185, April 2014.Authors' Addresses 💌
Jiazi Yi
LIX, Ecole Polytechnique
91128 Palaiseau Cedex
France
Phone: +33 1 77 57 80 85
EMail: jiazi@jiaziyi.com
URI: http://www.jiaziyi.com/
Ulrich Herberg
Fujitsu Laboratories of America
1240 E Arques Ave
Sunnyvale, CA 94085
USA
EMail: ulrich@herberg.name
URI: http://www.herberg.name/
Thomas Heide Clausen
LIX, Ecole Polytechnique
91128 Palaiseau Cedex
France
Phone: +33 6 6058 9349
EMail: T.Clausen@computer.org
URI: http://www.thomasclausen.org/That's the whole RFC, bestie 🌈✨ You made it!
📦 where this page comes from
- ietf: rfc7186 2014-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms