Subject: [manet] OLSRv2 sec threats review

From: Justin Dean <[email-masked]>
Date: Mon, 29 Aug 2016 00:33:13 -0400

As there weren't many on list comments during or after last call here
is my detailed review.
Summary is that I'm doing the writeup right now and passing it on up.
Most of my comments
are of the editorial type with exceptions which are minor and mostly
clarification based.

Apologies to the author team for not getting this done sooner; I
wanted to make sure I did it right.

Comments noted as JWD

Network Working Group                                         T. Clausen
Internet-Draft                                                U. Herberg
Intended status: Informational
Expires: November 10, 2016                                         J. Yi
                                                     Ecole Polytechnique
                                                             May 9, 2016

Security Threats for the Optimized Link State Routing Protocol version 2
                                (OLSRv2)
                 draft-ietf-manet-olsrv2-sec-threats-02
Abstract

   This document analyzes common security threats of the Optimized Link
   State Routing Protocol version 2 (OLSRv2) and describes their
   potential impacts on Mobile Ad Hoc Network (MANET) operations.  It
   then 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 Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on November 10, 2016.
Copyright Notice

   Copyright (c) 2016 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
Clausen, et al.         Expires November 10, 2016               [Page
1]Internet-Draft               OLSRv2 Threats                     May
2016

   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.
Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  OLSRv2 Overview  . . . . . . . . . . . . . . . . . . . . .  4
       1.1.1.  Neighborhood Discovery . . . . . . . . . . . . . . . .  4
       1.1.2.  MPR Flooding . . . . . . . . . . . . . . . . . . . . .  5
       1.1.3.  Link State Advertisement . . . . . . . . . . . . . . .  5
     1.2.  Link State Vulnerability Taxonomy  . . . . . . . . . . . .  5
     1.3.  OLSRv2 Attack Vectors  . . . . . . . . . . . . . . . . . .  6
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Topology Map Acquisition . . . . . . . . . . . . . . . . . . .  6
     3.1.  Attack on Jittering  . . . . . . . . . . . . . . . . . . .  7
     3.2.  Hop-count and Hop-limit Attacks  . . . . . . . . . . . . .  7
       3.2.1.  Modifying the Hop Limit  . . . . . . . . . . . . . . .  7
       3.2.2.  Modifying the Hop Count  . . . . . . . . . . . . . . .  8
   4.  Effective Topology . . . . . . . . . . . . . . . . . . . . . .  9
     4.1.  Incorrect Forwarding . . . . . . . . . . . . . . . . . . .  9
     4.2.  Wormholes  . . . . . . . . . . . . . . . . . . . . . . . . 10
     4.3.  Sequence Number Attacks  . . . . . . . . . . . . . . . . . 11
       4.3.1.  Message Sequence Number  . . . . . . . . . . . . . . . 11
       4.3.2.  Advertised Neighbor Sequence Number (ANSN) . . . . . . 11
     4.4.  Indirect Jamming . . . . . . . . . . . . . . . . . . . . . 12
   5.  Inconsistent Topology  . . . . . . . . . . . . . . . . . . . . 14
     5.1.  Identity Spoofing  . . . . . . . . . . . . . . . . . . . . 14
     5.2.  Link Spoofing  . . . . . . . . . . . . . . . . . . . . . . 16
       5.2.1.  Inconsistent Topology Maps due to Link State
               Advertisements . . . . . . . . . . . . . . . . . . . . 16
   6.  Mitigation of Security Vulnerabilities for OLSRv2  . . . . . . 18
     6.1.  Inherent OLSRv2 Resilience . . . . . . . . . . . . . . . . 18
     6.2.  Resilience by using RFC7183 with OLSRv2  . . . . . . . . . 19
       6.2.1.  Topology Map Acquisition . . . . . . . . . . . . . . . 19
       6.2.2.  Effective Topology . . . . . . . . . . . . . . . . . . 20
       6.2.3.  Inconsistent Topology  . . . . . . . . . . . . . . . . 20
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 21
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
Clausen, et al.         Expires November 10, 2016               [Page
2]Internet-Draft               OLSRv2 Threats                     May
2016
1.  Introduction

   The Optimized Link State Routing Protocol version 2 (OLSRv2)
   [RFC5148], [RFC5444], [RFC5497], [RFC6130], [RFC7181], [RFC7182],
   [RFC7183], [RFC7187], [RFC7188] is a successor to OLSR [RFC3626] as a
   routing protocol for MANETs (Mobile Ad hoc NETworks).  OLSRv2 retains
   the same basic algorithms as its predecessor, however 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.

