From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8116.txt | 1459 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1459 insertions(+) create mode 100644 doc/rfc/rfc8116.txt (limited to 'doc/rfc/rfc8116.txt') diff --git a/doc/rfc/rfc8116.txt b/doc/rfc/rfc8116.txt new file mode 100644 index 0000000..c79a4cc --- /dev/null +++ b/doc/rfc/rfc8116.txt @@ -0,0 +1,1459 @@ + + + + + + +Internet Engineering Task Force (IETF) T. Clausen +Request for Comments: 8116 +Category: Informational U. Herberg +ISSN: 2070-1721 + J. Yi + Ecole Polytechnique + May 2017 + + + Security Threats to the + Optimized Link State Routing Protocol Version 2 (OLSRv2) + +Abstract + + This document analyzes common security threats to the Optimized Link + State Routing Protocol version 2 (OLSRv2) and describes their + potential impacts on Mobile Ad Hoc Network (MANET) operations. It + also analyzes which of these security vulnerabilities can be + mitigated when using the mandatory-to-implement security mechanisms + for OLSRv2 and how the vulnerabilities are mitigated. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc8116. + + + + + + + + + + + + + + + +Clausen, et al. Informational [Page 1] + +RFC 8116 OLSRv2 Threats May 2017 + + +Copyright Notice + + Copyright (c) 2017 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Clausen, et al. Informational [Page 2] + +RFC 8116 OLSRv2 Threats May 2017 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1. OLSRv2 Overview . . . . . . . . . . . . . . . . . . . . . 5 + 1.1.1. Neighborhood Discovery . . . . . . . . . . . . . . . 5 + 1.1.2. MPR Selection . . . . . . . . . . . . . . . . . . . . 6 + 1.1.3. Link State Advertisement . . . . . . . . . . . . . . 6 + 1.2. Link State Vulnerability Taxonomy . . . . . . . . . . . . 6 + 1.3. OLSRv2 Attack Vectors . . . . . . . . . . . . . . . . . . 7 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 3. Topology Map Acquisition . . . . . . . . . . . . . . . . . . 7 + 3.1. Attack on Jittering . . . . . . . . . . . . . . . . . . . 8 + 3.2. Hop Count and Hop Limit Attacks . . . . . . . . . . . . . 8 + 3.2.1. Modifying the Hop Limit . . . . . . . . . . . . . . . 8 + 3.2.2. Modifying the Hop Count . . . . . . . . . . . . . . . 9 + 4. Effective Topology . . . . . . . . . . . . . . . . . . . . . 10 + 4.1. Incorrect Forwarding . . . . . . . . . . . . . . . . . . 10 + 4.2. Wormholes . . . . . . . . . . . . . . . . . . . . . . . . 11 + 4.3. Sequence Number Attacks . . . . . . . . . . . . . . . . . 12 + 4.3.1. Message Sequence Number . . . . . . . . . . . . . . . 12 + 4.3.2. Advertised Neighbor Sequence Number (ANSN) . . . . . 12 + 4.4. Indirect Jamming . . . . . . . . . . . . . . . . . . . . 12 + 5. Inconsistent Topology . . . . . . . . . . . . . . . . . . . . 15 + 5.1. Identity Spoofing . . . . . . . . . . . . . . . . . . . . 15 + 5.2. Link Spoofing . . . . . . . . . . . . . . . . . . . . . . 17 + 5.2.1. Inconsistent Topology Maps Due to Link State + Advertisements . . . . . . . . . . . . . . . . . . . 18 + 6. Mitigation of Security Vulnerabilities for OLSRv2 . . . . . . 19 + 6.1. Inherent OLSRv2 Resilience . . . . . . . . . . . . . . . 19 + 6.2. Resilience by Using RFC 7183 with OLSRv2 . . . . . . . . 20 + 6.2.1. Topology Map Acquisition . . . . . . . . . . . . . . 21 + 6.2.2. Effective Topology . . . . . . . . . . . . . . . . . 21 + 6.2.3. Inconsistent Topology . . . . . . . . . . . . . . . . 22 + 6.3. Correct Deployment . . . . . . . . . . . . . . . . . . . 22 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 23 + 8.2. Informative References . . . . . . . . . . . . . . . . . 23 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 + + + + + + + + + + + + +Clausen, et al. Informational [Page 3] + +RFC 8116 OLSRv2 Threats May 2017 + + +1. Introduction + + The Optimized Link State Routing Protocol version 2 (OLSRv2) + [RFC7181] is a successor to OLSR [RFC3626] as a routing protocol for + Mobile Ad Hoc Networks (MANETs). OLSRv2 retains the same basic + algorithms as its predecessor; however, it offers various + improvements, e.g., a modular and flexible architecture allowing + extensions (such as for security) to be developed as add-ons to the + basic protocol. Such building blocks and modules include [RFC5148], + [RFC5444], [RFC5497], [RFC6130], [RFC7182], [RFC7183], [RFC7187], + [RFC7188], [RFC7466], etc. + + The developments reflected in OLSRv2 have been motivated by increased + real-world deployment experiences, e.g., from networks such as + FunkFeuer [FUNKFEUER], and the requirements to be addressed for + continued successful operation of these networks. With participation + in such networks increasing (the FunkFeuer community network has, + e.g., roughly 400 individual participants at the time of publication + of this document), operating under the assumption that participants + can be "trusted" to behave in a non-destructive way, is naive. With + deployment in the wider Internet, and a resultant increase in user + numbers, an increase in attacks and abuses has followed necessitating + a change in recommended practices. For example, SMTP servers, which + were initially available for use by everyone on the Internet, require + authentication and accounting for users today [RFC5068]. + + As OLSRv2 is often used in wireless environments, it is potentially + exposed to different kinds of security threats, some of which are of + greater significance when compared to wired networks. As radio + signals can be received as well as transmitted by any compatible + wireless device within radio range, there are commonly no physical + constraints on the conformation of nodes and communication links that + make up the network (as could be expected for wired networks). + + A first step towards hardening against attacks disrupting the + connectivity of a network is to understand the vulnerabilities of the + routing protocol managing the connectivity. Therefore, this document + analyzes OLSRv2 in order to understand its inherent vulnerabilities + and resilience. The authors do not claim completeness of the + analysis but hope that the identified attacks, as presented, form a + meaningful starting point for developing and deploying increasingly + well-secured OLSRv2 networks. + + This document describes security vulnerabilities of OLSRv2 when it is + used without the mandatory-to-implement security mechanisms, as + specified in Section 23.5 of [RFC7181]. It also analyzes which of + these security vulnerabilities can be mitigated when using the + mandatory-to-implement security mechanisms for OLSRv2 and how the + + + +Clausen, et al. Informational [Page 4] + +RFC 8116 OLSRv2 Threats May 2017 + + + vulnerabilities are mitigated. This separation is important since, + as explicitly stated in [RFC7181]: + + 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. + + Moreover, this document is also based on the assumption that no + additional security mechanism such as IPsec is used in the IP layer, + or other mechanisms on lower layers, as not all MANET deployments may + be able to accommodate such common protection mechanisms (e.g., + because of limited resources of MANET routers). + + As NHDP is a fundamental component of OLSRv2, the vulnerabilities of + NHDP, discussed in [RFC7186], also apply to OLSRv2. + + It should be noted that many OLSRv2 implementations are configurable, + and so an attack on the configuration system (such as [RFC7939] and + [RFC7184]) can be used to adversely affect the operation of an OLSRv2 + implementation. + +1.1. OLSRv2 Overview + + OLSRv2 contains three basic processes: neighborhood discovery, + Multipoint Relay (MPR) selection, and Link State Advertisements + (LSAs). They are described in the sections below with sufficient + details to allow elaboration of the analyses in this document. + +1.1.1. Neighborhood Discovery + + Neighborhood discovery is the process whereby each router discovers + the routers that are in direct communication range of itself (1-hop + neighbors) and detects with which of these it can establish + bidirectional communication. Each router sends HELLO messages + periodically, listing the identifiers of all the routers from which + it has recently received a HELLO message as well as the "status" of + the link (heard or verified bidirectional). A router A receiving a + HELLO message from a neighbor router B, in which B indicates it has + recently received a HELLO message from A, considers the link A-B to + be bidirectional. As B lists identifiers of all its neighbors in its + HELLO message, A learns the "neighbors of its neighbors" (2-hop + neighbors) through this process. HELLO messages are sent + periodically; however, certain events may trigger non-periodic + HELLOs. OLSRv2 [RFC7181] uses NHDP [RFC6130] as its neighborhood + discovery mechanism. The vulnerabilities of NHDP are analyzed in + [RFC7186]. + + + +Clausen, et al. Informational [Page 5] + +RFC 8116 OLSRv2 Threats May 2017 + + +1.1.2. MPR Selection + + Multipoint Relay (MPR) selection is the process whereby each router + is able to identify a set of relays for efficiently conducting + network-wide broadcasts. Each router designates, from among its + bidirectional neighbors, a subset (the "MPR set") such that an + OLSRv2-specific multicast message transmitted by the router and + relayed by the MPR set can be received by all its 2-hop neighbors. + MPR selection is encoded in outgoing NHDP HELLO messages. + + In their HELLO messages, routers may express their "willingness" to + be selected as an MPR using an integer between 0 and 7 ("will never" + to "will always"). This is taken into consideration for the MPR + calculation and is useful, for example, when an OLSRv2 network is + "planned". The set of routers having selected a given router as an + MPR is the MPR selector set of that router. A study of the MPR + flooding algorithm can be found in [MPR-FLOODING]. + +1.1.3. Link State Advertisement + + Link State Advertisement (LSA) is the process whereby routers + determine which link state information to advertise through the + network. Each router must advertise, at least, all links between + itself and its MPR selectors in order to allow all routers to + calculate shortest paths. Such LSAs are carried in Topology Control + (TC) messages, which are broadcast through the network using the MPR + flooding process described in Section 1.1.2. As a router selects + MPRs only from among bidirectional neighbors, links advertised in TC + are also bidirectional and routing paths calculated by OLSRv2 contain + only bidirectional links. TCs are sent periodically; however, + certain events may trigger non-periodic TCs. + +1.2. Link State Vulnerability Taxonomy + + Proper functioning of OLSRv2 assumes that: + + o each router signals its presence in the network and the topology + information that it obtained correctly; + + o each router can acquire and maintain a topology map that + accurately reflects the effective network topology; and, + + o that the network converges, i.e., that all routers in the network + will have sufficiently identical topology maps. + + 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 + + + +Clausen, et al. Informational [Page 6] + +RFC 8116 OLSRv2 Threats May 2017 + + + 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. Such attacks may + disrupt the LSA process by targeting the MPR flooding mechanism or by + causing incorrect link state information to be included in TCs, + causing routers to have incomplete, inaccurate, or inconsistent + topology maps. In a different class of attacks, a compromised OLSRv2 + router injects control traffic designed so as to cause an in-router + resource exhaustion, e.g., by causing the algorithms calculating + routing tables or MPR sets to be invoked continuously, preventing the + internal state of a router from converging, which depletes the energy + of battery-driven routers, etc. + +2. Terminology + + This document uses the terminology and notation defined in [RFC5444], + [RFC6130], and [RFC7181]. Additionally, it defines the following + terminology: + + 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 relates to the ability for 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. Topology map acquisition can be hindered by (i) TCs + + + + +Clausen, et al. Informational [Page 7] + +RFC 8116 OLSRv2 Threats May 2017 + + + 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. In order to reduce the number of transmissions, when a + control message is due for transmission, OLSRv2 piggybacks all queued + messages into a single transmission. Thus, 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; therefore, 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 will reduce 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. + + + + +Clausen, et al. Informational [Page 8] + +RFC 8116 OLSRv2 Threats May 2017 + + + .---. + | X | + --'---' __ + / \ + / \ + .---. .---. + TC -----> | A | | C | + '---' '---' + \ .---. / + \-- | B |__/ + '---' + + Figure 1: Hop Limit Attack + + A 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 Hops + + In 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 + + + + +Clausen, et al. Informational [Page 9] + +RFC 8116 OLSRv2 Threats May 2017 + + + 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 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 Forwarding + + Some 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 operating 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). + + + + + +Clausen, et al. Informational [Page 10] + +RFC 8116 OLSRv2 Threats May 2017 + + + 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 + + A wormhole, depicted in the example in Figure 4, may be established + between two collaborating devices that are connected by an out-of- + band channel. These devices send traffic through the "tunnel" to + their alter ego, which "replays" the traffic. Thus, routers D and S + appear as if direct neighbors and are reachable from each other in 1 + hop through the tunnel, with the path through the MANET being 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 Protocol + + The consequences of such a wormhole in the network depend on the + detailed behavior of the wormhole. If the wormhole relays only + control traffic, but not data traffic, the same considerations as in + Section 4.1 apply. If, however, the wormhole relays all traffic + (control and data alike), it is identical, connectivity wise, to a + usable link - and the routing protocol will correctly generate a + topology map reflecting the effective network topology. The + efficiency of the topology obtained depends on (i) the wormhole + characteristics, (ii) how the wormhole presents itself, and (iii) how + paths are calculated. + + Assuming that paths are calculated with unit cost for all links, + including the "link" presented by the wormhole, if the real + characteristics of the wormhole are as if it were a path of more than + 100 hops (e.g., with respect to delay, bandwidth, etc.), then the + presence of the wormhole results in a degradation in performance as + compared to using the non-wormhole path. Conversely, if the "link" + presented by the wormhole has better characteristics, the wormhole + results in improved performance. + + + + + +Clausen, et al. Informational [Page 11] + +RFC 8116 OLSRv2 Threats May 2017 + + + If paths are calculated using non-unit-costs for all links, and if + the cost of the "link" presented by the wormhole correctly represents + the actual cost (e.g., if the cost is established through + measurements across the wormhole), then the wormhole may, in the + worst case, cause no degradation in performance or, in the best case, + improve performance by offering a better path. If the cost of the + "link" presented by the wormhole is misrepresented, then the same + considerations as for unit-cost links apply. + + An additional consideration with regard to wormholes is that they may + present topologically attractive paths for the network; however, it + may be undesirable to have data traffic transit such a path. An + attacker could, by virtue of introducing a wormhole, acquire the + ability to record and inspect transiting data traffic. + +4.3. Sequence Number Attacks + + OLSRv2 uses two different sequence numbers in TCs to (i) avoid + processing and forwarding the same message more than once (Message + Sequence Number) and to (ii) ensure that old information, arriving + late due to, e.g., long paths or other delays, is not allowed to + overwrite more recent information generated (Advertised Neighbor + Sequence Number (ANSN)). + +4.3.1. Message Sequence Number + + 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. + Subsequent TCs with the same sequence numbers, originating from the + router whose identity was spoofed, would hence be ignored until + eventually information concerning these "spoofed" TCs expires. + +4.3.2. Advertised Neighbor Sequence Number (ANSN) + + 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 that which was last used by + the legitimate router. Routers will retain this larger ANSN as "the + most recent information" and discard subsequent TCs with lower + sequence numbers as being "old". + + + + + + + + + + +Clausen, et al. Informational [Page 12] + +RFC 8116 OLSRv2 Threats May 2017 + + +4.4. Indirect Jamming + + Indirect jamming is an attack in which a compromised OLSRv2 router + is, by its actions, causing legitimate routers to generate inordinate + amounts of control traffic, thereby increasing both channel + occupation and the overhead incurred in each router for processing + this control traffic. This control traffic will be originated from + legitimate routers; thus, to the wider network, the malicious device + may remain undetected. + + The general mechanism whereby a malicious router can cause indirect + jamming is for it to participate in the protocol by generating + plausible control traffic and to tune this control traffic to in turn + trigger receiving routers to generate additional traffic. For + OLSRv2, such an indirect attack can be directed at the neighborhood + discovery mechanism and the LSA mechanism, respectively. + + One efficient indirect jamming attack in OLSRv2 is to target control + traffic destined for network-wide diffusion. This is illustrated in + Figure 5. + + The malicious router X selects router A as an MPR at time t0 in a + HELLO. This causes X to appear as MPR selector for A and, + consequently, A sets X to be advertised in its "Neighbor Set" and + increments the associated "Advertised Neighbor Sequence Number" + (ANSN). Router A must then advertise the link between itself and X + in subsequent outgoing TCs (t1), also including the ANSN in such TCs. + Upon X having received this 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 receipt hereof) remove X from the set of advertised + neighbors and increment the ANSN. Router A will then, in subsequent + TCs, advertise the remaining set of advertised neighbors (i.e., with + X removed) and the corresponding ANSN (t3). Upon X having received + this information in another TC from A, it may repeat this cycle, + alternating advertising the link A-X as "LOST" and as "MPR". + + + + + + + + + + + + + + + +Clausen, et al. Informational [Page 13] + +RFC 8116 OLSRv2 Threats May 2017 + + + 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 Advertisement + + Routers receiving a TC message will parse and process this message, + specifically updating their topology map as a consequence of + successful receipt. If the ANSN between two successive TCs from the + same router has incremented, then the topology has changed and + routing sets are to be recalculated. This has the potential to be a + computationally costly operation. + + A compromised OLSRv2 router may chose to conduct this attack against + all its neighbors, thus maximizing its disruptive impact on the + network with relatively little overhead of its own: other than + participating in the neighborhood discovery procedure, the + compromised OLSRv2 router will monitor TCs generated by its neighbors + and alternate the advertised status for each such neighbor between + "MPR" and "LOST". The compromised OLSRv2 router will indicate its + willingness to be selected as an MPR as 0 (thus avoiding selection as + an MPR) and may ignore all other protocol operations while still + remaining effective as an attacker. + + The basic operation of OLSRv2 employs periodic message emissions, and + by this attack it can be ensured that each such periodic message will + entail routing table recalculation in all routers in the network. + + If the routers in the network have "triggered TCs" enabled, this + attack may also cause an increased TC frequency. Triggered TCs are + intended to allow a (stable) network to have relatively low TC + emission frequencies yet still allow link breakage or link emergence + to be advertised through the network rapidly. A minimum message + interval (typically much smaller than the regular periodic message + interval) is imposed to rate-limit worst-case message emissions. + + + +Clausen, et al. Informational [Page 14] + +RFC 8116 OLSRv2 Threats May 2017 + + + This attack can cause the TC interval to permanently 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). + + Indirect jamming by a compromised OLSRv2 router can thus 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 occur by a compromised OLSRv2 router + employing either identity spoofing or link spoofing for conducting an + attack against an OLSRv2 network. The threats related to NHDP, such + as identity spoofing in NHDP, link spoofing in NHDP, and creating + loops, have been illustrated in [RFC7186]. This section mainly + addresses the vulnerabilities in [RFC7181]. + +5.1. Identity Spoofing + + Identity spoofing can be employed by a compromised OLSRv2 router via + the neighborhood discovery process and via the LSA process. Either + of them causes inconsistent topology maps in routers in the network. + The creation of inconsistent topology maps due to neighborhood + discovery has been discussed in [RFC7186]. For OLSRv2, the attack on + the LSA process can also cause inconsistent topology maps. + + An inconsistent topology map may occur when the compromised OLSRv2 + router takes part in the LSA process by selecting a neighbor as an + MPR, which in turn advertises the spoofed identities of the + compromised OLSRv2 router. This attack will alter the topology maps + of all routers of 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 will be informed about the link + F-A by the TCs originating from F. Assuming that (the real) A + + + + +Clausen, et al. Informational [Page 15] + +RFC 8116 OLSRv2 Threats May 2017 + + + selects B as an MPR, the link B-A will also be advertised in the + network. + + When calculating paths, B and C will calculate paths to A via B, as + illustrated 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 illustrated in + Figure 7(b); for these routers, the shortest path to A is via the + compromised OLSRv2 router X, and these are thus disconnected from the + real A. D will have a choice, as the path calculated to A via B is + of the same length as the path via the compromised OLSRv2 router X, + as illustrated in Figure 7(c). + + In general, the following observations can be made: + + o The network will be split in two, with those routers closer to B + than to X reaching A, whereas those routers closer to X than to B + will be unable to reach A. + + o Routers beyond B, i.e., routers beyond 1 hop away from A, will be + unable to detect this identity spoofing. + + The identity spoofing attack via the LSA procedure has a higher + impact than the attack on the neighborhood discovery procedure since + it alters the topology maps of all routers in the network and not + only in the 2-hop neighborhood. However, the attack is easier to + detect by other routers in the network. Since the compromised OLSRv2 + router is advertised in the whole network, routers whose identities + are spoofed by the compromised OLSRv2 router can detect the attack. + For example, when A receives a TC from F advertising the link F-A, it + can deduce that some entity is injecting incorrect link state + information as it does not have F as 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 presence of a compromised OLSRv2 router X, + spoofing the address of A. + + Figure 7: Routing Paths towards A + + + +Clausen, et al. Informational [Page 16] + +RFC 8116 OLSRv2 Threats May 2017 + + + As the compromised OLSRv2 router X does not itself send the TCs, but + rather, by virtue of MPR selection, ensures that the addresses it + spoofs are advertised in TCs from its MPR selector F, the attack may + be difficult to counter. Simply ignoring TCs that originate from F + may also suppress the link state information for other, legitimate, + MPR selectors of F. + + Thus, identity spoofing by a compromised OLSRv2 router, participating + in the LSA process by selecting MPRs only, creates a situation + wherein two or more routers have substantially inconsistent topology + maps: traffic for an identified destination is, depending on where in + the network it appears, delivered to different routers. + +5.2. Link Spoofing + + Link spoofing is a situation in which a router advertises non- + existing links to another router (possibly not present in the + network). Essentially, TCs and HELLOs both advertise links to direct + neighbor routers with the difference being the scope of the + advertisement. Thus, link spoofing consists of a compromised OLSRv2 + router reporting that it has neighbors routers that are either not + present in the network or are effectively not neighbors of the + compromised OLSRv2 router. + + It can be noted that a situation similar to link spoofing may occur + temporarily in an OLSR or OLSRv2 network without compromised OLSRv2 + routers: if A was, but is no more, a neighbor of B, then A may still + be advertising a link to B for the duration of the time it takes for + the neighborhood discovery process to determine this changed + neighborhood. + + In the context of this document, link spoofing refers to a persistent + situation where a compromised OLSRv2 router intentionally advertises + links to other routers for which it is not a direct neighbor. + + + + + + + + + + + + + + + + + +Clausen, et al. Informational [Page 17] + +RFC 8116 OLSRv2 Threats May 2017 + + +5.2.1. Inconsistent Topology Maps Due to Link State Advertisements + + Figure 8 illustrates a network in which the compromised OLSRv2 router + X spoofs links to an existing router A by participating in the LSA + process and including this non-existing 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; thus, all routers will record both of the links + X-A and B-A. + + Figure 8: Link Spoofing + + As TCs are flooded through the network, all routers will 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 likewise + flood this link state information through the network; thus, all + routers will receive and record information describing a link B-A. + + When calculating routing paths, B, C, and D will calculate paths to A + via B, as illustrated 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 + illustrated in Figure 9(b); for these routers, the shortest path to A + is via X, and these are thus disconnected from the real router A. E + will have a choice: the path calculated to A via B is of the same + length as the path via X, as illustrated in Figure 9(b). + + 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 E + + Description: 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 + + + + + + + +Clausen, et al. Informational [Page 18] + +RFC 8116 OLSRv2 Threats May 2017 + + + In general, the following observations can be made: + + o The network will be separated in two: routers closer to B than X + will reach A, whereas routers closer to X than B will be unable to + reach A. + + o 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. However, deployments may + choose to use different security mechanisms if more appropriate. + Therefore, it is important to understand both the inherent resilience + of OLSRv2 against security vulnerabilities when not using the + mechanisms specified in [RFC7183] and the protection that [RFC7183] + provides when used in a deployment. + +6.1. Inherent OLSRv2 Resilience + + OLSRv2 (even when used without the mandatory-to-implement security + mechanisms in [RFC7183]) provides some inherent resilience against + part of the attacks described in this document. In particular, it + provides the following resilience: + + o Sequence numbers: OLSRv2 employs message sequence numbers, which + are specific per the router identity and message type. Routers + keep an "information freshness" number (ANSN) incremented each + time the content of an LSA from a router changes. This allows + rejecting both "old" information and duplicate messages, and it + provides some protection against "message replay". However, this + also presents an attack vector (Section 4.3). + + o 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 reception of + control traffic; however, OLSRv2 will correctly recognize, and + ignore, such a link that is not bidirectional. + + o Message interval bounds: The frequency of control messages, with + minimum intervals imposed for HELLO and TCs. This may limit the + impact from an indirect jamming attack (Section 4.4). + + + + + + + + +Clausen, et al. Informational [Page 19] + +RFC 8116 OLSRv2 Threats May 2017 + + + o Additional reasons for rejecting control messages: The OLSRv2 + specification includes a list of reasons for which an incoming + control message should be rejected as malformed -- and allows that + a protocol extension may recognize additional reasons for OLSRv2 + to consider a message malformed. Together with the flexible + message format [RFC5444], this allows addition of security + mechanisms, such as digital signatures, while remaining compliant + 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 using the generalized packet/message format + described in [RFC5444] and the TLV definitions in [RFC7182]. The + specification describes how to add an Integrity Check Value (ICV) in + a TLV to each control message, providing integrity protection of the + content of the message using Hashed Message Authentication Code + (HMAC) / SHA-256. In addition, a timestamp TLV is added to the + message prior to creating the ICV, enabling replay protection of + messages. The document specifies how to sign outgoing messages and + how to verify incoming messages, as well as under which circumstances + an invalid message is rejected. Because of the HMAC/SHA-256 ICV, a + shared key between all routers in the MANET is assumed. A router + without valid credentials is not able to create an ICV that can be + correctly verified by other routers in the MANET; therefore, such an + incorrectly signed message will be rejected by other MANET routers, + and the router cannot participate in the OLSRv2 routing process + (i.e., the malicious router will be ignored by other legitimate + routers). [RFC7183] does not address the case where a router with + valid credentials has been compromised. Such a compromised router + will not be excluded from the routing process, and other means of + detecting such a router are necessary if required in a deployment: + for example, using an asymmetric key extension to [RFC7182] that + allows revocation of the access of one particular router. + + In the following sections, each of the vulnerabilities described + earlier in this document will be evaluated in terms of 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. + + + + + + + + + + + +Clausen, et al. Informational [Page 20] + +RFC 8116 OLSRv2 Threats May 2017 + + +6.2.1. Topology Map Acquisition + + Attack on Jittering: As only OLSRv2 routers with valid credentials + can participate in the routing process, a malicious router cannot + reduce the jitter time of an attacked router to 0 by sending many + TC messages in a short time. The attacked router would reject all + the incoming messages as "invalid" and not forward them. The same + applies for the case where a malicious router wants to assure that + by forcing a 0 jitter interval, the message arrives before the + same message forwarded by legitimate routers. + + Modifying the Hop Limit and the Hop Count: As the hop limit and hop + count are not protected by [RFC7183] (since they are mutable + fields that change at every hop), this attack is still feasible. + It is possible to apply [RFC5444] packet-level protection by using + ICV Packet TLV defined in [RFC7182] to provide hop-by-hop + integrity protection -- at the expense of a requirement of + pairwise trust between all neighbor routers. + +6.2.2. Effective Topology + + Incorrect Forwarding: As only OLSRv2 routers with valid credentials + can participate in the routing process, a malicious router will + not be part of the topology of other legitimate OLSRv2 routers. + Therefore, no data traffic will be sent to the malicious router + for forwarding. + + Wormholes: Since a wormhole consists of at least two devices + forwarding (unmodified) traffic, this attack is still feasible and + undetectable by the OLSRv2 routing process since the attack does + not involve the OLSRv2 protocol itself (but rather 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. + + Message Sequence Number: As the message sequence number is included + in the ICV calculation, OLSRv2 is protected against this attack. + + Advertised Neighbor Sequence Number (ANSN): As the ANSN is included + in the ICV calculation, OLSRv2 is protected against this attack. + + 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. + + + + + +Clausen, et al. Informational [Page 21] + +RFC 8116 OLSRv2 Threats May 2017 + + +6.2.3. Inconsistent Topology + + Identity Spoofing: 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. 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. + + 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 + + Other than implementing OLSRv2, including appropriate security + mechanisms, the way in which the protocol is deployed is also + important to ensure proper functioning and threat mitigation. For + example, Section 4.1 discussed considerations due to an incorrect + forwarding-policy setting, and Section 4.2 discussed considerations + for when intentional wormholes are present in a deployment. + +7. Security Considerations + + This document does not specify a protocol or a procedure but reflects + on security considerations for OLSRv2 and for its constituent parts, + including NHDP. The document initially analyses threats to topology + map acquisition, with the assumption that no security mechanism + (including the mandatory-to-implement mechanisms from [RFC7182] and + [RFC7183]) is in use. Then, it proceeds to discuss how the use of + [RFC7182] and [RFC7183] mitigate the identified threats. When + [RFC7183] is used with routers using a single shared key, the + protection offered is not effective if a compromised router has valid + credentials. + + + + + + +Clausen, et al. Informational [Page 22] + +RFC 8116 OLSRv2 Threats May 2017 + + +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, + . + + [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, + . + + [RFC7186] Yi, J., Herberg, U., and T. Clausen, "Security Threats for + the Neighborhood Discovery Protocol (NHDP)", RFC 7186, + DOI 10.17487/RFC7186, April 2014, + . + +8.2. Informative References + + [FUNKFEUER] + Funkfeuer, "Funkfeuer", . + + [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. + + + + + + + + +Clausen, et al. Informational [Page 23] + +RFC 8116 OLSRv2 Threats May 2017 + + + [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, + . + + [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, + . + + [RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter + Considerations in Mobile Ad Hoc Networks (MANETs)", + RFC 5148, DOI 10.17487/RFC5148, February 2008, + . + + [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, + . + + [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value + Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, + DOI 10.17487/RFC5497, March 2009, + . + + [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, . + + [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, + . + + [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, . + + + + +Clausen, et al. Informational [Page 24] + +RFC 8116 OLSRv2 Threats May 2017 + + + [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, . + + [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, + . + + [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, . + + [RFC7859] Dearlove, C., "Identity-Based Signatures for Mobile Ad Hoc + Network (MANET) Routing Protocols", RFC 7859, + DOI 10.17487/RFC7859, May 2016, + . + + [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, . + + + + + + + + + + + + + + + + + + + + + + + + + + +Clausen, et al. Informational [Page 25] + +RFC 8116 OLSRv2 Threats May 2017 + + +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/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Clausen, et al. Informational [Page 26] + -- cgit v1.2.3