summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8116.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8116.txt')
-rw-r--r--doc/rfc/rfc8116.txt1459
1 files changed, 1459 insertions, 0 deletions
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,
+ <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.
+
+
+
+
+
+
+
+
+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,
+ <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>.
+
+
+
+
+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, <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>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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]
+