[JWD] NIT: listing RFC7181 first would be helpful.

   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 presented 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 with the assumption, that participants can
   be "trusted" to behave in a non-destructive way, is utopia.  Taking
   the Internet as an example, as participation in the network increases
   and becomes more diverse, more efforts are required to preserve the
   integrity and operation of the network.  Most SMTP-servers were,
   e.g., initially available for use by everyone on the Internet - with
   an increased populace on the Internet, attacks and abuses caused the
   recommended practice is today to require authentication and
   accounting for users of such SMTP servers [RFC5068].

[JWD] NIT language improvement....with an increase in users on the Internet,
an increase in attacks and abuses followed necessitating a change in
recommended
practices; today authentication and accounting for users is required
for use of SMTP servers [RFC5068].

   As OLSRv2 often is used in wireless environments, it is potentially
   exposed to different kinds of security threats, some of which are of
   particular significance as compared to wired networks.  As radio
   signals can be received as well as transmitted by any compatible
   wireless device within radio range, there is commonly no physical
   protection as otherwise known for wired networks.

   A first step towards hardening against attacks disrupting the
   connectivity of a network, is to understand the vulnerabilities of
   routing protocol, managing the connectivity.  This document therefore
   analyzes OLSRv2, to understand its inherent vulnerabilities and
   resiliences.  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 secured
   OLSRv2 networks.

   This document first describes security vulnerabilities to OLSRv2 when
   it is used without the mandatory-to-implement security mechanisms, as
   specified in Section 23.5 of [RFC7181].  It then 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.         Expires November 10, 2016               [Page
3]Internet-Draft               OLSRv2 Threats                     May
2016

   vulnerabilities are mitigated.  This separation is important since
   other security mechanisms ([JWD] other) than the
mandatory-to-implement ones may be
   used in a deployment, 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).

   The threats related to NHDP (Neighborhood Discovery Protocol) have
   been discussed in [RFC7186].  As NHDP is a fundamental block of
   OLSRv2, the vulnerabilities of NHDP apply also to OLSRv2.

   It should be noted that many OLSRv2 implementations are configurable,
   and so an attack on the configuration system (such as [RFC6779] 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, MPR
   Flooding ([JWD] MPR election/flooding not just flooding?) and Link
State Advertisements, described in the below with
   sufficient details for elaborating the analyses in this document.

[JWD] NIT make above two separate sentences.

1.1.1.  Neighborhood Discovery

   Neighborhood Discovery is the process, whereby each router discovers
   the routers which are in direct communication range of itself (1-hop
   neighbors), and detects with which of these it can establish bi-
   directional 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 bi-directional).  A router A receiving a
   HELLO message from a neighbor B, in which B indicates to have
   recently received a HELLO message from A, considers the link A-B to
   be bi-directional.  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.         Expires November 10, 2016               [Page
4]Internet-Draft               OLSRv2 Threats                     May
2016
1.1.2.  MPR Flooding

   Multi Point Relay (MPR) Flooding is the process whereby each router
   is able to efficiently conduct network-wide broadcasts.  Each router
   designates, from among its bi-directional neighbors, a subset (MPR
   set) such that a multicast ([JWD] OLSRv2 specific multicast)
message transmitted by the router and
   relayed by the MPR set can ([JWD] be) received by all its 2-hop
