RFC 8116
Security Threats to the Optimized Link State Routing Protocol Version 2 (OLSRv2)
RFC 8116: Security Threats to the Optimized Link State Routing Protocol Version 2 (OLSRv2) 🦋
okay bestie, let's get into it 💅 this RFC is by T. Clausen, U. Herberg, and J. Yi (from Ecole Polytechnique), and it was published in May 2017. It's Informational 💜, so it's NOT a standards-track spec, just a "here's what's sus about this protocol" doc. It's listed as ISSN: 2070-1721 and it doesn't obsolete or update anything, so it's standing on its own ✨
Abstract ✨
so basically this doc looks at the common security threats to OLSRv2 (that's the Optimized Link State Routing Protocol version 2 🌸) and what those threats could do to Mobile Ad Hoc Network (MANET) operations. it also checks which of those vulnerabilities can be mitigated when you use the mandatory-to-implement security mechanisms for OLSRv2, and how that mitigation actually works 🔥
Status of This Memo ✨
this doc is not an Internet Standards Track spec, it's just published for info 🎀
it's a product of the Internet Engineering Task Force (IETF), so it reflects consensus of the IETF community 🫶 it got public review and was approved by the Internet Engineering Steering Group (IESG). not every IESG-approved doc is a candidate for an Internet Standard, so check Section 2 of RFC 7841 if you want the details 💅
for the latest status, errata, and feedback info, go to http://www.rfc-editor.org/info/rfc8116 🌈
Copyright Notice ✨
copyright (c) 2017 IETF Trust and the people listed as authors. all rights reserved 💖
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as of the publication date. read them, because they explain your rights and restrictions 🧚 code components pulled out of this doc must include Simplified BSD License text (Section 4.e of the Trust Legal Provisions) and come without warranty, as the Simplified BSD License describes ⭐
1. Introduction 🌸
okay so OLSRv2 [RFC7181] is the successor to OLSR [RFC3626] as a routing protocol for Mobile Ad Hoc Networks (MANETs) 🦋 it keeps the same basic algorithms as its predecessor, BUT it adds upgrades, like a modular and flexible architecture where extensions (security, for example) can be built as add-ons to the basic protocol. the building blocks and modules include [RFC5148], [RFC5444], [RFC5497], [RFC6130], [RFC7182], [RFC7183], [RFC7187], [RFC7188], [RFC7466], etc. 🧚
the developments in OLSRv2 came from real-world deployments, like FunkFeuer [FUNKFEUER], and from the requirements that keep these networks running well 💅 more people are joining these networks (FunkFeuer alone had roughly 400 individual participants when this doc was published), so assuming everyone will "behave" in a non-destructive way is just naive 💀 when networks reach the wider Internet and user numbers grow, attacks and abuses go up too, so recommended practices have to change. for example, SMTP servers that used to be open to everyone on the Internet now require authentication and accounting for users [RFC5068] 🙈
OLSRv2 is often used in wireless environments, so it can be exposed to security threats that matter more than they would on wired networks 🔥 radio signals can be received and transmitted by any compatible wireless device in range, so there usually aren't physical constraints on how nodes and links are arranged (unlike wired networks) 🌈
the first step toward hardening a network against attacks that disrupt its connectivity is understanding the vulnerabilities of the routing protocol that manages that connectivity 💖 so this doc analyzes OLSRv2 to understand its inherent vulnerabilities and resilience. the authors don't claim the analysis is complete, but they hope the attacks identified here make a meaningful starting point for building increasingly well-secured OLSRv2 networks 🫶
this doc describes OLSRv2's security vulnerabilities when it's used WITHOUT the mandatory-to-implement security mechanisms in Section 23.5 of [RFC7181] 👑 it also analyzes which of those vulnerabilities can be mitigated when you DO use those mandatory-to-implement security mechanisms, and how they get mitigated. this separation matters, because [RFC7181] explicitly says:
Any deployment of OLSRv2 SHOULD use the security mechanism specified in [RFC7183] but MAY use another mechanism if more appropriate in an OLSRv2 deployment. For example, for longer-term OLSRv2 deployments, alternative security mechanisms (e.g., rekeying) SHOULD be considered.
so basically [RFC7181] says deployments SHOULD use [RFC7183] but are allowed (MAY) to use something else if it fits better, and for longer-term deployments, other options like rekeying SHOULD be considered 🎀
also, this doc assumes NO extra security mechanism like IPsec is running at the IP layer, or other mechanisms on lower layers, because not every MANET deployment can handle that stuff (for example, MANET routers can have limited resources) 🍓
NHDP is a fundamental piece of OLSRv2, so the NHDP vulnerabilities discussed in [RFC7186] also apply to OLSRv2 ✨
lastly, lots of OLSRv2 implementations are configurable, so an attack on the configuration system (like [RFC7939] and [RFC7184]) can mess with how an OLSRv2 implementation runs 😭
1.1. OLSRv2 Overview 🧚
OLSRv2 has three basic processes: neighborhood discovery, Multipoint Relay (MPR) selection, and Link State Advertisements (LSAs) 🦋 they're described in the sections below with enough detail to follow the analysis in this doc.
1.1.1. Neighborhood Discovery 💜
neighborhood discovery is how each router finds out which routers are in direct radio range of itself (its 1-hop neighbors) and detects which of them it can actually have bidirectional communication with 🌸 each router sends HELLO messages periodically, listing the identifiers of all the routers it has recently received a HELLO from, plus the "status" of the link (heard or verified bidirectional).
here's the key bit: if router A gets a HELLO from neighbor B, and B says it's recently heard a HELLO from A, then A considers the A-B link bidirectional ✨ and since B lists all of ITS neighbors in its HELLO, A learns the "neighbors of its neighbors" (its 2-hop neighbors) too 🔥 HELLO messages go out periodically, but certain events can trigger non-periodic HELLOs 💅
OLSRv2 [RFC7181] uses NHDP [RFC6130] as its neighborhood discovery mechanism, and the NHDP vulnerabilities are analyzed in [RFC7186] 🫶
1.1.2. MPR Selection 🎀
MPR selection is how each router figures out a set of relays for efficiently doing network-wide broadcasts 🌈 each router picks, from its bidirectional neighbors, a subset (the "MPR set") so that an OLSRv2-specific multicast message sent by the router and relayed by the MPR set can reach ALL its 2-hop neighbors 👑 MPR selection gets encoded in outgoing NHDP HELLO messages 🦋
in their HELLO messages, routers can express their "willingness" to be picked as an MPR, using an integer from 0 to 7 ("will never" to "will always") 🧚 that willingness gets factored into the MPR calculation, and it's especially handy when an OLSRv2 network is "planned" ✨ the set of routers that picked a given router as an MPR is that router's MPR selector set 💖 and if you want to see a study of the MPR flooding algorithm, check [MPR-FLOODING] 🍓
(part 1 of 5, more coming next! 💅)
1.1.3. Link State Advertisement ✨
okay so Link State Advertisement (LSA) is basically how routers decide which link state info to shout out to the rest of the network 📣 Each router must advertise, at least, all links between itself and its MPR selectors so that every router can calculate shortest paths 🗺️ These LSAs ride inside Topology Control (TC) messages, and they get broadcast around the network using the MPR flooding process from Section 1.1.2. 💅 Since a router only picks MPRs from its bidirectional neighbors, the links advertised in TC are bidirectional too, so every routing path OLSRv2 calculates contains only bidirectional links. 🔗 TCs get sent periodically, but certain events can trigger non-periodic TCs as well ⏰
1.2. Link State Vulnerability Taxonomy 🕵️♀️
okay so proper OLSRv2 functioning assumes three things 🫶
- each router signals its presence in the network and the topology information that it obtained correctly;
- each router can acquire and maintain a topology map that accurately reflects the effective network topology; and,
- that the network converges, i.e., that all routers in the network will have sufficiently identical topology maps.
ngl this is where it gets spicy 🌶️ An OLSRv2 network can be disrupted by breaking any of these assumptions, specifically that (a) routers may be prevented from acquiring a topology map of the network, (b) routers may acquire a topology map that does not reflect the effective network topology, and (c) two or more routers may acquire inconsistent topology maps. 💀
1.3. OLSRv2 Attack Vectors 😈
besides "radio jamming", attacks on OLSRv2 consist of a compromised OLSRv2 router injecting apparently correct, but invalid, control traffic (TCs, HELLOs) into the network 🙈 A compromised OLSRv2 router can either (a) advertise erroneous information about itself (its identification and its willingness to serve as an MPR), henceforth called identity spoofing, or (b) advertise erroneous information about its relationship to other routers (pretend existence of links to other routers), henceforth called link spoofing. 🎭 These attacks can mess with the LSA process by targeting the MPR flooding mechanism or by causing incorrect link state information to be included in TCs, which leaves routers with incomplete, inaccurate, or inconsistent topology maps 😭
And then there's a whole different class of attacks 🔥 A compromised OLSRv2 router injects control traffic designed to cause an in-router resource exhaustion, e.g., by causing the algorithms calculating routing tables or MPR sets to be invoked continuously. That stops the internal state of a router from converging, and it drains the energy of battery-driven routers, etc. 🔋
2. Terminology 📖
this document uses the terminology and notation defined in [RFC5444], [RFC6130], and [RFC7181]. 🫶 It also defines the following terminology, bestie:
Compromised OLSRv2 router: an attacker that eavesdrops on the network traffic and/or generates syntactically correct OLSRv2 control messages. 👀 Control messages emitted by a compromised OLSRv2 router may contain additional information or omit information, as compared to a control message generated by a non-compromised OLSRv2 router located in the same topological position in the network. 🕵️
Legitimate OLSRv2 router: an OLSRv2 router that is not a compromised OLSRv2 router. 🌸
3. Topology Map Acquisition 🗺️
topology map acquisition is all about the ability of any given router in the network to acquire a representation of the network connectivity ✨ A router that is unable to acquire a topology map is incapable of calculating routing paths and participating in forwarding data, so it's a big deal 😬 Topology map acquisition can be hindered by (i) TCs not being delivered to (all) routers in the network, such as what happens in case of flooding disruption, or (ii) in case of "jamming" of the communication channel. 📡
The jamming and flooding disruption due to identity spoofing and link spoofing have been discussed in [RFC7186]. 📚
3.1. Attack on Jittering 🎲
OLSRv2 incorporates a jittering mechanism: a random, but bounded, delay on outgoing control traffic [RFC5148]. 🌀 This may be necessary when link layers (such as 802.11 [IEEE802.11]) are used that do not guarantee collision-free delivery of frames, and where jitter can reduce the probability of collisions of frames on lower layers. 💫
In OLSRv2, TC forwarding is jittered by a value between 0 and MAX_JITTER. 🎀 To reduce the number of transmissions, when a control message is due for transmission, OLSRv2 piggybacks all queued messages into a single transmission. 📦 So if a compromised OLSRv2 router sends many TCs within a very short time interval, the jitter time of the attacked router tends towards 0. 📉 This renders jittering ineffective and can lead to collisions on the link layer. 💥
In addition to causing more collisions, forwarding a TC with little or no jittering can make sure that the TC message forwarded by a compromised router arrives before the message forwarded by legitimate routers. 🏃♀️ The compromised router can thus inject malicious content in the TC: for example, if the message identification is spoofed, the legitimate message will be discarded as a duplicate message. 🙅♀️ This preemptive action is important for some of the attacks introduced in the following sections. 🦋
3.2. Hop Count and Hop Limit Attacks 🧚
the hop count and hop limit fields are the only parts of a TC that are modified when forwarding, so they are not protected by integrity check mechanisms 🫣 A compromised OLSRv2 router can modify either of these when forwarding TCs. 😈
3.2.1. Modifying the Hop Limit 🌈
A compromised OLSRv2 router can decrease the hop limit when forwarding a TC. 📉 This reduces the scope of forwarding for the message and may lead to some routers in the network not receiving that TC. Note that this is not necessarily the same as not relaying the message (i.e., setting the hop limit to 0), as is illustrated in Figure 1. 🖼️
.---.
| X |
--'---' __
/ \
/ \
.---. .---.
TC -----> | A | | C |
'---' '---'
\ .---. /
\-- | B |__/
'---'
Figure 1: Hop Limit AttackA TC arrives at and is forwarded by router A such that it is received by both B and the malicious X. 👀 X can forward the TC without any delay (including without jitter) such that its transmissions arrive before that of B at C. 🏎️ Before forwarding, it significantly reduces the hop limit of the message. 🤏 Router C receives the TC, processes (and forwards) it, and marks it as already received, causing it to discard further copies received from B. 🙃 Thus, if the TC is forwarded by C, it has a very low hop limit and will not reach the whole network. 💔
3.2.2. Modifying the Hop Count 🔢
A compromised OLSRv2 router can modify the hop count when forwarding a TC. 🪄 This may have two consequences: (i) if the hop count is set to the maximum value, then the TC will be forwarded no further or (ii) artificially manipulating the hop count may affect the validity time as calculated by recipients, when using distance-dependent validity times as defined in [RFC5497] (e.g., as part of a Fish Eye extension to OLSR2 [OLSR-FSR] [OLSR-FSR-Scaling]). 🐟
v_time(3hops)=9s v_time(4hops)=12s v_time(5hops)=15s
.---. .---. .---. .---.
| A |-- ... --> | B | -------> | X |---------->| C |
`---' `---' `---' `---'
Figure 2: Different Validity Times Based on the Distance in HopsIn Figure 2, router A sends a TC with a validity time of 9 seconds for routers in a 3-hop distance, 12 seconds for routers in a 4-hop distance, and 15 seconds in a 5-hop distance. ⏳ If X is a compromised OLSRv2 router and modifies the hop count (say, by decreasing it to 3), then C will calculate the validity time of received information to 9 seconds, after which it expires unless refreshed. 🫠 If TCs from A are sent less frequently than that up to 4 hops, this causes links advertised in such TCs to be only intermittently available to C. 🥺
4. Effective Topology 🧭
link state protocols assume that each router can acquire an accurate topology map that reflects the effective network topology 🗺️ This implies that the routing protocol is able to identify a path from a source to a destination, and that this path is valid for forwarding data traffic. 📬 If an attacker disturbs the correct protocol behavior, the perceived topology map of a router can permanently differ from the effective topology. 😱
Consider the example in Figure 3(a), which illustrates the topology map as acquired by router S. 🔍 This topology map indicates that the routing protocol has identified that for S, a path exists to D via B, which it therefore assumes can be used for transmitting data. 🛤️ If B does not forward data traffic from S, then the topology map in S does not accurately reflect the effective network topology. 🙈 Rather, the effective network topology from the point of view of S would be as indicated in Figure 3(b): D is not part of the network reachable from router S. 🥲
.---. .---. .---. .---. .---.
| S |----| B |----| D | | S |----| B |
`---' `---' `---' `---' `---'
(a) (b)
Figure 3: Incorrect Data Traffic ForwardingSome of the attacks related to NHDP, such as message timing attacks and indirect channel overloading, are discussed in [RFC7186]. ⏱️ Other threats specific to OLSRv2 are further detailed in this section. 🫶
4.1. Incorrect Forwarding 🚫
OLSRv2 routers exchange information using link-local transmissions (link-local multicast or limited broadcast) for their control messages, with the routing process in each router retransmitting received messages destined for network-wide diffusion. 📻 Thus, if the operating system in a router is not configured to enable forwarding, this will not affect the operation of the routing protocol or the topology map acquired by the routing protocol. 🤷♀️ It will, however, cause a discrepancy between the effective topology and the topology map, as indicated in Figures 3(a) and 3(b). 🙃
This situation is not hypothetical. 😭 A common error seen when deploying OLSRv2-based networks using a Linux-based computer as a router is to neglect enabling IP forwarding, which effectively becomes an accidental attack of this type. 💀🫶
4.2. Wormholes 🌀
Okay so bestie, picture this 👀 a wormhole (see Figure 4 💅) can get set up between two collaborating devices that are linked by an out-of-band channel. They shove traffic through the "tunnel" to their alter ego, which "replays" it on the other end. So routers D and S look like direct neighbors, reachable from each other in 1 hop through the tunnel, even though the path through the MANET is actually 100 hops long 🫣🌸
.---. .---.
| S |---- ....100-hop-long path ... ---| D |
`---. / `---'
\ /
\ /
\X=============================X
1-hop path via wormhole Figure 4: Wormholing between Two Collaborating Devices Not
Participating in the Routing ProtocolSo what happens to the network depends on how the wormhole actually behaves 🤔 If it relays only control traffic and not data traffic, the same considerations as in Section 4.1 apply ✨. But if it relays all traffic (control and data alike), it's connectivity-wise identical to a usable link 🔥. In that case the routing protocol will correctly generate a topology map that reflects the effective network topology 🗺️. How efficient that topology is depends on (i) the wormhole characteristics, (ii) how the wormhole presents itself, and (iii) how paths are calculated 🧠
Let's say paths get calculated with unit cost for all links, including the "link" the wormhole presents 💅 If the wormhole's real characteristics are as if it were a path of more than 100 hops (for example, in terms of delay, bandwidth, etc.), then having it around makes performance worse compared to the non-wormhole path 😭 On the flip side, if the "link" the wormhole presents has better characteristics, the wormhole actually improves performance 🦋
If paths are calculated with non-unit costs for all links, and the cost of the wormhole "link" correctly reflects the actual cost (say, because the cost was established through measurements across the wormhole), then the wormhole may, in the worst case, cause no degradation in performance 🫶 and in the best case, improve performance by offering a better path 🌈 If the wormhole's cost is misrepresented, then the same considerations as for unit-cost links apply 🙈
One more thing that's lowkey scary 😳 wormholes may present topologically attractive paths for the network, but it may be undesirable to have data traffic transit such a path. An attacker could, by introducing a wormhole, gain the ability to record and inspect transiting data traffic 💀
4.3. Sequence Number Attacks 🔢
OLSRv2 uses two different sequence numbers in TCs ✨ The first one (the Message Sequence Number) helps avoid processing and forwarding the same message more than once. The second one (the Advertised Neighbor Sequence Number (ANSN)) makes sure that old information, which might arrive late because of, e.g., long paths or other delays, isn't allowed to overwrite more recent information that was generated 🧚
4.3.1. Message Sequence Number
Here's the drama 🎭 An attack may consist of a compromised OLSRv2 router spoofing the identity of another router in the network and transmitting a large number of TCs, each with different Message Sequence Numbers. Any later TCs with the same sequence numbers that come from the router whose identity was spoofed would then get ignored 😤 until the information about those "spoofed" TCs eventually expires 🥀
4.3.2. Advertised Neighbor Sequence Number (ANSN)
Same energy, different sequence number 💅 An attack may consist of a compromised OLSRv2 router spoofing the identity of another router in the network and transmitting a single TC with an ANSN significantly larger than the one last used by the legitimate router. Routers will hold onto that bigger ANSN as "the most recent information," and then discard subsequent TCs with lower sequence numbers as being "old" 🫠 rude, honestly.
4.4. Indirect Jamming 📡
Indirect jamming is an attack where a compromised OLSRv2 router, just by what it does, gets legitimate routers to generate inordinate amounts of control traffic 😵💫 That means more channel occupation, and more overhead for each router to process all that control traffic 🔥 The sneaky part? This control traffic is originated by legitimate routers, so to the wider network, the malicious device may stay totally undetected 🕵️♀️
The general mechanism is that a malicious router participates in the protocol by generating plausible control traffic, and tunes that traffic so it triggers receiving routers to generate additional traffic in turn 🔁 For OLSRv2, this kind of indirect attack can be aimed at the neighborhood discovery mechanism and the LSA mechanism, respectively 🦋
One super efficient indirect jamming attack in OLSRv2 targets control traffic destined for network-wide diffusion 👑 Here's how it plays out, illustrated in Figure 5:
The malicious router X selects router A as an MPR at time t0 in a HELLO. This makes X appear as an MPR selector for A, so A sets X to be advertised in its "Neighbor Set" and increments the associated "Advertised Neighbor Sequence Number" (ANSN). Router A then has to advertise the link between itself and X in subsequent outgoing TCs (t1), also including the ANSN in those TCs. Once X receives that TC, it declares the link between itself and A as no longer valid (t2) in a HELLO, indicating the link to A as LOST. Since only symmetric links are advertised by OLSRv2 routers, A will (upon receiving this) remove X from the set of advertised neighbors and increment the ANSN. Router A then advertises the remaining set of advertised neighbors (i.e., with X removed) and the corresponding ANSN in subsequent TCs (t3). Once X has received this information in another TC from A, it may repeat the cycle, alternating between advertising the link A-X as "LOST" and as "MPR" 🔄
broadcast TC ANS={} TC:()
(X-A) ANSN ANSN++ ANSN
.---. .---. .---. .---.
| A | | A | | A | | A |
'---' '---' '---' '---'
^ | ^ |
| | | |
| select | |indicate |
| as MPR | |as LOST |
.---. .---. .---. .---.
| X | | X | | X | | X |
'---' '---' '---' '---'
t0 t1 t2 t3 Description: The malicious X flips between link status MPR and LOST.
Figure 5: Indirect Jamming in Link State AdvertisementRouters that receive a TC message will parse and process it, updating their topology map as a result of successful receipt 🧩 If the ANSN between two successive TCs from the same router has incremented, the topology has changed and routing sets need to be recalculated. That can be a computationally costly operation 🥵
A compromised OLSRv2 router may choose to run this attack against all of its neighbors 😈 which maxes out its disruptive impact on the network with relatively little overhead of its own. Apart from taking part in the neighborhood discovery procedure, the compromised router just monitors the TCs its neighbors generate and alternates the advertised status for each neighbor between "MPR" and "LOST." It indicates its willingness to be selected as an MPR as 0 (so it avoids being selected as an MPR), and it may ignore all other protocol operations while still being a very effective attacker 💀
Basic OLSRv2 operation uses periodic message emissions, and with this attack, it can be ensured that each of those periodic messages will trigger routing table recalculation in all routers in the network 🫨
If the routers in the network have "triggered TCs" enabled, this attack may also increase the TC frequency 📈 Triggered TCs exist so that a (stable) network can keep relatively low TC emission frequencies and still advertise link breakage or link emergence through the network quickly ⚡ To keep worst-case message emissions in check, a minimum message interval (typically much smaller than the regular periodic message interval) is imposed to rate-limit them 🚦
This attack can permanently force the TC interval to become equal to the minimum message interval 😱 [RFC7181] proposes as default that the minimum TC interval be 0.25 x TC_INTERVAL (TC_INTERVAL being the maximum interval between two TC messages from the same OLSRv2 router) 📏
So indirect jamming by a compromised OLSRv2 router can have two effects 🧨 (i) it may cause increased frequency of TC generation and transmission, and (ii) it will cause additional routing table recalculation in all routers in the network 🫠
5. Inconsistent Topology 🌀
Inconsistent topology maps can happen when a compromised OLSRv2 router uses either identity spoofing or link spoofing to attack an OLSRv2 network 🙃 The threats related to NHDP, like identity spoofing in NHDP, link spoofing in NHDP, and creating loops, have been illustrated in [RFC7186] 📚 This section mainly digs into the vulnerabilities in [RFC7181] 🔍
5.1. Identity Spoofing 🎀
Okay bestie, so identity spoofing can be pulled off by a compromised OLSRv2 router in two ways: through the neighborhood discovery process and through the LSA process 😭. Either one causes inconsistent topology maps in the routers across the network. The neighborhood discovery version has already been covered in [RFC7186]. For OLSRv2, the attack on the LSA process can also make the topology maps go inconsistent 💀.
An inconsistent topology map can happen when the compromised OLSRv2 router takes part in the LSA process by picking a neighbor as an MPR. That neighbor then advertises the spoofed identities of the compromised router. This attack alters the topology maps of every router in the network 🫠.
A -- B -- C -- D -- E -- F -- X
(X spoofs A)Description: A compromised OLSRv2 router X spoofs the identity of A, leading to a wrongly perceived topology.
Figure 6: Identity Spoofing
In Figure 6, router X spoofs the address of router A. If X selects F as an MPR, all routers in the network get told about the link F-A through the TCs originating from F 👀. Assuming the real A selects B as an MPR, the link B-A gets advertised across the network too.
When calculating paths, B and C will calculate paths to A via B, as shown in Figure 7(a). For these routers, the shortest path to A is via B. E and F will calculate paths to A via F, as shown in Figure 7(b). For these routers, the shortest path to A is via the compromised OLSRv2 router X, so they get disconnected from the real A 😤. D has a choice, because the path it calculates to A via B is the same length as the path via the compromised OLSRv2 router X, as shown in Figure 7(c).
In general, the following observations can be made:
- The network will be split in two. Routers closer to B than to X will reach A, whereas routers closer to X than to B will be unable to reach A.
- Routers beyond B, i.e., routers beyond 1 hop away from A, will be unable to detect this identity spoofing.
The identity spoofing attack through the LSA procedure has a bigger impact than the attack on the neighborhood discovery procedure, since it alters the topology maps of all routers in the network and not only the 2-hop neighborhood 🚨. The good news is that it's easier for other routers to catch. Since the compromised OLSRv2 router gets advertised across the whole network, the routers whose identities are being spoofed can detect the attack. For example, when A receives a TC from F advertising the link F-A, it can work out that some entity is injecting incorrect link state information, because F isn't one of its direct neighbors 🕵️♀️.
(X spoofs A)
A < ---- B < ---- C E ----> F ----> X
(a) Routers B and C (b) Routers E and F
A < --- B < --- C < --- D ---> E ---> F ----> X
(X spoofs A)Description: These paths appear as calculated by the different routers in the network in the presence of a compromised OLSRv2 router X, spoofing the address of A.
Figure 7: Routing Paths towards A
Here's the tricky part 🥺. The compromised OLSRv2 router X doesn't send the TCs itself. Instead, through MPR selection, it makes sure the addresses it spoofs get advertised in TCs from its MPR selector F. That's why the attack can be really hard to counter. Simply ignoring TCs that originate from F may also suppress the link state information from other, legitimate, MPR selectors of F.
So, identity spoofing by a compromised OLSRv2 router that takes part in the LSA process by selecting MPRs only creates a situation where two or more routers have substantially inconsistent topology maps. Traffic for an identified destination gets delivered to different routers depending on where in the network it shows up 🌀.
5.2. Link Spoofing 🦋
Link spoofing is when a router advertises links that don't exist to another router, which may not even be present in the network 👻. TCs and HELLOs both advertise links to direct neighbor routers. The only difference is how far the advertisement reaches. So link spoofing means a compromised OLSRv2 router reports that it has neighbor routers that either aren't in the network at all or aren't actually its neighbors.
It's worth noting that something similar to link spoofing can happen temporarily in an OLSR or OLSRv2 network with no compromised routers at all. If A was a neighbor of B but isn't anymore, A might still advertise a link to B for as long as it takes the neighborhood discovery process to figure out the neighborhood has changed 🔄.
In the context of this document, link spoofing refers to a persistent situation where a compromised OLSRv2 router deliberately advertises links to other routers that it is not a direct neighbor of 😈.
5.2.1. Inconsistent Topology Maps Due to Link State Advertisements
Figure 8 shows a network where the compromised OLSRv2 router X spoofs links to an existing router A. It does this by taking part in the LSA process and including the non-existent link in its advertisements 🍓.
A --- B --- C --- D --- E --- F --- G --- H --- X
(X spoofs the link to A)Description: The compromised OLSRv2 router X advertises a spoofed link to A in its TCs. As a result, all routers will record both the links X-A and B-A.
Figure 8: Link Spoofing
As TCs get flooded through the network, all routers receive and record information describing a link X-A in this link state information. If A has selected router B as an MPR, B will also flood this link state information through the network. So all routers will receive and record information describing a link B-A too 📡.
When calculating routing paths, B, C, and D will calculate paths to A via B, as shown in Figure 9(a). For these routers, the shortest path to A is via B. F and G will calculate paths to A via X, as shown in Figure 9(b). For these routers, the shortest path to A is via X, so they're cut off from the real router A 💔. E has a choice: the path it calculates to A via B is the same length as the path via X, as shown in Figure 9(c).
A < --- B < --- C < --- D F ---> G ---> X ---> A
(a) Routers B, C, and D (b) Routers F and G
A < --- B < --- C < --- D < --- E ---> F ---> G ---> X ---> A
(c) Router EDescription: These paths appear as calculated by the different routers in the network in the presence of a compromised OLSRv2 router X, spoofing a link to router A.
Figure 9: Routing Paths towards Router A
In general, the following observations can be made:
- The network will be separated in two. Routers closer to B than to X will reach A, whereas routers closer to X than to B will be unable to reach A.
- Routers beyond B, i.e., routers beyond 1 hop away from A, will be unable to detect this link spoofing.
6. Mitigation of Security Vulnerabilities for OLSRv2 🛡️
As described in Section 1, [RFC7183] specifies a security mechanism for OLSRv2 that is mandatory to implement. Deployments can still choose to use different security mechanisms if those fit better 💅. So it's important to understand two things: how resilient OLSRv2 is on its own against security vulnerabilities when the mechanisms in [RFC7183] aren't used, and how much protection [RFC7183] gives when it's used in a deployment ✨.
6.1. Inherent OLSRv2 Resilience 💖
OLSRv2, even when it's used without the mandatory-to-implement security mechanisms in [RFC7183], has some built-in resilience against part of the attacks described in this document 🫶. Specifically, it offers the following:
- Sequence numbers: OLSRv2 uses message sequence numbers, which are specific per router identity and message type. Routers keep an "information freshness" number (ANSN) that gets incremented each time the content of an LSA from a router changes. This lets routers reject both "old" information and duplicate messages, and it gives some protection against "message replay". However, this also presents an attack vector (Section 4.3) 😬.
- Ignoring unidirectional links: The neighborhood discovery process detects and admits only bidirectional links for use in MPR selection and LSA. Jamming attacks may affect only the reception of control traffic. Even so, OLSRv2 will correctly recognize and ignore a link that isn't bidirectional 🙅♀️.
- Message interval bounds: Control messages have a frequency limit, with minimum intervals imposed for HELLO and TCs. This may limit the impact of an indirect jamming attack (Section 4.4) ⏱️.
- Additional reasons for rejecting control messages: The OLSRv2 specification includes a list of reasons an incoming control message should be rejected as malformed. It also allows a protocol extension to recognize additional reasons for OLSRv2 to consider a message malformed. Together with the flexible message format [RFC5444], this allows adding security mechanisms, such as digital signatures, while still complying with the OLSRv2 standard specification 🌈.
6.2. Resilience by Using RFC 7183 with OLSRv2 👑
[RFC7183] specifies mechanisms for integrity and replay protection for NHDP and OLSRv2. It uses the generalized packet/message format described in [RFC5444] and the TLV definitions in [RFC7182] 🧚. The specification explains how to add an Integrity Check Value (ICV) in a TLV to each control message. This gives integrity protection for the content of the message, using Hashed Message Authentication Code (HMAC) / SHA-256. On top of that, a timestamp TLV is added to the message before the ICV is created, which enables replay protection of messages ⏰. The document specifies how to sign outgoing messages, how to verify incoming messages, and under which circumstances an invalid message is rejected.
Because the ICV uses HMAC/SHA-256, a shared key between all routers in the MANET is assumed 🔑. A router without valid credentials can't create an ICV that other routers can verify correctly. So an incorrectly signed message gets rejected by other MANET routers, and that router can't take part in the OLSRv2 routing process. In other words, the malicious router gets ignored by the legitimate routers 🚫.
[RFC7183] does not address the case where a router with valid credentials has been compromised 😱. Such a compromised router won't be kicked out of the routing process. If a deployment needs to detect such a router, other means are necessary. For example, an asymmetric key extension to [RFC7182] could allow revoking the access of one particular router 🔐.
In the following sections, each of the vulnerabilities described earlier in this document will be evaluated for whether OLSRv2 with the mechanisms in [RFC7183] provides sufficient protection against the attack. It is implicitly assumed in each of the following sections that [RFC7183] is used with OLSRv2 💜.
6.2.1. Topology Map Acquisition 🗺️
Attack on Jittering: okay so, only OLSRv2 routers with valid credentials can join the routing process 🔐, which means a malicious router can't drop the jitter time of an attacked router to 0 just by blasting a bunch of TC messages in a short time 🙈. The attacked router would reject all the incoming messages as "invalid" and not forward them 💀. Same deal if a malicious router tries to make sure its message arrives before the same message forwarded by legit routers by forcing a 0 jitter interval. Not happening, bestie 💅✨.
Modifying the Hop Limit and the Hop Count: the hop limit and hop count are not protected by [RFC7183], since they're mutable fields that change at every hop 😭, so this attack is still feasible 🥲. You can apply [RFC5444] packet-level protection by using the ICV Packet TLV defined in [RFC7182] to get hop-by-hop integrity protection 🛡️, but it comes at the expense of a requirement of pairwise trust between all neighbor routers 🫶. Trust is a whole vibe, so choose wisely 🌸.
6.2.2. Effective Topology 🧚
Incorrect Forwarding: only OLSRv2 routers with valid credentials can participate in the routing process, so a malicious router won't be part of the topology of other legitimate OLSRv2 routers 🙌. Therefore, no data traffic will be sent to the malicious router for forwarding. Main character energy for the good guys 👑.
Wormholes: a wormhole consists of at least two devices forwarding (unmodified) traffic 🕳️, so this attack is still feasible and undetectable by the OLSRv2 routing process 😵. Why? Because the attack doesn't involve the OLSRv2 protocol itself, it's happening down at the lower layers 🧱. By using [RFC7183], it can at least be assured that the content of the control messages is not modified while being forwarded via the wormhole 🔒. Moreover, the timestamp TLV assures that the forwarding can only be done in a short time window after the actual TC message has been sent ⏰. Tiny window, big energy ⚡.
Message Sequence Number: the message sequence number is included in the ICV calculation, so OLSRv2 is protected against this attack 🦋. Iconic.
Advertised Neighbor Sequence Number (ANSN): the ANSN is included in the ICV calculation, so OLSRv2 is protected against this attack 💜. Literally same energy as the sequence number, obsessed 😤.
Indirect Jamming: since the control messages of a malicious router will be rejected by other legitimate OLSRv2 routers in the MANET, this attack is mitigated 🌈✨.
6.2.3. Inconsistent Topology 🌀
Identity Spoofing: okay this one is a little messy 🙈. Since the control messages of a malicious router will be rejected by other legitimate OLSRv2 routers in the MANET, a router without valid credentials may spoof its identity (e.g., IP source address or message originator address), but the messages will be ignored by other routers 🙄. BUT, as the mandatory mechanism in [RFC7183] uses shared keys amongst all MANET routers, a single compromised router may spoof its identity and cause harm to the network stability 🚨. Removing this one malicious router, once detected, implies rekeying all other routers in the MANET 😩. Asymmetric keys, particularly when using identity-based signatures (such as those specified in [RFC7859]), may give the possibility of revoking single routers and verifying their identity based on the ICV itself 🔑. That's the glow-up we want 💖.
Link Spoofing: similar to identity spoofing, a malicious router without valid credentials may spoof links, but its control messages will be rejected by other routers, thereby mitigating the attack 🫧.
Inconsistent Topology Maps Due to LSAs: the same considerations for link spoofing apply 🔁.
6.3. Correct Deployment 🎀
Okay, real talk: implementing OLSRv2 with the right security mechanisms is only part of the story 📖. How you actually deploy the protocol matters just as much for it to work properly and for threats to get mitigated 💅. For example, Section 4.1 covered the considerations that come up with an incorrect forwarding-policy setting 🙃, and Section 4.2 covered the considerations for when intentional wormholes are present in a deployment 🕳️✨.
7. Security Considerations 🚨
This document doesn't specify a protocol or a procedure 📝. Instead, it reflects on the security considerations for OLSRv2 and for its constituent parts, including NHDP 🧩. It starts by analysing threats to topology map acquisition 🔍, with the assumption that no security mechanism is in use (including the mandatory-to-implement mechanisms from [RFC7182] and [RFC7183]) 😱. Then it moves on to discuss how the use of [RFC7182] and [RFC7183] mitigates the identified threats 🛡️.
🚨 Warning, bestie: when [RFC7183] is used with routers using a single shared key, the protection offered is not effective if a compromised router has valid credentials. Shared key, shared risk. Please don't skip this part 😭🙏.
8. References 📚
8.1. Normative References
[RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
Network (MANET) Neighborhood Discovery Protocol (NHDP)",
RFC 6130, DOI 10.17487/RFC6130, April 2011,
<http://www.rfc-editor.org/info/rfc6130>.
[RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
"The Optimized Link State Routing Protocol Version 2",
RFC 7181, DOI 10.17487/RFC7181, April 2014,
<http://www.rfc-editor.org/info/rfc7181>.
[RFC7186] Yi, J., Herberg, U., and T. Clausen, "Security Threats for
the Neighborhood Discovery Protocol (NHDP)", RFC 7186,
DOI 10.17487/RFC7186, April 2014,
<http://www.rfc-editor.org/info/rfc7186>.8.2. Informative References
[FUNKFEUER]
Funkfeuer, "Funkfeuer", <https://www.funkfeuer.at/>.
[IEEE802.11]
IEEE, "IEEE Standard for Information technology -
Telecommunications and information exchange between
systems Local and metropolitan area networks - Specfic
requirements Part 11: Wireless LAN Medium Access Control
and Physical (PHY) Specifications", IEEE Std 802.11-2016,
DOI 10.1109/IEEESTD.2016.7786995, December 2016.
[MPR-FLOODING]
Qayyum, A., Viennot, L., and A. Laouiti, "Multipoint
Relaying: An Efficient Technique for Flooding in Mobile
Wireless Networks", Proceedings of the 35th Annual Hawaii
International Conference on System Sciences (HICSS
'01), IEEE Computer Society, 2001.
[OLSR-FSR] Clausen, T., "Combining Temporal and Spatial Partial
Topology for MANET routing - Merging OLSR and FSR",
Proceedings of the 2003 IEEE Conference of Wireless
Personal Multimedia Communications (WPMC '03), 2003.
[OLSR-FSR-Scaling]
Adjih, C., Baccelli, E., Clausen, T., Jacquet, P., and G.
Rodolakis, "Fish Eye OLSR Scaling Properties", IEEE
Journal of Communication and Networks (JCN), Special Issue
on Mobile Ad Hoc Networks, December 2004.
[RFC3626] Clausen, T., Ed. and P. Jacquet, Ed., "Optimized Link
State Routing Protocol (OLSR)", RFC 3626,
DOI 10.17487/RFC3626, October 2003,
<http://www.rfc-editor.org/info/rfc3626>.
[RFC5068] Hutzler, C., Crocker, D., Resnick, P., Allman, E., and T.
Finch, "Email Submission Operations: Access and
Accountability Requirements", BCP 134, RFC 5068,
DOI 10.17487/RFC5068, November 2007,
<http://www.rfc-editor.org/info/rfc5068>.
[RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter
Considerations in Mobile Ad Hoc Networks (MANETs)",
RFC 5148, DOI 10.17487/RFC5148, February 2008,
<http://www.rfc-editor.org/info/rfc5148>.
[RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
"Generalized Mobile Ad Hoc Network (MANET) Packet/Message
Format", RFC 5444, DOI 10.17487/RFC5444, February 2009,
<http://www.rfc-editor.org/info/rfc5444>.
[RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value
Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497,
DOI 10.17487/RFC5497, March 2009,
<http://www.rfc-editor.org/info/rfc5497>.
[RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity
Check Value and Timestamp TLV Definitions for Mobile Ad
Hoc Networks (MANETs)", RFC 7182, DOI 10.17487/RFC7182,
April 2014, <http://www.rfc-editor.org/info/rfc7182>.
[RFC7183] 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 7183, DOI 10.17487/RFC7183, April 2014,
<http://www.rfc-editor.org/info/rfc7183>.
[RFC7184] Herberg, U., Cole, R., and T. Clausen, "Definition of
Managed Objects for the Optimized Link State Routing
Protocol Version 2", RFC 7184, DOI 10.17487/RFC7184, April
2014, <http://www.rfc-editor.org/info/rfc7184>.
[RFC7187] Dearlove, C. and T. Clausen, "Routing Multipoint Relay
Optimization for the Optimized Link State Routing Protocol
Version 2 (OLSRv2)", RFC 7187, DOI 10.17487/RFC7187, April
2014, <http://www.rfc-editor.org/info/rfc7187>.
[RFC7188] Dearlove, C. and T. Clausen, "Optimized Link State Routing
Protocol Version 2 (OLSRv2) and MANET Neighborhood
Discovery Protocol (NHDP) Extension TLVs", RFC 7188,
DOI 10.17487/RFC7188, April 2014,
<http://www.rfc-editor.org/info/rfc7188>.
[RFC7466] Dearlove, C. and T. Clausen, "An Optimization for the
Mobile Ad Hoc Network (MANET) Neighborhood Discovery
Protocol (NHDP)", RFC 7466, DOI 10.17487/RFC7466, March
2015, <http://www.rfc-editor.org/info/rfc7466>.
[RFC7859] Dearlove, C., "Identity-Based Signatures for Mobile Ad Hoc
Network (MANET) Routing Protocols", RFC 7859,
DOI 10.17487/RFC7859, May 2016,
<http://www.rfc-editor.org/info/rfc7859>.
[RFC7939] Herberg, U., Cole, R., Chakeres, I., and T. Clausen,
"Definition of Managed Objects for the Neighborhood
Discovery Protocol", RFC 7939, DOI 10.17487/RFC7939,
August 2016, <http://www.rfc-editor.org/info/rfc7939>.Authors' Addresses 🦋
Thomas Clausen
Phone: +33-6-6058-9349
Email: T.Clausen@computer.org
URI: http://www.thomasclausen.org
Ulrich Herberg
Email: ulrich@herberg.name
URI: http://www.herberg.name
Jiazi Yi
Ecole Polytechnique
91128 Palaiseau Cedex
France
Phone: +33 1 77 57 80 85
Email: jiazi@jiaziyi.com
URI: http://www.jiaziyi.com/📦 where this page comes from
- ietf: rfc8116 2017-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms