Skip to main content

Security Threats for the Neighborhood Discovery Protocol (NHDP)

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7186.
Authors Jiazi Yi , Ulrich Herberg , Thomas H. Clausen
Last updated 2020-01-21 (Latest revision 2013-06-17)
RFC stream Internet Engineering Task Force (IETF)
Additional resources Mailing list discussion
Stream WG state Submitted to IESG for Publication
Document shepherd Joseph P. Macker
Shepherd write-up Show Last changed 2013-05-23
IESG IESG state RFC 7186 (Informational)
Consensus boilerplate Yes
Telechat date (None)
Responsible AD Adrian Farrel
IESG note Joe Macker <> is the document shepherd
Send notices to (None)
IANA IANA review state Version Changed - Review Needed
IANA action state No IANA Actions
Mobile Ad hoc Networking (MANET)                                   J. Yi
Internet-Draft                                  LIX, Ecole Polytechnique
Intended status: Informational                                U. Herberg
Expires: December 19, 2013               Fujitsu Laboratories of America
                                                              T. Clausen
                                                LIX, Ecole Polytechnique
                                                           June 17, 2013

                       Security Threats for NHDP


   This document analyzes common security threats of the Neighborhood
   Discovery Protocol (NHDP), and describes their potential impacts on
   MANET routing protocols using NHDP.  This document is not intended to
   propose solutions to the threats described.

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

   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 December 19, 2013.

Copyright Notice

   Copyright (c) 2013 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
   ( 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

Yi, et al.              Expires December 19, 2013               [Page 1]
Internet-Draft          Security Threats for NHDP              June 2013

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  NHDP Threat Overview . . . . . . . . . . . . . . . . . . . . .  4
   4.  Detailed Threat Description  . . . . . . . . . . . . . . . . .  5
     4.1.  Jamming  . . . . . . . . . . . . . . . . . . . . . . . . .  5
     4.2.  Denial of Service Attack . . . . . . . . . . . . . . . . .  5
     4.3.  Eavesdropping and Traffic Analysis . . . . . . . . . . . .  6
     4.4.  Incorrect HELLO Message Generation . . . . . . . . . . . .  7
       4.4.1.  Identity Spoofing  . . . . . . . . . . . . . . . . . .  7
       4.4.2.  Link Spoofing  . . . . . . . . . . . . . . . . . . . .  8
     4.5.  Replay Attack  . . . . . . . . . . . . . . . . . . . . . .  9
     4.6.  Message Timing Attacks . . . . . . . . . . . . . . . . . .  9
       4.6.1.  Interval Time Attack . . . . . . . . . . . . . . . . .  9
       4.6.2.  Validity Time Attack . . . . . . . . . . . . . . . . . 10
     4.7.  Indirect Channel Overloading . . . . . . . . . . . . . . . 10
     4.8.  Attack on Link Quality Update  . . . . . . . . . . . . . . 11
   5.  Impact of inconsistent Information Bases on Protocols
       using NHDP . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     5.1.  MPR Calculation  . . . . . . . . . . . . . . . . . . . . . 12
       5.1.1.  Flooding Disruption due to Identity Spoofing . . . . . 12
       5.1.2.  Flooding Disruption due to Link Spoofing . . . . . . . 13
       5.1.3.  Broadcast Storm  . . . . . . . . . . . . . . . . . . . 14
     5.2.  Routing Loops  . . . . . . . . . . . . . . . . . . . . . . 15
     5.3.  Invalid or Non-Existing Paths to Destinations  . . . . . . 15
     5.4.  Data Sinkhole  . . . . . . . . . . . . . . . . . . . . . . 16
   6.  Future Work  . . . . . . . . . . . . . . . . . . . . . . . . . 16
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 17
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
     10.2. Informative References . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19

Yi, et al.              Expires December 19, 2013               [Page 2]
Internet-Draft          Security Threats for NHDP              June 2013

1.  Introduction

   The Neighborhood Discovery Protocol (NHDP) [RFC6130] allows routers
   to acquire topological information up to two hops away from
   themselves, by way of periodic HELLO message exchanges.  The
   information acquired by NHDP is used by other protocols, such as
   OLSRv2 [I-D.ietf-manet-olsrv2] and SMF [RFC6621].  The topology
   information, acquired by way of NHDP, serves these routing protocols
   by detecting and maintaining local 1-hop and 2-hop neighborhood

   As NHDP is typically 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.  NHDP does not
   define any explicit security measures for protecting the integrity of
   the information it acquires, however suggests that the integrity
   protection be addressed in a fashion appropriate to the deployment of
   the network.

   This document is based on the assumption that no additional security
   mechanism such as IPsec is used in the IP layer, as not all MANET
   deployments may be suitable to deploy common IP protection mechanisms
   (e.g., because of limited resources of MANET routers to support the
   IPsec stack).  The document analyzes possible attacks on and mis-
   configurations of NHDP and outlines the consequences of such attacks/
   mis-configurations to the state maintained by NHDP in each router
   (and, thus, made available to protocols using this state).

   This document is not intended to propose solutions to the threats
   described.  [I-D.ietf-manet-nhdp-olsrv2-sec] provides further
   information on how to enable integrity protection to NHDP, which can
   help mitigating the threats described related to identity spoofing.

   It should be noted that many NHDP implementations are configurable
   and so an attack on the configuration system (such as [RFC6779]) can
   be used to adversely affect the operation of an NHDP implementation.

   The NHDP MIB module [RFC6779] might help monitoring some of the
   security attacks mentioned in this document.  Note that,
   [I-D.nguyen-manet-management] contains specific guidelines on MANET
   network management, taking into account the specific nature of

Yi, et al.              Expires December 19, 2013               [Page 3]
Internet-Draft          Security Threats for NHDP              June 2013

2.  Terminology

   This document uses the terminology and notation defined in [RFC5444],
   NHDP [RFC6130] and [RFC4949].

   Additionally, this document introduces the following terminology:

   NHDP Router:  A MANET router, running NHDP as specified in [RFC6130].

   Attacker:  A device, present in the network and which intentionally
      seeks to compromise the information bases in NHDP routers.

   Compromised NHDP Router:  An attacker, present in the network and
      which generates syntactically correct NHDP control messages.
      Control messages emitted by a Compromised NHDP router may contain
      additional information, or omit information, as compared to a
      control message generated by a non-compromized NHDP router located
      in the same topological position in the network.

   Legitimate NHDP Router:  An NHDP router, which is not a Compromised
      NHDP Router.

3.  NHDP Threat Overview

   NHDP defines a HELLO messages exchange, enabling each NHDP Router to
   acquire topological information describing its 1-hop and 2-hop
   neighbors, and specifies information bases for recording this

   An NHDP Router periodically transmits HELLO messages using a link-
   local multicast on each of its interfaces with a hop-limit of 1
   (i.e., HELLOs are never forwarded).  In these HELLO messages, an NHDP
   Router announces the IP addresses as heard, symmetric or lost
   neighbor interface addresses.

   An Attacker has several ways of harming this neighbor discovery
   process: It can announce "wrong" information about its identity,
   postulate non-existent links, and replay HELLO messages.  These
   attacks are presented in detail in Section 4.

   The different ways of attacking an NHDP deployment may eventually
   lead to inconsistent information bases, not accurately reflecting the
   correct topology of the MANET.  The consequence hereof is that
   protocols using NHDP will base their operation on incorrect
   information, causing routing protocols to not be able to calculate
   correct (or any) paths, degrade the performance of flooding
   operations based on reduced relay sets, etc.  These consequences to

Yi, et al.              Expires December 19, 2013               [Page 4]
Internet-Draft          Security Threats for NHDP              June 2013

   protocols using NHDP are described in detail in Section 5.

4.  Detailed Threat Description

   For each threat, described in the below, a description of the
   mechanism of the corresponding attack is given, followed by a
   description of how the attack affects NHDP.  The impacts from each
   attack on protocols using NHDP are given in Section 5.

   For simplicity in the description, examples given assume that NHDP
   Routers have a single interface with a single IP address configured.
   All the attacks apply, however, for NHDP Routers with multiple
   interfaces and multiple addresses as well.

4.1.  Jamming

   One vulnerability, common for all protocols operating a wireless ad
   hoc network, is that of "jamming", i.e., that a device generates
   massive amounts of interfering radio transmissions, which will
   prevent legitimate traffic (e.g.,control traffic as well as data
   traffic) on part of a network.  Jamming is a form of Interference and
   Overload with threat consequences of Disruption [RFC4593].

   Depending on lower layers, this may not affect transmissions: HELLO
   messages from an NHDP Router with "jammed" interfaces may be received
   by other NHDP Routers.  As NHDP identifies whether a link to a
   neighbor is uni-directional or bi-directional, a routing protocol
   that uses NHDP for neighborhood discovery may ignore a link from a
   jammed NHDP Router to a non-jammed NHDP Router.  The jammed router (a
   router with jammed carrier) would appear simply as "disconnected" for
   the un-jammed part of the network - which is able to maintain
   accurate topology maps.

   If, due to a jamming attack, a considerable amount of HELLO messages
   are lost or corrupted due to collisions, neighbor NHDP Routers are
   not able to establish links between themselves any more.  Thus, NHDP
   will present empty information bases to the protocols using it.

4.2.  Denial of Service Attack

   A Denial of Service (DoS) attack can be a result of misconfiguration
   of Legitimate NHDP Routers (e.g., very short HELLO transmission
   interval) or malicious behavior of Compromised NHDP Routers
   [ACCT2012], so called byzantine routers [RFC4593].  DoS is a form of
   Interference and Overload with threat consequences of Disruption

Yi, et al.              Expires December 19, 2013               [Page 5]
Internet-Draft          Security Threats for NHDP              June 2013

   By transmitting a huge amount of HELLO messages in a short period of
   time, NHDP Routers can increase channel occupation as introduced in
   Section 4.1.  Furthermore, a Compromised NHDP Router can spoof a
   large amount of different IP addresses, and send HELLOs to its
   neighbors to fill their Link/Neighbor Sets.  This may result in
   memory overflow, and makes the processing of legitimate HELLO
   messages impossible.  A Compromised NHDP Router can also use link
   spoofing in its HELLO messages, generating huge 2-hop Sets in
   adjacent NHDP Routers and therefore potentially a memory overflow.
   Moreover, protocols such as SMF and OLSRv2, using the 2-hop
   information for MPR calculation, may exhaust the available
   computational resources of the router if the Neighbor Set and 2-hop
   Sets have too many entries.

   By exhausting the memory, CPU, or (and) channel resources of a router
   in a DoS attack or a misconfiguration, NHDP Routers may not be able
   to accomplish their specified tasks of exchanging 1-hop and 2-hop
   neighborhood information, and thereby disturbing the operation of
   routing protocols using NHDP.

   In some MANETs, the routers are powered by battery.  Another
   consequence of DoS attack in such networks is that the power will be
   drained quickly by unnecessary message processing, transmission and

4.3.  Eavesdropping and Traffic Analysis

   Eavesdropping, sometimes referred as sniffing, is a common and easy
   passive attack in a wireless environment.  Once a packet is
   transmitted, any adjacent NHDP Router can potentially obtain a copy,
   for immediate or later processing.  Neither the source nor the
   intended destination can detect this.  A malicious NHDP Router can
   eavesdrop on the NHDP message exchange and thus learn the local
   topology.  It may also eavesdrop on data traffic to learn source and
   destination addresses of data packets, or other header information,
   as well as the packet payload.

   Eavesdropping does not pose a direct threat to the network nor to
   NHDP, in as much as that it does not alter the information recorded
   by NHDP in its information bases and presented to other protocols
   using it, but it can provide network information required for
   enabling other attacks, such as the identity of communicating NHDP
   Routers, detection of link characteristic, and NHDP Router
   configuration.  The compromised NHDP Routers may use the obtained
   information to launch subsequent attacks, and they may also share
   NHDP routing information with other NHDP or non-NHDP entities.
   [RFC4593] would categorize the threat consequence as Disclosure.

Yi, et al.              Expires December 19, 2013               [Page 6]
Internet-Draft          Security Threats for NHDP              June 2013

   Traffic analysis normally comes along with eavesdropping, which is
   the process of intercepting messages in order to deduce information
   from communication patterns.  It can be performed even HELLO messages
   are encrypted (encryption is not a part of NHDP), for example:

   o  Triggered HELLO messages: an attacker could figure out that
      messages are triggered and determine that there was a change of
      symmetric neighbors of an NHDP Router sending the HELLO (as well
      get the frequency).

   o  Message size: the message grows exactly by x bytes per neighbor.
      Depending on which cipher is used for the encryption, some
      information about the size could be inferred and thus the number
      of neighbors guessed.

   [RFC4593] would categorize the threat consequence as Disclosure.

4.4.  Incorrect HELLO Message Generation

   An NHDP Router performs two distinct tasks: it periodically generates
   HELLO messages, and it processes incoming HELLO messages from
   neighbor NHDP Routers.  This section describes security attacks
   involving the HELLO generation.

4.4.1.  Identity Spoofing

   Identity spoofing implies that a Compromised NHDP Router sends HELLO
   messages, pretending to have the identity of another NHDP Router, or
   even a router that does not exist in the networks.  A Compromised
   NHDP Router can accomplish this by using another IP address in an
   address block of a HELLO message, and associating this address with a
   LOCAL_IF Address Block TLV [IJNSIA2010].

   An NHDP Router receiving the HELLO message from a neighbor, will
   assume that it originated from the NHDP Router with the spoofed
   interface address.  As a consequence, it will add a Link Tuple to
   that neighbor with the spoofed address, and include it in its next
   HELLO messages as a heard neighbor (and possibly as symmetric
   neighbor after another HELLO exchange).

   Identity spoofing is particular harmful if a Compromised NHDP Router
   spoofs the identity of another NHDP Router that exists in the same
   routing domain.  With respect to NHDP, such a duplicated, spoofed
   address can lead to an inconsistent state up to two hops from an NHDP
   Router.  [RFC4593] would categorize the threat consequence as
   Disclosure and Deception.

   Figure 1 depicts a simple example.  In that example, NHDP Router A is

Yi, et al.              Expires December 19, 2013               [Page 7]
Internet-Draft          Security Threats for NHDP              June 2013

   in radio range of C, but not of the Compromised NHDP Router X. If X
   spoofs the address of A, that can lead to conflicts for routing
   protocol that uses NHDP, and therefore for wrong path calculations as
   well as incorrect data traffic forwarding.

                          .---.    .---.    .---.
                          | A |----| C |----| X |
                          '---'    '---'    '---'

                                 Figure 1

   Figure 2 depicts another example.  In this example, A is two hops
   away from NHDP Router C, reachable through NHDP Router B. If the
   Compromised NHDP Router X spoofs the address of A, D will take A as
   its one hop neighbor, and C may think that A is indeed reachable
   through NHDP Router D.

                 .---.    .---.    .---.    .---.    .---.
                 | A |----| B |----| C |----| D |----| X |
                 '---'    '---'    '---'    '---'    '---'

                                 Figure 2

4.4.2.  Link Spoofing

   Similar to identity spoofing, link spoofing implies that a
   Compromised NHDP Router sends HELLO messages, signaling an incorrect
   set of neighbors, sometimes referred to as Falsification [RFC4593].
   This may take either of two forms:

   o  A Compromised NHDP Router can postulate addresses of non-present
      neighbor NHDP Routers in an address block of a HELLO, associated
      with LINK_STATUS TLVs.

   o  A Compromised NHDP Router can "ignore" otherwise existing
      neighbors by not advertising them in its HELLO messages.

   The effect of link spoofing with respect to NHDP are twofold,
   depending on the two cases mentioned above: If the Compromised NHDP
   Router ignores existing neighbors in its advertisements, links will
   be missing in the information bases maintained by other routers, and
   there may not be any connectivity to or from these NHDP Routers to
   others NHDP Routers in the MANET.  If, on the other hand, the
   Compromised NHDP Router advertises non-existing links, this will lead
   to inclusion of topological information in the information base,
   describing non-existing links in the network (which, then, may be
   used by other protocols using NHDP in place of other, existing,
   links).  [RFC4593] would categorize the threat consequence as

Yi, et al.              Expires December 19, 2013               [Page 8]
Internet-Draft          Security Threats for NHDP              June 2013

   Usurpation, Deception and Disruption.

4.5.  Replay Attack

   A replay attack implies that control traffic from one region of the
   network is recorded and replayed in a different region at (almost)
   the same time, or in the same region at a different time.  This may,
   for example, happen when two Compromised NHDP Routers collaborate on
   an attack, one recording traffic in its proximity and tunneling it to
   the other Compromised NHDP Router, which replays the traffic.  In a
   protocol where links are discovered by testing reception, this will
   result in extraneous link creation (basically, a "virtual" link
   between the two Compromised NHDP Routers will appear in the
   information bases of neighboring NHDP Routers).  [RFC4593] would
   categorize this as a Falsification and Interference threat with a
   threat consequence of Usurpation, Deception, and Disruption.

   While this situation may result from an attack, it may also be
   intentional: if data-traffic also is relayed over the "virtual" link,
   the link being detected is indeed valid for use.  This is, for
   instance, used in wireless repeaters.  If data traffic is not carried
   over the virtual link, an imaginary, useless, link between the two
   Compromised NHDP Routers, has been advertised, and is being recorded
   in the information bases of their neighboring NHDP Routers.

   Compared to Incorrect HELLO Message attacks described in Section 4.4,
   the messages used in Replay attack are legitimate messages sent out
   by (non-malicious) NHDP Routers and replayed at a later time or
   different locality by malicious routers.  This makes this kind of
   attack harder to be detect and to counteract: integrity checks cannot
   help in this case as the original message ICV (Integrity Check
   Values) was correctly calculated.

4.6.  Message Timing Attacks

   In NHDP, each HELLO message contains a "validity time" and may
   contain an "interval time" field, identifying the time for which
   information in that control message should be considered valid until
   discarded, and the time until the next control message of the same
   type should be expected [RFC5497].

4.6.1.  Interval Time Attack

   A use of the expected interval between two successive HELLO messages
   is for determining the link quality in NHDP: if messages are not
   received within the expected intervals (e.g., a certain fraction of
   messages are missing), then this may be used to exclude a link from
   being considered as useful, even if (some) bi-directional

Yi, et al.              Expires December 19, 2013               [Page 9]
Internet-Draft          Security Threats for NHDP              June 2013

   communication has been verified.  If a Compromised NHDP Router X
   spoofs the identity of an existing NHDP Router A, and sends HELLOs
   indicating a low interval time, an NHDP Router B receiving this HELLO
   will expect the following HELLO to arrive within the interval time
   indicated - or otherwise, decrease the link quality for the link A-B.
   Thus, X may cause NHDP Router B's estimate of the link quality for
   the link A-B to fall below the limit, where it is no longer
   considered as useful and, thus, not used [CPSCOM2011].  [RFC4593]
   would categorize the threat consequence as Usurpation.

4.6.2.  Validity Time Attack

   A Compromised NHDP Router X can spoof the identity of an NHDP Router
   A and send a HELLO using a low validity time (e.g.,1 ms).  A
   receiving NHDP Router B will discard the information upon expiration
   of that interval, i.e., a link between NHDP Router A and B will be
   "torn down" by X. It can be caused by intended malicious behaviors,
   or simply mis-configuration in the NHDP Routers.  [RFC4593] would
   categorize the threat consequence as Usurpation.

4.7.  Indirect Channel Overloading

   Indirect Channel Overloading is when a Compromised NHDP Router X by
   its actions causes other legitimate NHDP Routers to generate
   inordinate amounts of control traffic.  This increases channel
   occupation, and the overhead in each receiving NHDP Router processing
   this control traffic.  With this traffic originating from Legitimate
   NHDP Routers, the malicious device may remain undetected to the wider
   network.  It is a form of Interference and Overload with threat
   consequences of Disruption [RFC4593].

   Figure 3 illustrates Indirect Channel Overloading with NHDP.  A
   Compromised NHDP Router X advertises a symmetric spoofed link to the
   non-existing NHDP Router B (at time t0).  Router A selects X as MPR
   upon reception of the HELLO, and will trigger a HELLO at t1.
   Overhearing this triggered HELLO, the attacker sends another HELLO at
   t2, advertising the link to B as lost, which leads to NHDP Router A
   deselecting the attacker as MPR, and another triggered message at t3.
   The cycle may be repeated, alternating advertising the link X-B as
   LOST and SYM.

Yi, et al.              Expires December 19, 2013              [Page 10]
Internet-Draft          Security Threats for NHDP              June 2013

                             MPRs(X)                   MPRs()
                .---.        .---.        .---.        .---.
                | A |        | A |        | A |        | A |
                '---'        '---'        '---'        '---'
                  |            |            |            |
                  | SYM(B)     |            | LOST(B)    |
                  |            |            |            |
                .---.        .---.        .---.        .---.
                | X |        | X |        | X |        | X |
                '---'        '---'        '---'        '---'
                  .            .
                  .            .
                  .            .
                .....        .....
                . B .        . B .
                .....        .....

                 t0           t1           t2           t3

                                 Figure 3

4.8.  Attack on Link Quality Update

   According to NHDP, "Link quality is a mechanism whereby a router MAY
   take considerations other than message exchange into account for
   determining when a link is and is not a candidate for being
   considered as HEARD or SYMMETRIC.  As such, it is a link admission

   Section 14.4 of NHDP [RFC6130] then lists several examples of which
   information can be used to update link quality.  One of the listed
   examples is to update link quality based on [RFC5444] packet
   exchanges between neighbor routers, e.g., an NHDP Router may update
   the link quality of a neighbor based on receipt or loss of packets if
   they include a sequential packet sequence number.

   NHDP does not specify how to acquire link quality updates
   normatively, however, attack vectors may be introduced if an
   implementation chooses to calculate link quality based on packet
   sequence numbers.  The consequences of such threats would depend on
   specific implementations.  For example, if the link quality update is
   based on sequential packet sequence number from neighbor routers, a
   Comprised NDHP Router can spoof packets appearing to be from another
   Legitimate NHDP Router that skips some packet sequence numbers.  The
   NHDP Router receiving the spoofed packets may degrade the link
   quality as it appears that several packets have been dropped.
   Eventually, the router remove the neighbor when the link quality
   drops below HYST_REJECT.

Yi, et al.              Expires December 19, 2013              [Page 11]
Internet-Draft          Security Threats for NHDP              June 2013

5.  Impact of inconsistent Information Bases on Protocols using NHDP

   This section describes the impact on protocols, using NHDP, of NHDP
   failing to obtain and represent accurate information, possibly as a
   consequence of the attacks described in Section 4.  This description
   emphasizes the impacts on the MANET protocols OLSRv2
   [I-D.ietf-manet-olsrv2], and SMF [RFC6621].

5.1.  MPR Calculation

   MPR selection (as used in e.g., [I-D.ietf-manet-olsrv2] and
   [RFC6621]) uses information about a router's 1-hop and 2-hop
   neighborhood, assuming that (i) this information is accurate, and
   (ii) all 1-hop neighbors are apt to act as as MPR, depending on the
   willingness they report.  Thus, a Compromised NHDP router may seek to
   manipulate the 1-hop and 2-hop neighborhood information in a router
   such as to cause the MPR selection to fail, leading to a flooding
   disruption of TC messages, which can result in incomplete topology
   advertisement, or degrade the optimized flooding to classical

5.1.1.  Flooding Disruption due to Identity Spoofing

   A Compromised NHDP router can spoof the identify of other routers, to
   disrupt the MPR selection, so as to cache certain parts of the
   network from the flooding traffic [IJNSIA2010].

   In Figure 4, a Compromised NHDP router X spoofs the identity of B.
   The link between X and C is correctly detected and listed in X's
   HELLOs.  Router A will receive HELLOs indicating links from,
   respectively B:{B-E}, X:{X-C, X-E}, and D:{D-E, D-C}.  For router A,
   X and D are equal candidates for MPR selection.  To make sure the X
   can be selected as MPR for router A, X can set its willingness to the
   maximum value.

                         .---.    .---.    .---.
                         | E |----| D |----| C |
                         '---'    '---'    '---'
                           |        |        .
                           |        |        .
                         .---.    .---.    .---.
                         | B |----| A |----| X |
                         '---'    '---'    '---'
                                           spoofs B

                                 Figure 4

   If B and X (i) accept MPR selection and (ii) forward flooded traffic

Yi, et al.              Expires December 19, 2013              [Page 12]
Internet-Draft          Security Threats for NHDP              June 2013

   as-if they were both B, identity spoofing by X is harmless.  However,
   if X does not forward flooded traffic (i.e., does not accept MPR
   selection), its presence entails flooding disruption: selecting B
   over D renders C unreachable by flooded traffic.

                                  | D |
                .---.    .---.    .---.    .---.    .---.
                | X |----| A |----| B |----| C |----| E |...
                '---'    '---'    '---'    '---'    '---'
               spoofs E

                                 Figure 5

   In Figure 5, the Compromised NHDP router X spoofs the identity of E,
   i.e.,router A and C both receive HELLOs from a router identifying as
   E. For router B, A and C present the same neighbor sets, and are
   equal candidates for MPR selection.  If router B selects only router
   A as MPR, C will not relay flooded traffic from or transiting via B,
   and router X (and routers to the "right" of it) will not receive
   flooded traffic.

5.1.2.  Flooding Disruption due to Link Spoofing

   A Compromised NHDP router can also spoof links to other NHDP routers,
   and thereby makes itself appear as the most appealing candidate of
   MPR for its neighbors, possibly to the exclusion of other NHDP
   routers in the neighborhood (this, in particular, if the Compromised
   NHDP router spoof links to all other NHDP routers in the
   neighborhood, plus to one other NHDP router).  By thus excluding
   other legitimate NHDP routers from being selected as MPR, the
   Compromised NHDP router will receive and be expected to relay all
   flooded traffic (e.g., TC messages in OLSRv2 or data traffic in SMF)
   - which it can then drop or otherwise manipulate.

   In the network in Figure 6, the Compromised NHDP router X spoofs
   links to the existing router C, as well as to a fictitious W. Router
   A receives HELLOs from X and B, reporting X: {X-C, X-W}, b: {B-C}.
   All else being equal, X appears a better choice as MPR than B, as X
   appears to cover all neighbors of B, plus W.

Yi, et al.              Expires December 19, 2013              [Page 13]
Internet-Draft          Security Threats for NHDP              June 2013

                                             ,---.    .....
                                             | S |    . C .
                                             '---'    .....
                                               |        .
                                               |        .
                  .---.    .---.    .---.    .---.    .---.
                  | D |----| C |----| B |----| A |----| X |
                  '---'    '---'    '---'    '---'    '---'
                                                      . w .

                                 Figure 6

   As router A will not select B as MPR, B will not relay flooded
   messages received from router A. The NHDP routers on the left of B
   (starting with C) will, thus, not receive any flooded messages from
   or transiting NHDP router A (e.g., a message originating from S).

5.1.3.  Broadcast Storm

   Compromised NHDP router may attack the network by attempting to
   degrade the performance of optimized flooding algorithms so as to be
   equivalent to classic flooding.  This can be achieved by forcing an
   NHDP router into choosing all its 1-hop neighbors as MPRs.  In
   MANETs, a broadcast storm caused by classic flooding is a serious
   problem which can result in redundancy, contention and collisions

   As shown in Figure 7, the Compromised NHDP router X spoofs the
   identity of NHDP router B and, spoofs a link to router Y {B-Y} (Y
   does not have to be exist).  By doing so, the legitimate NHDP router
   A has to select the legitimate NHDP router B as its MPR, in order for
   it to reach all its 2-hop neighbors.  The Compromised NHDP router Y
   can perform this identity+link spoofing for all of NHDP router A's
   1-hop neighbors, thereby forcing NHDP router A to select all its
   neighbors as MPR - disabling the optimization sought by the MPR

Yi, et al.              Expires December 19, 2013              [Page 14]
Internet-Draft          Security Threats for NHDP              June 2013

                         | B |
                         .---.    .---.      .....
                         | A |----| X | .  . . Y .
                         '---'    '---'      .....
                                  spoofs B

                                 Figure 7

5.2.  Routing Loops

   Inconsistent information bases, provided by NHDP to other protocols,
   can also cause routing loops.  In Figure 8, the Compromised NHDP
   router X spoofs the identity of NHDP router E. NHDP router D has data
   traffic to send to NHDP router A. The topology recorded in the
   information base of router D indicates that the shortest path to
   router A is {D->E->A}, because of the link {A-E} reported by X.
   Therefore, the data traffic will be routed to the NHDP router E. As
   the link {A-E} does not exist in NHDP router E's information bases,
   it will identify the next hop for data traffic to NHDP router A as
   being NHDP router D. A loop between the NHDP routers D and E is thus

                    .---.    .---.    .---.    .---.    .---.
                    | A |----| B |----| C |----| D |----| E |
                    '---'    '---'    '---'    '---'    '---'
                    | X |
                    spoofs E

                                 Figure 8

5.3.  Invalid or Non-Existing Paths to Destinations

   By reporting inconsistent topology information in NHDP, the invalid
   links/routers can be propagated as link state information with TC
   messages and results in route failure.  As illustrated in Figure 8,
   if NHDP router B tries to send data packets to NHDP router E, it will
   choose router A as its next hop, based on the information of non-
   existing link {A-E} reported by the Compromised NHDP router X.

Yi, et al.              Expires December 19, 2013              [Page 15]
Internet-Draft          Security Threats for NHDP              June 2013

5.4.  Data Sinkhole

   With the ability to spoof multiple identities of legitimate NHDP
   routers (by eavesdropping, for example), the Compromised NHDP router
   can represent a "data sinkhole" for its 1-hop and 2-hop neighbors.
   Data packets that come across its neighbors may be forwarded to the
   Compromised NHDP router instead of to the real destination.  The
   packet can then be dropped, manipulated, duplicated, etc., by the
   Compromised NHDP router.  As shown in Figure 8, if the Compromised
   NHDP router X spoofs the identity of NHDP router E, all the data
   packets to E that cross NHDP routers A and B will be sent to NHDP
   router X, instead of to E.

6.  Future Work

   This document does not propose solutions to mitigate the security
   threats described in Section 4.  However, this section aims at
   driving new work by suggesting which threats discussed in Section 4
   could be addressed in new protocol work, which in deployment, and
   which by applications:

   o  Section 4.1: Jamming - If a single router or a small area of the
      MANET is jammed, protocols could be specified that increase link
      metrics in NHDP for the jammed links.  When a routing protocol,
      such as OLSRv2, uses NHDP for neighborhood discovery, other paths
      leading "around" the jammed area would be preferred, and therefore
      mitigate the threat to some extent.

   o  Section 4.2: DoS - DoS using a massive amount of HELLO messages
      can be mitigated by admitting only trusted routers to the network.
      [I-D.ietf-manet-nhdp-olsrv2-sec] specifies a mechanism for adding
      Integrity Check Values (ICVs) to HELLO messages and therefore
      providing an admittance mechanism for NHDP Routers to a MANET.
      (Note that adding ICVs adds itself a new DoS attack vector, as ICV
      verification requires CPU and memory resources.)  Using ICVs does
      however not address the problem of compromised routers.  Detecting
      compromised routers could be addressed in new work.
      [I-D.ietf-manet-nhdp-olsrv2-sec] mandates to implement a security
      mechanism based on shared keys, which makes excluding single
      compromised routers difficult; work could be done to facilitate
      revocation mechanisms in certain MANET use cases where routers
      have sufficient capabilities to support asymmetric keys.

   o  Section 4.3: Eavesdropping - [I-D.ietf-manet-nhdp-olsrv2-sec] adds
      ICVs to HELLO messages, but does not encrypt them.  Therefore,
      eavesdropping of control traffic is not mitigated.  Future work
      could provide encryption of control traffic for sensitive MANET

Yi, et al.              Expires December 19, 2013              [Page 16]
Internet-Draft          Security Threats for NHDP              June 2013

      topologies.  Note that, other than using a single shared secret
      key, encryption to a potentially a priori unknown set of
      neighbors, especially without multiplying overheads, is non-
      trivial.  By traffic analyzing, attackers could still deduce the
      network information like HELLO message triggering, and HELLO
      message size, even HELLO messages are encrypted.

   o  Section 4.4.2: Link spoofing - [I-D.ietf-manet-nhdp-olsrv2-sec]
      provides certain protection against link spoofing, but an NHDP
      Router has to "trust" the originator of a HELLO that the
      advertized links are correct.  For example, if a router A reports
      a link to B, routers receiving HELLOs from A have to trust that B
      is actually a (symmetric) neighbor of A. New protocol work could
      address protection of links without overly increasing space and
      time overheads.  An immediate suggestion for deployments is to
      protect routers against being compromised and distributing keys
      only to trusted routers.

   o  Section 4.5: Replay Attacks - [I-D.ietf-manet-nhdp-olsrv2-sec]
      provides certain protection against replay attacks, using ICVs and
      timestamps.  It is still feasible to replay control messages
      within limited time.  A suggestion for deployments is to provide
      time synchronization between routers.  New work could provide time
      synchronization mechanisms for certain MANET use cases, or specify
      a mechanism using nonces instead of time stamps in HELLO messages.

   o  Section 4.4.1: Identity spoofing, Section 4.6: Message timing
      attacks, Section 4.7: Indirect channel overloading, and
      Section 4.8: Attack on link quality update -
      [I-D.ietf-manet-nhdp-olsrv2-sec] provides protection against these
      attacks, assuming that routers are not compromised.

7.  Security Considerations

   This document does not specify a protocol or a procedure.  The
   document, however, reflects on security considerations for NHDP and
   MANET routing protocols using NHDP for neighborhood discovery.

8.  IANA Considerations

   This document contains no actions for IANA.

9.  Acknowledgments

   The authors would like to gratefully acknowledge the following people

Yi, et al.              Expires December 19, 2013              [Page 17]
Internet-Draft          Security Threats for NHDP              June 2013

   for valuable comments and technical discussions: Teco Boot, Henning
   Rogge, Christopher Dearlove, John Dowdell, Joseph Macker, and the all
   the other participants of IETF MANET working group.

10.  References

10.1.  Normative References

   [RFC5444]  Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
              "Generalized Mobile Ad Hoc Network (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.

10.2.  Informative References

              Jhaveri, R. and S. Patel, "DoS Attacks in Mobile Ad Hoc
              Networks: A Survey", Second International Conference
              on Advanced Computing & Communication Technologies (ACCT),
              Jan 2012.

              Yi, J., Clausen, T., and U. Herberg, "Vulnerability
              Analysis of the Simple Multicast Forwarding (SMF) Protocol
              for Mobile Ad Hoc Networks", Proceedings of the IEEE
              International Conference on Cyber, Physical, and Social
              Computing (CPSCom), October 2011.

              Herberg, U., Dearlove, C., and T. Clausen, "Integrity
              Protection for Control Messages in NHDP and OLSRv2",
              draft-ietf-manet-nhdp-olsrv2-sec-02 (work in progress),
              April 2013.

              Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
              "The Optimized Link State Routing Protocol version 2",
              draft-ietf-manet-olsrv2-19 (work in progress), March 2013.


Yi, et al.              Expires December 19, 2013              [Page 18]
Internet-Draft          Security Threats for NHDP              June 2013

              Nguyen, J., Cole, R., Herberg, U., Yi, J., and J. Dean,
              "Network Management of Mobile Ad hoc Networks (MANET):
              Architecture, Use Cases, and Applicability",
              draft-nguyen-manet-management-00 (work in progress),
              February 2013.

              Herberg, U. and T. Clausen, "Security Issues in the
              Optimized Link State Routing Protocol version 2",
              International Journal of Network Security & Its
              Applications, April 2010.

              Ni, S., Tseng, Y., Chen, Y., and J. Sheu, "The Broadcast
              Storm Problem in a Mobile Ad Hoc Network", Proceedings of
              the 5th annual ACM/IEEE international conference on Mobile
              computing and networking, 1999.

   [RFC4593]  Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to
              Routing Protocols", RFC 4593, October 2006.

   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",
              RFC 4949, August 2007.

   [RFC6621]  Macker, J., "Simplified Multicast Forwarding", RFC 6621,
              May 2012.

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

Authors' Addresses

   Jiazi Yi
   LIX, Ecole Polytechnique
   91128 Palaiseau Cedex,

   Phone: +33 1 77 57 80 85

Yi, et al.              Expires December 19, 2013              [Page 19]
Internet-Draft          Security Threats for NHDP              June 2013

   Ulrich Herberg
   Fujitsu Laboratories of America
   1240 E Arques Ave
   Sunnyvale, CA 94085


   Thomas Heide Clausen
   LIX, Ecole Polytechnique
   91128 Palaiseau Cedex,

   Phone: +33 6 6058 9349

Yi, et al.              Expires December 19, 2013              [Page 20]