neighbors.  MPR
   selection is encoded in outgoing HELLO messages. ([JWD] NHDP HELLO messages)

   Routers may express, in their HELLO messages, their "willingness" (an
   integer between 0 "will never" and 7 "will always") to be selected as
   MPR, which is taken into consideration for the MPR calculation, and
   which is useful for example when an OLSRv2 network is "planned".  The
   set of routers having selected a given router as 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 is the process whereby routers are
   determining ([JWD] 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 link state advertisements are carried
   in Topology Control (TC) messages, broadcast through the network
   using the MPR flooding process described above.  As a router selects
   MPRs only from among bi-directional neighbors, links advertised in TC
   are also bi-directional and routing paths calculated by OLSRv2
   contain only bi-directional 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 (i) each router signals its
   presence in the network and the topology information that it obtained
   honestly, (ii) each router can acquire and maintain a topology map,
   accurately reflecting the effective network topology; and (iii) that
   the network converges, i.e., that all routers in the network will
   have sufficiently identical topology maps.

[JWD] Nit make above a list.

   An OLSRv2 network can be disrupted by breaking either ([JWD] any
not either) of these
   assumptions, specifically (a) routers may be prevented from acquiring
   a topology map of the network; (b) routers may acquire a topology map
   that does not reflect the effective network topology; and (c) two or
   more routers may acquire inconsistent topology maps.
Clausen, et al.         Expires November 10, 2016               [Page
5]Internet-Draft               OLSRv2 Threats                     May
2016
1.3.  OLSRv2 Attack Vectors

   Besides "radio jamming", attacks on OLSRv2 consist of a compromised
   OLSRv2 router injecting "correctly looking, but invalid, control
   traffic" (TCs, HELLOs) into the network.  A compromised OLSRv2 router
   can either (a) lie about itself (its identification, its willingness
   to serve as MPR), henceforth Identity Spoofing, or (b) lie about its
   relationship to other routers (pretend existence of links to other
   routers), henceforth Link Spoofing.  Such attacks may disrupt the the
   Link State Advertisement process, through 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.
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 is present in the
      network and 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, 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
   to 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.
Clausen, et al.         Expires November 10, 2016               [Page
6]Internet-Draft               OLSRv2 Threats                     May
2016

   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: 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 to 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, and the legitimate message will be discarded as ([JWD] 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.  A compromised OLSRv2 router can modify
   either of these when forwarding TCs.

[JWD] mention of the integrity TLV here which makes this statement
true would be helpful.

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 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 illustrated in
   Figure 1.
Clausen, et al.         Expires November 10, 2016               [Page
7]Internet-Draft               OLSRv2 Threats                     May
2016

                            .---.
                            | 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
   arrives 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 by, 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(1hop)=2s  v_time(2hops)=4s   v_time(3hops)=6s
   .---.         .---.          .---.           .---.
   | 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 two seconds
   for neighbors that are one hop away, four seconds for routers in a
   two-hop distance and six seconds in a three-hop distance.  If X is a
   compromised OLSRv2 router and modifies the hop count (say, by
   decreasing it to 0), then C will calculate the validity time of
   received information to two seconds - after which it expires unless
Clausen, et al.         Expires November 10, 2016               [Page
8]Internet-Draft               OLSRv2 Threats                     May
2016

   refreshed.  If TCs from A are sent less frequently than that up to 3
   hops, this causes links advertised in such TCs to be only
   intermittently available to C.

[JWD] this is a really good point!

 4.  Effective Topology

   Link-state protocols assume that each router can acquire an accurate
   topology map, reflecting the effective network topology.  This
   implies that the routing protocol, through its message exchange,
   identifies 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.

   Considering 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, effectively, 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 attack,
   indirect channel overloading have been 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,
Clausen, et al.         Expires November 10, 2016               [Page
9]Internet-Draft               OLSRv2 Threats                     May
2016

   cause a discrepancy between the effective topology and the topology
   map, as indicated in Figure 3(a) and Figure 3(b).

[JWD] the term unicast forwarding should be used as without that term it may
be assumed that forwarding of multicast is being disrupted which isn't the case.

   This situation is not hypothetical.  A common error seen when
   deploying OLSRv2-based networks using Linux-based computers as 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, 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 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 depends 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 applies.  If, however, the wormhole relays all traffic,
   control and data alike, it is connectivity-wise identical to a usable
   link - and the routing protocol will correctly generate a topology
   map reflecting the effective network topology.  The efficiency of the
   topology so 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 was a path of more than
   100 hops (e.g., with respect to delay, bandwidth, etc.), then the
Clausen, et al.         Expires November 10, 2016              [Page
10]Internet-Draft               OLSRv2 Threats                     May
2016

   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.

   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, 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 regards to wormholes is, that such
   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 (ii) to ensure that old information, arriving
   late due to, e.g., long paths or other delays, is not allowed to
   overwrite fresher information (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.

[JWD] it should be mentioned that this is fixed with the signing TLV.

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 fresh information" and discard subsequent TCs with lower
   sequence numbers as being "old".
[JWD] again it should be mentioned that this is fixed with the signing TLV.
Clausen, et al.         Expires November 10, 2016              [Page
11]Internet-Draft               OLSRv2 Threats                     May
2016
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, respectively, the
   Neighborhood Discovery mechanism and the Link State Advertisement
   mechanism.

   The most 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 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.         Expires November 10, 2016              [Page
12]Internet-Draft               OLSRv2 Threats                     May
2016

              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

   Figure 5: Indirect Jamming in Link State Advertisement: the malicious
                 X flips between link status MPR and LOST.

   Routers receiving a TC 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 is a potentially
   computationally costly operation.

   A compromised OLSRv2 router may chose to conduct this attack against
   all its neighbors, thus attaining maximum 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 zero (thus, avoid being selected as 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.
   This attack can cause the TC interval to, permanently, become equal
Clausen, et al.         Expires November 10, 2016              [Page
13]Internet-Draft               OLSRv2 Threats                     May
2016

   to the minimum message interval.  [RFC7181] proposes as default that
   the minimum TC interval be 0.25 x TC interval.
[JWD glad this was mentioned.  Something might be said regarding the reduced
effectiveness of the compromised node is not ever selected as an MPR as the
calculation for routing might only affect a leaf router (dependent on
implementation)

   Indirect Jamming by a compromised OLSRv2 router can thus have two
   effects: it may cause increased frequency of TC generation and
   transmission, and 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 of 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 Link State
   Advertisement process.  Either of them causes inconsistent topology
   maps in routers in the network.  The inconsistent topology maps due
   to neighborhood discovery has been discussed in [RFC7186].  For
   OLSRv2, the attack on link state advertisements can also cause
   inconsistent topology maps.

   An inconsistent topology map may occur when the compromised OLSRv2
   router takes part in the Link State Advertisement (LSA) procedure, by
   selecting a neighbor as 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.

[JWD] this is the only play that the term LSA is used.  Suggest removing it.

[JWD] also it should be mentioned that spoofing is protected against
if using the SHOULD use TLVs

   A -- B -- C -- D -- E -- F -- X

                               (X spoofs A)

    Figure 6: Identity Spoofing: compromised OLSRv2 router X spoofs the
          identity of A, leading to a wrongly perceived topology.

   In Figure 6, router X spoofs the address of router A. If X selects F
   as 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 selects
   B as MPR, the link B-A will also be advertised in the network.
Clausen, et al.         Expires November 10, 2016              [Page
14]Internet-Draft               OLSRv2 Threats                     May
2016

   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: 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(b).

   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 one hop away from A will be
      unable to detect this identity spoofing.

   The identity spoofing attack via the Link State Advertisement
   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)

     Figure 7: Routing paths towards A, as calculated by the different
   routers in the network in presence of a compromised OLSRv2 router X,
                        spoofing the address of A.

   As the compromised OLSRv2 router X does not itself send the TCs, but
   rather, by virtue of MPR selection, ensures that the addresses it
Clausen, et al.         Expires November 10, 2016              [Page
15]Internet-Draft               OLSRv2 Threats                     May
2016

   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.

   Identity spoofing by a compromised OLSRv2 router, participating in
   the Link State Advertisement process by selecting MPRs only, thus,
   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.

[JWD] Link State Advertisement is again used here suggest lowercase.

 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 which are, either,
   not present in the network, or which 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 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.

[JWD] this is a similar attack to the above but is not protected against
but the attacker is more easily identified.  One difference is that TC
messages with spoofed links may be hop count limited making detection
more difficult.
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 a existing router A by participating in the
   Link State Advertisement 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)

   Figure 8: Link Spoofing: The compromised OLSRv2 router X advertises a
Clausen, et al.         Expires November 10, 2016              [Page
16]Internet-Draft               OLSRv2 Threats                     May
2016

    spoofed link to A in its TCs, thus all routers will record both of
                          the links X-A and B-A.

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

      Figure 9: Routing paths towards router A, as calculated by the
   different routers in the network in presence of a compromised OLSRv2
                  router X, spoofing a link to router A.

   In general, the following observations can be made:

   o  The network will be separated in two, with those routers closer to
      B than to X reaching A, whereas those routers closer to X than to
      B unable to reach A.

   o  Routers beyond B, i.e., routers beyond one hop away from A will be
      unable to detect this link spoofing.

   The impact of this attack is similar to that presented in
   Section 5.2.1, however, is easier to detect as the compromised OLSRv2
   router is generating control traffic reaching the entire network.
Clausen, et al.         Expires November 10, 2016              [Page
17]Internet-Draft               OLSRv2 Threats                     May
2016
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], as well as the protection that
   [RFC7183] provides when used in a deployment.
6.1.  Inherent OLSRv2 Resilience

   OLSRv2 (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,
      specific per router identity and message type.  Routers keep an
      "information freshness" number (ANSN), incremented each time the
      content of a Link State Advertisement from a router changes.  This
      allows rejecting "old" information and duplicate messages, and
      provides some protection against "message replay".  This, however,
      also presents an attack vector (Section 4.3).

   o  Ignoring uni-directional links: The Neighborhood Discovery process
      detects and admits only bi-directional links for use in MPR
      selection and Link State Advertisement.  Jamming attacks may
      affect only reception of control traffic, however OLSRv2 will
      correctly recognize, and ignore, such a link as not bi-
      directional.

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

   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.  This allows - together with the
      flexible message format [RFC5444] - addition of security
      mechanisms, such as digital signatures, while remaining compliant
      with the OLSRv2 standard specification.
Clausen, et al.         Expires November 10, 2016              [Page
18]Internet-Draft               OLSRv2 Threats                     May
2016
6.2.  Resilience by using RFC7183 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 a digital signature of the
   content of the message using 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 a non-valid 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 (in addition to using asymmetric keys, allowing to revoke
   access to one particular router instead of revoking the shared key
   used by all routers in the MANET).

   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.

[JWD] this is a really important part of the document and should be moved
up to provide the reader with a better understanding.  Without this it will
be easy for a reader to assume that all attacks presented are equally possible.
A summary was given but more details (along with an inline sentence per attack
pointing to appropriate section below) would help quite a lot.

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 zero jitter interval, the message arrives before the
      same message forwarded by legitimate routers.

   Modifying the Hop Limit -  As the hop limit is not protected by
      [RFC7183] (since it is a mutual field, changing at every hop),
      this attack is still feasible.
Clausen, et al.         Expires November 10, 2016              [Page
19]Internet-Draft               OLSRv2 Threats                     May
2016

   Modifying the Hop Count -  Similarly to the hop limit, as the hop
      count is not protected by [RFC7183] (since it is a mutual field,
      changing at every hop), this attack is still feasible.
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.
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, in particular when using identity based
      signatures, such as specified in [IBS] may further allow to revoke
      single routers and to verify their identity based on the ICV
      itself.
Clausen, et al.         Expires November 10, 2016              [Page
20]Internet-Draft               OLSRv2 Threats                     May
2016

   Link Spoofing -  Similar to identity spoofing, a malicious router
      without valid credential may spoof links, but its control messages
      will be rejected by other routers, thereby mitigating the attack.

   Inconsistent Topology Maps due to Link State Advertisements -  The
      same considerations as for link spoofing apply.
7.  Security Considerations

   This document does not specify a protocol or a procedure.  The
   document, however, reflects on security considerations for OLSRv2,
   and its constituent parts, including NHDP.
8.  IANA Considerations

   This document has no actions for IANA.
9.  References
9.1.  Normative References

   [RFC7181]  Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
              "The Optimized Link State Routing Protocol Version 2",
              RFC 7181, April 2014.

   [RFC7186]  Yi, J., Herberg, U., and T. Clausen, "Security Threats for
              the Neighborhood Discovery Protocol (NHDP)", RFC 7186,
              April 2014.
9.2.  Informative References

   [FUNKFEUER]
              "http://www.funkfeuer.at/".

   [IBS]      Dearlove, C., "Identity-Based Signatures for MANET Routing
              Protocols", work in progress draft-ietf-manet-ibs-05,
              March 2016.

   [IEEE802.11]
              "IEEE 802.11: Wireless LAN Medium Access Control (MAC) and
              Physical Layer (PHY) Spec.", 2007.

   [MPR-FLOODING]
              Qayyum, A., Viennot, L., and A. Laouiti, "Multipoint
              relaying: An efficient technique for flooding in mobile
Clausen, et al.         Expires November 10, 2016              [Page
21]Internet-Draft               OLSRv2 Threats                     May
2016

              wireless networks.", 2001.

   [OLSR-FSR]
              Clausen, T., "Combining Temporal and Spatial Partial
              Topology for MANET routing-Merging OLSR and FSR,
              Proceedings of the 2003 IEEE Conference of Wireless
              Personal Multimedia Communications (WPMC 03)", 2003.

   [OLSR-FSR-Scaling]
              Adjih, C., Baccelli, E., Clausen, T., Jacquet, P., and G.
              Rodolakis, "Fish eye OLSR scaling properties, IEEE Journal
              of Communication and Networks (JCN), Special Issue on
              Mobile Ad Hoc Wireless Networks", 2004.

   [RFC3626]  Clausen, T. and P. Jacquet, "The Optimized Link State
              Routing Protocol", RFC 3626, October 2003.

   [RFC5068]  Hutzler, C., Crocker, D., Resnick, P., Allman, E., and T.
              Finch, "Email Submission Operations: Access and
              Accountability Requirements", RFC 5068, BCP 134,
              October 2007.

   [RFC5148]  Clausen, T., Dearlove, C., and B. Adamson, "Jitter
              Considerations in Mobile Ad Hoc Networks (MANETs)",
              RFC 5148, February 2008.

   [RFC5444]  Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
              "Generalized MANET Packet/Message Format", RFC 5444,
              February 2009.

   [RFC5497]  Clausen, T. and C. Dearlove, "Representing Multi-Value
              Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497,
              March 2009.

   [RFC6130]  Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
              Network (MANET) Neighborhood Discovery Protocol (NHDP)",
              RFC 6130, April 2011.

   [RFC6779]  Herberg, U., Cole, R., and I. Chakeres, "Definition of
              Managed Objects for the Neighborhood Discovery Protocol",
              RFC 6779, May 2012.

   [RFC7182]  Herberg, U., Clausen, T., and C. Dearlove, "Integrity
              Check Value and Timestamp TLV Definitions for Mobile Ad
              Hoc Networks (MANETs)", RFC 7182, April 2014.

   [RFC7183]  Herberg, U., Dearlove, C., and T. Clausen, "Integrity
              Protection for the Neighborhood Discovery Protocol (NHDP)
Clausen, et al.         Expires November 10, 2016              [Page
22]Internet-Draft               OLSRv2 Threats                     May
2016

              and Optimized Link State Routing Protocol Version 2
              (OLSRv2)", RFC 7183, April 2014.

   [RFC7184]  Herberg, U., Cole, R., and T. Clausen, "Definition of
              Managed Objects for the Optimized Link State Routing
              Protocol Version 2", RFC 7184, April 2014.

   [RFC7187]  Dearlove, C. and T. Clausen, "Routing Multipoint Relay
              Optimization for the Optimized Link State Routing Protocol
              Version 2 (OLSRv2)", RFC 7187, April 2014.

   [RFC7188]  Dearlove, C. and T. Clausen, "Optimized Link State Routing
              Protocol Version 2 (OLSRv2) and MANET Neighborhood
              Discovery Protocol (NHDP) Extension TLVs", RFC 7188,
              April 2014.
Authors' Addresses

   Thomas Clausen

   Phone: +33-6-6058-9349
   Email: [email-masked]
   URI:   http://www.thomasclausen.org

   Ulrich Herberg

   Email: [email-masked]
   URI:   http://www.herberg.name

   Jiazi Yi
   Ecole Polytechnique
   91128 Palaiseau Cedex,
   France

   Phone: +33 1 77 57 80 85
   Email: [email-masked]
   URI:   http://www.jiaziyi.com/
Clausen, et al.         Expires November 10, 2016              [Page 23]

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 29 Aug 2016 08:25:02 +0200

Thanks Justin,

I would add my quick comments,

On Mon, Aug 29, 2016 at 6:33 AM, Justin Dean <[email-masked]> wrote:

> As there weren't many on list comments during or after last call here is my detailed review.
> Summary is that I'm doing the writeup right now and passing it on up.  Most of my comments
> are of the editorial type with exceptions which are minor and mostly clarification based.
>
> Apologies to the author team for not getting this done sooner; I wanted to make sure I did it right.
>
>
> Comments noted as JWD
>
>
>
>
> Clausen, et al.         Expires November 10, 2016               [Page 1]Internet-Draft               OLSRv2 Threats                     May 2016
>
> Clausen, et al.         Expires November 10, 2016               [Page 2]Internet-Draft               OLSRv2 Threats                     May 2016
> 1.  Introduction
>
> [AB] why the introduction says basic algorithms as OLSRv1, it is
confusing, I think they are not having similar procedures. The plural of
algorithms even makes it confused. It is better to say 'basic algorithm'.

> an increase in attacks and abuses followed necessitating a change in recommended
> practices; today authentication and accounting for users is required for use of SMTP servers [RFC5068].
>
>
> [AB] it should not only say about wireless and wired, but what about
Mobile environment, OLSRv2 is for MANET, so it is not only for wireless.
Threats are more in Mobile environment than Wireless environment. So please
add some words about the different threats for OLSRv2 in Mobile, in
addition to the threats in wireless. Otherwise the draft needs to state
what states that are mobile environment threats, or what states are covered
in the draft.

We need for threats, to define the environment under study/analysis, or the
scenarios. I don't know if IETF they do this or not for threat document,
but IMHO it is very important to have some basic mobile scenarios.

>    starting-point for developing and deploying increasingly secured
So the analysis is not complete, we need to say why? if we say why it will
be good for future work to solve the issue. However, we can describe the
analysis as simple-analysis or any other word ( basic, general, ,,,,), that
will help the reader understand that there may be future analysis that will
use this draft as its start for more deep/specific/complete analysis.

> Clausen, et al.         Expires November 10, 2016               [Page 3]Internet-Draft               OLSRv2 Threats                     May 2016
>
>    other security mechanisms ([JWD] other) than the mandatory-to-implement ones may be
> [AB] I cannot understand the paragraph, I think there is edit error in
lines of-------  system and can be used ....

will continue review,

Regards
AB

---

From: Jiazi YI <[email-masked]>
Date: Tue, 30 Aug 2016 10:24:43 +0200

Thanks very much for the review, Justin.

We will update the draft based on the comments received and make a
submission soon.

regards

Jiazi

On Mon, Aug 29, 2016 at 6:33 AM, Justin Dean <[email-masked]> wrote:

>    Flooding ([JWD] MPR election/flooding not just flooding?) and Link State Advertisements, described in the below with
> Clausen, et al.         Expires November 10, 2016               [Page 4]Internet-Draft               OLSRv2 Threats                     May 2016
> 1.1.2.  MPR Flooding
>
>    set) such that a multicast ([JWD] OLSRv2 specific multicast) message transmitted by the router and
>    relayed by the MPR set can ([JWD] be) received by all its 2-hop neighbors.  MPR
>    determining ([JWD] routers determine) which link state information to advertise through the
>    An OLSRv2 network can be disrupted by breaking either ([JWD] any not either) of these
> Clausen, et al.         Expires November 10, 2016               [Page 5]Internet-Draft               OLSRv2 Threats                     May 2016
> Clausen, et al.         Expires November 10, 2016               [Page 6]Internet-Draft               OLSRv2 Threats                     May 2016
>
> [JWD] mention of the integrity TLV here which makes this statement true would be helpful.
>
>
> Clausen, et al.         Expires November 10, 2016               [Page 7]Internet-Draft               OLSRv2 Threats                     May 2016
>
>                             .---.
>                             | X |
>                           --'---' __
>                          /          \
>                         /            \
>                     .---.              .---.
>         TC ----->   | A |              | C |
>                     '---'              '---'
>                         \    .---.   /
>                          \-- | B |__/
>                              '---'
>
> Clausen, et al.         Expires November 10, 2016               [Page 8]Internet-Draft               OLSRv2 Threats                     May 2016
>
> Clausen, et al.         Expires November 10, 2016               [Page 9]Internet-Draft               OLSRv2 Threats                     May 2016
>
> Clausen, et al.         Expires November 10, 2016              [Page 10]Internet-Draft               OLSRv2 Threats                     May 2016
>
> Clausen, et al.         Expires November 10, 2016              [Page 11]Internet-Draft               OLSRv2 Threats                     May 2016
> 4.4.  Indirect Jamming
>
> Clausen, et al.         Expires November 10, 2016              [Page 12]Internet-Draft               OLSRv2 Threats                     May 2016
>
> Clausen, et al.         Expires November 10, 2016              [Page 13]Internet-Draft               OLSRv2 Threats                     May 2016
>
> calculation for routing might only affect a leaf router (dependent on implementation)
>
> [JWD] also it should be mentioned that spoofing is protected against if using the SHOULD use TLVs
>
> Clausen, et al.         Expires November 10, 2016              [Page 14]Internet-Draft               OLSRv2 Threats                     May 2016
>
> Clausen, et al.         Expires November 10, 2016              [Page 15]Internet-Draft               OLSRv2 Threats                     May 2016
>
> messages with spoofed links may be hop count limited making detection more difficult.
> Clausen, et al.         Expires November 10, 2016              [Page 16]Internet-Draft               OLSRv2 Threats                     May 2016
>
> Clausen, et al.         Expires November 10, 2016              [Page 17]Internet-Draft               OLSRv2 Threats                     May 2016
> Clausen, et al.         Expires November 10, 2016              [Page 18]Internet-Draft               OLSRv2 Threats                     May 2016
> Clausen, et al.         Expires November 10, 2016              [Page 19]Internet-Draft               OLSRv2 Threats                     May 2016
>
> Clausen, et al.         Expires November 10, 2016              [Page 20]Internet-Draft               OLSRv2 Threats                     May 2016
>
> Clausen, et al.         Expires November 10, 2016              [Page 21]Internet-Draft               OLSRv2 Threats                     May 2016
>
> Clausen, et al.         Expires November 10, 2016              [Page 22]Internet-Draft               OLSRv2 Threats                     May 2016
>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 30 Aug 2016 09:11:22 +0000

Looking at Justin’s comments means I’ve caught an error, or at least a “don’t do that”.

   two-hop distance and six seconds in a three-hop distance.

Those look more like interval times than validity times with default parameters (which it’s easiest to use as an example). I suggest multiplying by three. But then …

That’s a bad pattern of validity times. It’s legal under 5497 (I think), but I don’t have the time right now to determine if it violates a MUST or a SHOULD for OLSRv2. I think it does, but in any case it’s a bad pattern we don’t want to suggest.

That’s because you can’t send messages at two second intervals with any pattern of hop limits that means each node sees a regular pattern of messages with appropriate intervals.

Easy fix, change the six to eight. Or with the tripling suggestion above, 24.

Also, it’s a bad example in another way. It suggests sending some TC messages only one hop. But one hop TC messages are pretty useless, everything you need from them is in a HELLO message - unless you have any attached networks. To avoid people having to go down that cul de sac (one hop, useless, unless attached networks, not mentioned) I’d use two, three and four hops rather than one, two and three. (Might mean other changes.)

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________

T:  +44 (0)1245 242194  |  E: [email-masked]<mailto:[email-masked]>

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai<http://www.baesystems.com/ai>
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 30 Aug 2016 09:15:15 +0000

Also, draft-ietf-manet-ibs-05 is RFC 7859.

T:  +44 (0)1245 242194  |  E: [email-masked]

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP