<pre>Internet Engineering Task Force (IETF)                        T. Clausen
Request for Comments: 8116
Category: Informational                                       U. Herberg
ISSN: 2070-1721
                                                                   J. Yi
                                                     Ecole Polytechnique
                                                                May 2017


                        <span class="h1">Security Threats to the</span>
        <span class="h1">Optimized Link State Routing Protocol Version 2 (OLSRv2)</span>

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 <a href="./rfc7841#section-2">Section&nbsp;2 of RFC 7841</a>.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   <a href="http://www.rfc-editor.org/info/rfc8116">http://www.rfc-editor.org/info/rfc8116</a>.















<span class="grey">Clausen, et al.               Informational                     [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc8116">RFC 8116</a>                     OLSRv2 Threats                     May 2017</span>


Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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.





































<span class="grey">Clausen, et al.               Informational                     [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc8116">RFC 8116</a>                     OLSRv2 Threats                     May 2017</span>


Table of Contents

   <a href="#section-1">1</a>.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   <a href="#page-4">4</a>
     <a href="#section-1.1">1.1</a>.  OLSRv2 Overview . . . . . . . . . . . . . . . . . . . . .   <a href="#page-5">5</a>
       <a href="#section-1.1.1">1.1.1</a>.  Neighborhood Discovery  . . . . . . . . . . . . . . .   <a href="#page-5">5</a>
       <a href="#section-1.1.2">1.1.2</a>.  MPR Selection . . . . . . . . . . . . . . . . . . . .   <a href="#page-6">6</a>
       <a href="#section-1.1.3">1.1.3</a>.  Link State Advertisement  . . . . . . . . . . . . . .   <a href="#page-6">6</a>
     <a href="#section-1.2">1.2</a>.  Link State Vulnerability Taxonomy . . . . . . . . . . . .   <a href="#page-6">6</a>
     <a href="#section-1.3">1.3</a>.  OLSRv2 Attack Vectors . . . . . . . . . . . . . . . . . .   <a href="#page-7">7</a>
   <a href="#section-2">2</a>.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   <a href="#page-7">7</a>
   <a href="#section-3">3</a>.  Topology Map Acquisition  . . . . . . . . . . . . . . . . . .   <a href="#page-7">7</a>
     <a href="#section-3.1">3.1</a>.  Attack on Jittering . . . . . . . . . . . . . . . . . . .   <a href="#page-8">8</a>
     <a href="#section-3.2">3.2</a>.  Hop Count and Hop Limit Attacks . . . . . . . . . . . . .   <a href="#page-8">8</a>
       <a href="#section-3.2.1">3.2.1</a>.  Modifying the Hop Limit . . . . . . . . . . . . . . .   <a href="#page-8">8</a>
       <a href="#section-3.2.2">3.2.2</a>.  Modifying the Hop Count . . . . . . . . . . . . . . .   <a href="#page-9">9</a>
   <a href="#section-4">4</a>.  Effective Topology  . . . . . . . . . . . . . . . . . . . . .  <a href="#page-10">10</a>
     <a href="#section-4.1">4.1</a>.  Incorrect Forwarding  . . . . . . . . . . . . . . . . . .  <a href="#page-10">10</a>
     <a href="#section-4.2">4.2</a>.  Wormholes . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-11">11</a>
     <a href="#section-4.3">4.3</a>.  Sequence Number Attacks . . . . . . . . . . . . . . . . .  <a href="#page-12">12</a>
       <a href="#section-4.3.1">4.3.1</a>.  Message Sequence Number . . . . . . . . . . . . . . .  <a href="#page-12">12</a>
       <a href="#section-4.3.2">4.3.2</a>.  Advertised Neighbor Sequence Number (ANSN)  . . . . .  <a href="#page-12">12</a>
     <a href="#section-4.4">4.4</a>.  Indirect Jamming  . . . . . . . . . . . . . . . . . . . .  <a href="#page-12">12</a>
   <a href="#section-5">5</a>.  Inconsistent Topology . . . . . . . . . . . . . . . . . . . .  <a href="#page-15">15</a>
     <a href="#section-5.1">5.1</a>.  Identity Spoofing . . . . . . . . . . . . . . . . . . . .  <a href="#page-15">15</a>
     <a href="#section-5.2">5.2</a>.  Link Spoofing . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-17">17</a>
       5.2.1.  Inconsistent Topology Maps Due to Link State
               Advertisements  . . . . . . . . . . . . . . . . . . .  <a href="#page-18">18</a>
   <a href="#section-6">6</a>.  Mitigation of Security Vulnerabilities for OLSRv2 . . . . . .  <a href="#page-19">19</a>
     <a href="#section-6.1">6.1</a>.  Inherent OLSRv2 Resilience  . . . . . . . . . . . . . . .  <a href="#page-19">19</a>
     <a href="#section-6.2">6.2</a>.  Resilience by Using <a href="./rfc7183">RFC 7183</a> with OLSRv2  . . . . . . . .  <a href="#page-20">20</a>
       <a href="#section-6.2.1">6.2.1</a>.  Topology Map Acquisition  . . . . . . . . . . . . . .  <a href="#page-21">21</a>
       <a href="#section-6.2.2">6.2.2</a>.  Effective Topology  . . . . . . . . . . . . . . . . .  <a href="#page-21">21</a>
       <a href="#section-6.2.3">6.2.3</a>.  Inconsistent Topology . . . . . . . . . . . . . . . .  <a href="#page-22">22</a>
     <a href="#section-6.3">6.3</a>.  Correct Deployment  . . . . . . . . . . . . . . . . . . .  <a href="#page-22">22</a>
   <a href="#section-7">7</a>.  Security Considerations . . . . . . . . . . . . . . . . . . .  <a href="#page-22">22</a>
   <a href="#section-8">8</a>.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-23">23</a>
     <a href="#section-8.1">8.1</a>.  Normative References  . . . . . . . . . . . . . . . . . .  <a href="#page-23">23</a>
     <a href="#section-8.2">8.2</a>.  Informative References  . . . . . . . . . . . . . . . . .  <a href="#page-23">23</a>
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-26">26</a>












<span class="grey">Clausen, et al.               Informational                     [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc8116">RFC 8116</a>                     OLSRv2 Threats                     May 2017</span>


<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   The Optimized Link State Routing Protocol version 2 (OLSRv2)
   [<a href="./rfc7181" title="&quot;The Optimized Link State Routing Protocol Version 2&quot;">RFC7181</a>] is a successor to OLSR [<a href="./rfc3626" title="&quot;Optimized Link State Routing Protocol (OLSR)&quot;">RFC3626</a>] 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 [<a href="./rfc5148" title="&quot;Jitter Considerations in Mobile Ad Hoc Networks (MANETs)&quot;">RFC5148</a>],
   [<a href="./rfc5444" title="&quot;Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format&quot;">RFC5444</a>], [<a href="./rfc5497" title="&quot;Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs)&quot;">RFC5497</a>], [<a href="./rfc6130" title="&quot;Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)&quot;">RFC6130</a>], [<a href="./rfc7182" title="&quot;Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)&quot;">RFC7182</a>], [<a href="./rfc7183" title="&quot;Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)&quot;">RFC7183</a>], [<a href="./rfc7187" title="&quot;Routing Multipoint Relay Optimization for the Optimized Link State Routing Protocol Version 2 (OLSRv2)&quot;">RFC7187</a>],
   [<a href="./rfc7188" title="&quot;Optimized Link State Routing Protocol Version 2 (OLSRv2) and MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs&quot;">RFC7188</a>], [<a href="./rfc7466" title="&quot;An Optimization for the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)&quot;">RFC7466</a>], etc.

   The developments reflected in OLSRv2 have been motivated by increased
   real-world deployment experiences, e.g., from networks such as
   FunkFeuer [<a href="#ref-FUNKFEUER">FUNKFEUER</a>], 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 [<a href="./rfc5068" title="&quot;Email Submission Operations: Access and Accountability Requirements&quot;">RFC5068</a>].

   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 <a href="./rfc7181#section-23.5">Section&nbsp;23.5 of [RFC7181]</a>.  It also analyzes which of
   these security vulnerabilities can be mitigated when using the
   mandatory-to-implement security mechanisms for OLSRv2 and how the



<span class="grey">Clausen, et al.               Informational                     [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc8116">RFC 8116</a>                     OLSRv2 Threats                     May 2017</span>


   vulnerabilities are mitigated.  This separation is important since,
   as explicitly stated in [<a href="./rfc7181" title="&quot;The Optimized Link State Routing Protocol Version 2&quot;">RFC7181</a>]:

      Any deployment of OLSRv2 SHOULD use the security mechanism
      specified in [<a href="./rfc7183" title="&quot;Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)&quot;">RFC7183</a>] 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 [<a href="./rfc7186" title="&quot;Security Threats for the Neighborhood Discovery Protocol (NHDP)&quot;">RFC7186</a>], also apply to OLSRv2.

   It should be noted that many OLSRv2 implementations are configurable,
   and so an attack on the configuration system (such as [<a href="./rfc7939" title="&quot;Definition of Managed Objects for the Neighborhood Discovery Protocol&quot;">RFC7939</a>] and
   [<a href="./rfc7184" title="&quot;Definition of Managed Objects for the Optimized Link State Routing Protocol Version 2&quot;">RFC7184</a>]) can be used to adversely affect the operation of an OLSRv2
   implementation.

<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>.  OLSRv2 Overview</span>

   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.

<span class="h4"><a class="selflink" id="section-1.1.1" href="#section-1.1.1">1.1.1</a>.  Neighborhood Discovery</span>

   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 [<a href="./rfc7181" title="&quot;The Optimized Link State Routing Protocol Version 2&quot;">RFC7181</a>] uses NHDP [<a href="./rfc6130" title="&quot;Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)&quot;">RFC6130</a>] as its neighborhood
   discovery mechanism.  The vulnerabilities of NHDP are analyzed in
   [<a href="./rfc7186" title="&quot;Security Threats for the Neighborhood Discovery Protocol (NHDP)&quot;">RFC7186</a>].



<span class="grey">Clausen, et al.               Informational                     [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc8116">RFC 8116</a>                     OLSRv2 Threats                     May 2017</span>


<span class="h4"><a class="selflink" id="section-1.1.2" href="#section-1.1.2">1.1.2</a>.  MPR Selection</span>

   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 [<a href="#ref-MPR-FLOODING">MPR-FLOODING</a>].

<span class="h4"><a class="selflink" id="section-1.1.3" href="#section-1.1.3">1.1.3</a>.  Link State Advertisement</span>

   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 <a href="#section-1.1.2">Section 1.1.2</a>.  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.

<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>.  Link State Vulnerability Taxonomy</span>

   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



<span class="grey">Clausen, et al.               Informational                     [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc8116">RFC 8116</a>                     OLSRv2 Threats                     May 2017</span>


   topology map that does not reflect the effective network topology,
   and (c) two or more routers may acquire inconsistent topology maps.

<span class="h3"><a class="selflink" id="section-1.3" href="#section-1.3">1.3</a>.  OLSRv2 Attack Vectors</span>

   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.

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Terminology</span>

   This document uses the terminology and notation defined in [<a href="./rfc5444" title="&quot;Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format&quot;">RFC5444</a>],
   [<a href="./rfc6130" title="&quot;Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)&quot;">RFC6130</a>], and [<a href="./rfc7181" title="&quot;The Optimized Link State Routing Protocol Version 2&quot;">RFC7181</a>].  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.

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Topology Map Acquisition</span>

   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




<span class="grey">Clausen, et al.               Informational                     [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc8116">RFC 8116</a>                     OLSRv2 Threats                     May 2017</span>


   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 [<a href="./rfc7186" title="&quot;Security Threats for the Neighborhood Discovery Protocol (NHDP)&quot;">RFC7186</a>].

<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  Attack on Jittering</span>

   OLSRv2 incorporates a jittering mechanism: a random, but bounded,
   delay on outgoing control traffic [<a href="./rfc5148" title="&quot;Jitter Considerations in Mobile Ad Hoc Networks (MANETs)&quot;">RFC5148</a>].  This may be necessary
   when link layers (such as 802.11 [<a href="#ref-IEEE802.11">IEEE802.11</a>]) 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.

<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  Hop Count and Hop Limit Attacks</span>

   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.

<span class="h4"><a class="selflink" id="section-3.2.1" href="#section-3.2.1">3.2.1</a>.  Modifying the Hop Limit</span>

   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.




<span class="grey">Clausen, et al.               Informational                     [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc8116">RFC 8116</a>                     OLSRv2 Threats                     May 2017</span>


                                 .---.
                                 | X |
                               --'---' __
                              /          \
                             /            \
                         .---.              .---.
             TC -----&gt;   | 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.

<span class="h4"><a class="selflink" id="section-3.2.2" href="#section-3.2.2">3.2.2</a>.  Modifying the Hop Count</span>

   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 [<a href="./rfc5497" title="&quot;Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs)&quot;">RFC5497</a>] (e.g., as part of a Fish Eye extension
   to OLSR2 [<a href="#ref-OLSR-FSR" title="&quot;Combining Temporal and Spatial Partial Topology for MANET routing - Merging OLSR and FSR&quot;">OLSR-FSR</a>] [<a href="#ref-OLSR-FSR-Scaling">OLSR-FSR-Scaling</a>]).

              v_time(3hops)=9s  v_time(4hops)=12s   v_time(5hops)=15s
     .---.           .---.          .---.           .---.
     | A |-- ... --&gt; | B | -------&gt; | X |----------&gt;| 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




<span class="grey">Clausen, et al.               Informational                     [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc8116">RFC 8116</a>                     OLSRv2 Threats                     May 2017</span>


   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.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Effective Topology</span>

   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 [<a href="./rfc7186" title="&quot;Security Threats for the Neighborhood Discovery Protocol (NHDP)&quot;">RFC7186</a>].  Other
   threats specific to OLSRv2 are further detailed in this section.

<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>.  Incorrect Forwarding</span>

   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).





<span class="grey">Clausen, et al.               Informational                    [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc8116">RFC 8116</a>                     OLSRv2 Threats                     May 2017</span>


   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.

<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>.  Wormholes</span>

   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
   <a href="#section-4.1">Section 4.1</a> 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.





<span class="grey">Clausen, et al.               Informational                    [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc8116">RFC 8116</a>                     OLSRv2 Threats                     May 2017</span>


   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.

<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>.  Sequence Number Attacks</span>

   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)).

<span class="h4"><a class="selflink" id="section-4.3.1" href="#section-4.3.1">4.3.1</a>.  Message Sequence Number</span>

   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.

<span class="h4"><a class="selflink" id="section-4.3.2" href="#section-4.3.2">4.3.2</a>.  Advertised Neighbor Sequence Number (ANSN)</span>

   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".










<span class="grey">Clausen, et al.               Informational                    [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc8116">RFC 8116</a>                     OLSRv2 Threats                     May 2017</span>


<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>.  Indirect Jamming</span>

   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".















<span class="grey">Clausen, et al.               Informational                    [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc8116">RFC 8116</a>                     OLSRv2 Threats                     May 2017</span>


              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.



<span class="grey">Clausen, et al.               Informational                    [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc8116">RFC 8116</a>                     OLSRv2 Threats                     May 2017</span>


   This attack can cause the TC interval to permanently become equal to
   the minimum message interval.  [<a href="./rfc7181" title="&quot;The Optimized Link State Routing Protocol Version 2&quot;">RFC7181</a>] 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.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Inconsistent Topology</span>

   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 [<a href="./rfc7186" title="&quot;Security Threats for the Neighborhood Discovery Protocol (NHDP)&quot;">RFC7186</a>].  This section mainly
   addresses the vulnerabilities in [<a href="./rfc7181" title="&quot;The Optimized Link State Routing Protocol Version 2&quot;">RFC7181</a>].

<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>.  Identity Spoofing</span>

   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 [<a href="./rfc7186" title="&quot;Security Threats for the Neighborhood Discovery Protocol (NHDP)&quot;">RFC7186</a>].  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




<span class="grey">Clausen, et al.               Informational                    [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc8116">RFC 8116</a>                     OLSRv2 Threats                     May 2017</span>


   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 &lt; ---- B &lt; ---- C           E ----&gt; F ----&gt; X

      (a) Routers B and C           (b) Routers E and F


         A &lt; --- B &lt; --- C &lt; --- D ---&gt; E ---&gt; F ----&gt; 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



<span class="grey">Clausen, et al.               Informational                    [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc8116">RFC 8116</a>                     OLSRv2 Threats                     May 2017</span>


   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.

<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>.  Link Spoofing</span>

   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.

















<span class="grey">Clausen, et al.               Informational                    [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc8116">RFC 8116</a>                     OLSRv2 Threats                     May 2017</span>


<span class="h4"><a class="selflink" id="section-5.2.1" href="#section-5.2.1">5.2.1</a>.  Inconsistent Topology Maps Due to Link State Advertisements</span>

   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 &lt; --- B &lt; --- C &lt; --- D           F ---&gt; G ---&gt; X ---&gt; A

       (a) Routers B, C, and D           (b) Routers F and G


   A &lt; --- B &lt; --- C &lt; --- D &lt; --- E ---&gt; F ---&gt; G ---&gt; X ---&gt; 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







<span class="grey">Clausen, et al.               Informational                    [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc8116">RFC 8116</a>                     OLSRv2 Threats                     May 2017</span>


   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.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Mitigation of Security Vulnerabilities for OLSRv2</span>

   As described in <a href="#section-1">Section 1</a>, [<a href="./rfc7183" title="&quot;Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)&quot;">RFC7183</a>] 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 [<a href="./rfc7183" title="&quot;Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)&quot;">RFC7183</a>] and the protection that [<a href="./rfc7183" title="&quot;Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)&quot;">RFC7183</a>]
   provides when used in a deployment.

<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>.  Inherent OLSRv2 Resilience</span>

   OLSRv2 (even when used without the mandatory-to-implement security
   mechanisms in [<a href="./rfc7183" title="&quot;Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)&quot;">RFC7183</a>]) 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 (<a href="#section-4.3">Section 4.3</a>).

   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 (<a href="#section-4.4">Section 4.4</a>).








<span class="grey">Clausen, et al.               Informational                    [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc8116">RFC 8116</a>                     OLSRv2 Threats                     May 2017</span>


   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 [<a href="./rfc5444" title="&quot;Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format&quot;">RFC5444</a>], this allows addition of security
      mechanisms, such as digital signatures, while remaining compliant
      with the OLSRv2 standard specification.

<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>.  Resilience by Using <a href="./rfc7183">RFC 7183</a> with OLSRv2</span>

   [<a id="ref-RFC7183">RFC7183</a>] specifies mechanisms for integrity and replay protection
   for NHDP and OLSRv2 using the generalized packet/message format
   described in [<a href="./rfc5444" title="&quot;Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format&quot;">RFC5444</a>] and the TLV definitions in [<a href="./rfc7182" title="&quot;Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)&quot;">RFC7182</a>].  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).  [<a href="./rfc7183" title="&quot;Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)&quot;">RFC7183</a>] 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 [<a href="./rfc7182" title="&quot;Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)&quot;">RFC7182</a>] 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 [<a href="./rfc7183" title="&quot;Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)&quot;">RFC7183</a>] provides sufficient protection
   against the attack.  It is implicitly assumed in each of the
   following sections that [<a href="./rfc7183" title="&quot;Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)&quot;">RFC7183</a>] is used with OLSRv2.











<span class="grey">Clausen, et al.               Informational                    [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc8116">RFC 8116</a>                     OLSRv2 Threats                     May 2017</span>


<span class="h4"><a class="selflink" id="section-6.2.1" href="#section-6.2.1">6.2.1</a>.  Topology Map Acquisition</span>

   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 [<a href="./rfc7183" title="&quot;Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)&quot;">RFC7183</a>] (since they are mutable
      fields that change at every hop), this attack is still feasible.
      It is possible to apply [<a href="./rfc5444" title="&quot;Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format&quot;">RFC5444</a>] packet-level protection by using
      ICV Packet TLV defined in [<a href="./rfc7182" title="&quot;Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)&quot;">RFC7182</a>] to provide hop-by-hop
      integrity protection -- at the expense of a requirement of
      pairwise trust between all neighbor routers.

<span class="h4"><a class="selflink" id="section-6.2.2" href="#section-6.2.2">6.2.2</a>.  Effective Topology</span>

   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 [<a href="./rfc7183" title="&quot;Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)&quot;">RFC7183</a>], 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.





<span class="grey">Clausen, et al.               Informational                    [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc8116">RFC 8116</a>                     OLSRv2 Threats                     May 2017</span>


<span class="h4"><a class="selflink" id="section-6.2.3" href="#section-6.2.3">6.2.3</a>.  Inconsistent Topology</span>

   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
      [<a href="./rfc7183" title="&quot;Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)&quot;">RFC7183</a>] 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 [<a href="./rfc7859" title="&quot;Identity-Based Signatures for Mobile Ad Hoc Network (MANET) Routing Protocols&quot;">RFC7859</a>]), 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.

<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>.  Correct Deployment</span>

   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, <a href="#section-4.1">Section 4.1</a> discussed considerations due to an incorrect
   forwarding-policy setting, and <a href="#section-4.2">Section 4.2</a> discussed considerations
   for when intentional wormholes are present in a deployment.

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  Security Considerations</span>

   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 [<a href="./rfc7182" title="&quot;Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)&quot;">RFC7182</a>] and
   [<a href="./rfc7183" title="&quot;Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)&quot;">RFC7183</a>]) is in use.  Then, it proceeds to discuss how the use of
   [<a href="./rfc7182" title="&quot;Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)&quot;">RFC7182</a>] and [<a href="./rfc7183" title="&quot;Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)&quot;">RFC7183</a>] mitigate the identified threats.  When
   [<a href="./rfc7183" title="&quot;Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)&quot;">RFC7183</a>] is used with routers using a single shared key, the
   protection offered is not effective if a compromised router has valid
   credentials.






<span class="grey">Clausen, et al.               Informational                    [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc8116">RFC 8116</a>                     OLSRv2 Threats                     May 2017</span>


<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  References</span>

<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>.  Normative References</span>

   [<a id="ref-RFC6130">RFC6130</a>]  Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
              Network (MANET) Neighborhood Discovery Protocol (NHDP)",
              <a href="./rfc6130">RFC 6130</a>, DOI 10.17487/RFC6130, April 2011,
              &lt;<a href="http://www.rfc-editor.org/info/rfc6130">http://www.rfc-editor.org/info/rfc6130</a>&gt;.

   [<a id="ref-RFC7181">RFC7181</a>]  Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
              "The Optimized Link State Routing Protocol Version 2",
              <a href="./rfc7181">RFC 7181</a>, DOI 10.17487/RFC7181, April 2014,
              &lt;<a href="http://www.rfc-editor.org/info/rfc7181">http://www.rfc-editor.org/info/rfc7181</a>&gt;.

   [<a id="ref-RFC7186">RFC7186</a>]  Yi, J., Herberg, U., and T. Clausen, "Security Threats for
              the Neighborhood Discovery Protocol (NHDP)", <a href="./rfc7186">RFC 7186</a>,
              DOI 10.17487/RFC7186, April 2014,
              &lt;<a href="http://www.rfc-editor.org/info/rfc7186">http://www.rfc-editor.org/info/rfc7186</a>&gt;.

<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>.  Informative References</span>

   [<a id="ref-FUNKFEUER">FUNKFEUER</a>]
              Funkfeuer, "Funkfeuer", &lt;<a href="https://www.funkfeuer.at/">https://www.funkfeuer.at/</a>&gt;.

   [<a id="ref-IEEE802.11">IEEE802.11</a>]
              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.

   [<a id="ref-MPR-FLOODING">MPR-FLOODING</a>]
              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.

   [<a id="ref-OLSR-FSR">OLSR-FSR</a>] 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.








<span class="grey">Clausen, et al.               Informational                    [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc8116">RFC 8116</a>                     OLSRv2 Threats                     May 2017</span>


   [<a id="ref-OLSR-FSR-Scaling">OLSR-FSR-Scaling</a>]
              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.

   [<a id="ref-RFC3626">RFC3626</a>]  Clausen, T., Ed. and P. Jacquet, Ed., "Optimized Link
              State Routing Protocol (OLSR)", <a href="./rfc3626">RFC 3626</a>,
              DOI 10.17487/RFC3626, October 2003,
              &lt;<a href="http://www.rfc-editor.org/info/rfc3626">http://www.rfc-editor.org/info/rfc3626</a>&gt;.

   [<a id="ref-RFC5068">RFC5068</a>]  Hutzler, C., Crocker, D., Resnick, P., Allman, E., and T.
              Finch, "Email Submission Operations: Access and
              Accountability Requirements", <a href="https://www.rfc-editor.org/bcp/bcp134">BCP 134</a>, <a href="./rfc5068">RFC 5068</a>,
              DOI 10.17487/RFC5068, November 2007,
              &lt;<a href="http://www.rfc-editor.org/info/rfc5068">http://www.rfc-editor.org/info/rfc5068</a>&gt;.

   [<a id="ref-RFC5148">RFC5148</a>]  Clausen, T., Dearlove, C., and B. Adamson, "Jitter
              Considerations in Mobile Ad Hoc Networks (MANETs)",
              <a href="./rfc5148">RFC 5148</a>, DOI 10.17487/RFC5148, February 2008,
              &lt;<a href="http://www.rfc-editor.org/info/rfc5148">http://www.rfc-editor.org/info/rfc5148</a>&gt;.

   [<a id="ref-RFC5444">RFC5444</a>]  Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
              "Generalized Mobile Ad Hoc Network (MANET) Packet/Message
              Format", <a href="./rfc5444">RFC 5444</a>, DOI 10.17487/RFC5444, February 2009,
              &lt;<a href="http://www.rfc-editor.org/info/rfc5444">http://www.rfc-editor.org/info/rfc5444</a>&gt;.

   [<a id="ref-RFC5497">RFC5497</a>]  Clausen, T. and C. Dearlove, "Representing Multi-Value
              Time in Mobile Ad Hoc Networks (MANETs)", <a href="./rfc5497">RFC 5497</a>,
              DOI 10.17487/RFC5497, March 2009,
              &lt;<a href="http://www.rfc-editor.org/info/rfc5497">http://www.rfc-editor.org/info/rfc5497</a>&gt;.

   [<a id="ref-RFC7182">RFC7182</a>]  Herberg, U., Clausen, T., and C. Dearlove, "Integrity
              Check Value and Timestamp TLV Definitions for Mobile Ad
              Hoc Networks (MANETs)", <a href="./rfc7182">RFC 7182</a>, DOI 10.17487/RFC7182,
              April 2014, &lt;<a href="http://www.rfc-editor.org/info/rfc7182">http://www.rfc-editor.org/info/rfc7182</a>&gt;.

   [<a id="ref-RFC7183">RFC7183</a>]  Herberg, U., Dearlove, C., and T. Clausen, "Integrity
              Protection for the Neighborhood Discovery Protocol (NHDP)
              and Optimized Link State Routing Protocol Version 2
              (OLSRv2)", <a href="./rfc7183">RFC 7183</a>, DOI 10.17487/RFC7183, April 2014,
              &lt;<a href="http://www.rfc-editor.org/info/rfc7183">http://www.rfc-editor.org/info/rfc7183</a>&gt;.

   [<a id="ref-RFC7184">RFC7184</a>]  Herberg, U., Cole, R., and T. Clausen, "Definition of
              Managed Objects for the Optimized Link State Routing
              Protocol Version 2", <a href="./rfc7184">RFC 7184</a>, DOI 10.17487/RFC7184, April
              2014, &lt;<a href="http://www.rfc-editor.org/info/rfc7184">http://www.rfc-editor.org/info/rfc7184</a>&gt;.




<span class="grey">Clausen, et al.               Informational                    [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc8116">RFC 8116</a>                     OLSRv2 Threats                     May 2017</span>


   [<a id="ref-RFC7187">RFC7187</a>]  Dearlove, C. and T. Clausen, "Routing Multipoint Relay
              Optimization for the Optimized Link State Routing Protocol
              Version 2 (OLSRv2)", <a href="./rfc7187">RFC 7187</a>, DOI 10.17487/RFC7187, April
              2014, &lt;<a href="http://www.rfc-editor.org/info/rfc7187">http://www.rfc-editor.org/info/rfc7187</a>&gt;.

   [<a id="ref-RFC7188">RFC7188</a>]  Dearlove, C. and T. Clausen, "Optimized Link State Routing
              Protocol Version 2 (OLSRv2) and MANET Neighborhood
              Discovery Protocol (NHDP) Extension TLVs", <a href="./rfc7188">RFC 7188</a>,
              DOI 10.17487/RFC7188, April 2014,
              &lt;<a href="http://www.rfc-editor.org/info/rfc7188">http://www.rfc-editor.org/info/rfc7188</a>&gt;.

   [<a id="ref-RFC7466">RFC7466</a>]  Dearlove, C. and T. Clausen, "An Optimization for the
              Mobile Ad Hoc Network (MANET) Neighborhood Discovery
              Protocol (NHDP)", <a href="./rfc7466">RFC 7466</a>, DOI 10.17487/RFC7466, March
              2015, &lt;<a href="http://www.rfc-editor.org/info/rfc7466">http://www.rfc-editor.org/info/rfc7466</a>&gt;.

   [<a id="ref-RFC7859">RFC7859</a>]  Dearlove, C., "Identity-Based Signatures for Mobile Ad Hoc
              Network (MANET) Routing Protocols", <a href="./rfc7859">RFC 7859</a>,
              DOI 10.17487/RFC7859, May 2016,
              &lt;<a href="http://www.rfc-editor.org/info/rfc7859">http://www.rfc-editor.org/info/rfc7859</a>&gt;.

   [<a id="ref-RFC7939">RFC7939</a>]  Herberg, U., Cole, R., Chakeres, I., and T. Clausen,
              "Definition of Managed Objects for the Neighborhood
              Discovery Protocol", <a href="./rfc7939">RFC 7939</a>, DOI 10.17487/RFC7939,
              August 2016, &lt;<a href="http://www.rfc-editor.org/info/rfc7939">http://www.rfc-editor.org/info/rfc7939</a>&gt;.


























<span class="grey">Clausen, et al.               Informational                    [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc8116">RFC 8116</a>                     OLSRv2 Threats                     May 2017</span>


Authors' Addresses

   Thomas Clausen

   Phone: +33-6-6058-9349
   Email: T.Clausen@computer.org
   URI:   <a href="http://www.thomasclausen.org">http://www.thomasclausen.org</a>


   Ulrich Herberg

   Email: ulrich@herberg.name
   URI:   <a href="http://www.herberg.name">http://www.herberg.name</a>


   Jiazi Yi
   Ecole Polytechnique
   91128 Palaiseau Cedex
   France

   Phone: +33 1 77 57 80 85
   Email: jiazi@jiaziyi.com
   URI:   <a href="http://www.jiaziyi.com/">http://www.jiaziyi.com/</a>




























Clausen, et al.               Informational                    [Page 26]
</pre>