Mobile Ad hoc Networking (MANET)                              U. Herberg
Internet-Draft                                                T. Clausen
Intended status: Informational                  LIX, Ecole Polytechnique
Expires: May 16, 2010                                  November 12, 2009


                       Security Threats for NHDP
                draft-herberg-manet-nhdp-sec-threats-00

Abstract

   This document analyses common security threats of the Neighborhood
   Discovery Protocol (NHDP) and describes impacts for MANET routing
   protocols using NHDP.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on May 16, 2010.

Copyright Notice

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



Herberg & Clausen         Expires May 16, 2010                  [Page 1]


Internet-Draft          Security Threats for NHDP          November 2009


   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 BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.



































Herberg & Clausen         Expires May 16, 2010                  [Page 2]


Internet-Draft          Security Threats for NHDP          November 2009


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  NHDP Threat Overview  . . . . . . . . . . . . . . . . . . . . . 3
   4.  Detailed Description of Security Threats to NHDP  . . . . . . . 4
     4.1.  Jamming . . . . . . . . . . . . . . . . . . . . . . . . . . 4
     4.2.  Incorrect HELLO Message Generation  . . . . . . . . . . . . 5
       4.2.1.  Identity Spoofing . . . . . . . . . . . . . . . . . . . 5
       4.2.2.  Link Spoofing . . . . . . . . . . . . . . . . . . . . . 6
     4.3.  Replay attack . . . . . . . . . . . . . . . . . . . . . . . 6
   5.  Impact of inconsisent Information Bases for Routing
       Protocols using NHDP  . . . . . . . . . . . . . . . . . . . . . 6
     5.1.  MPR Calculation . . . . . . . . . . . . . . . . . . . . . . 7
     5.2.  Routing Loops . . . . . . . . . . . . . . . . . . . . . . . 7
     5.3.  Invalid or non-existing Paths to Destinations . . . . . . . 7
     5.4.  Data Sinkhole . . . . . . . . . . . . . . . . . . . . . . . 7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   8.  Normative References  . . . . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8






























Herberg & Clausen         Expires May 16, 2010                  [Page 3]


Internet-Draft          Security Threats for NHDP          November 2009


1.  Introduction

   The Neighborhood Discovery Protocol (NHDP) [NHDP] allows routers to
   exchange information about their one-hop and two-hop neighbors by
   means of HELLO messages.  It is a common base protocol for several
   protocols in the MANET working group, such as OLSRv2 [OLSRv2] and SMF
   [SMF].  The neighborhood information, exchanged between routers using
   NHDP, serves these routing protocols as a baseline for calculating
   paths to all destinations in the MANET, relay set selection for
   network-wide transmissions etc.

   Due to the fact that 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 wireless radio waves can be captured as well as
   transmitted by any wireless device within radio range, there is
   commonly no physical protection as for wired networks.  The NHDP
   specification does not define any security means for protecting the
   integrity of the information it acquires, however suggests that this
   be addressed in a fashion appropriate to the deployment of the
   network.

   This document will describe these security attacks which NHDP is
   vulnerable to.  In addition, the document outlines the consequences
   of such security attacks to NHDP for routing protocols using NHDP for
   neighborhood discovery.  It is out of scope of this document to
   provide solutions to counteract security attacks to NHDP.


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in RFC
   2119 [RFC2119].

   Additionally, this document uses the terminology of [RFC5444] and
   [NHDP].


3.  NHDP Threat Overview

   NHDP [NHDP] defines a message exchange protocol based on HELLO
   messages in order for each router to acquire topological information
   about 1-hop and 2-hop neighbors.  It specifies information bases that
   store the information and the necessary message exchange.  These
   information bases can be accesses by routing protocols such as OLSRv2
   [OLSRv2] to construct routes to destinations in the MANET.



Herberg & Clausen         Expires May 16, 2010                  [Page 4]


Internet-Draft          Security Threats for NHDP          November 2009


   Every router periodically transmits HELLO messages on each of its
   interfaces with a hop-limit of 1 (i.e.  HELLOs are never forwarded by
   a router).  In these HELLO messages, a router announces the IP
   addresses of heard, symmetric and lost neighbor interface addresses.

   An adversary has several ways of harming the 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 will eventually
   lead to inconsistent information bases, not reflecting the correct
   topology of the MANET any more.  This means that routers may be
   unable to detect links to their neighbors correctly (for NHDP), and
   thus corrupt the routing process of a routing protocol using the
   neighbor information of NHDP.  These implications to protocols using
   the state of NHDP are in detail described in Section 5.


4.  Detailed Description of Security Threats to NHDP

   In this section, the different kind of threats to NHDP are detailed.
   For every attack, a description of the mechanism of the attack is
   followed by the implications for the NHDP instance.  Implications on
   routing protocols using NHDP are presented in Section 5.

   For simplicity, in all examples contained in the following sections,
   it is assumed that routers only have a single interface with a single
   IP address configured.  All the attacks apply as well for routers
   with multiple interfaces and multiple addresses.

4.1.  Jamming

   One vulnerability, common for all protocols operating a wireless ad
   hoc network, is that of "jamming" - i.e. that a router 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.  This vulnerability cannot be dealt
   with at L3 (if at all), leaving the network without the ability to
   maintain connectivity.  Jamming is somewhat similar to that of
   network overload and subsequent denial of service: a sufficiently
   significant amount of control traffic is lost, preventing HELLO
   messages to be correctly received.

   If a considerable amount of HELLO messages are lost or corrupted due
   to collisions, neighbor routers are able not any more to establish
   links between them.  This effectively renders NHDP unusable for upper
   layer protocols, since no stable links can be used for sending out



Herberg & Clausen         Expires May 16, 2010                  [Page 5]


Internet-Draft          Security Threats for NHDP          November 2009


   control packets, or for calculating routing information.

4.2.  Incorrect HELLO Message Generation

   Every router running NHDP performs mainly two tasks: Periodically
   generating HELLO messages and processing incoming HELLO messages from
   neighbor routers.  This section describes two security attacks
   involving the HELLO generation.

4.2.1.  Identity Spoofing

   The so-called identity spoofing implies that a router sends HELLO
   messages pretending to have the identity of another router.  An
   attacker can accomplish this by using another router's IP address in
   an address block of a HELLO, and associating this address with a
   LOCAL_IF Address Block TLV.  In addition, it may need to set the
   source address of the IP header that contains the control message.

   If a router receives such a forged HELLO message from a neighbor, it
   will assume that this HELLO comes from a router with the claimed
   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 router spoofs the
   identity of another 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 a router.  Figure 1)
   depicts a simple example.  In that example, router A is in radio
   range of C, but not of X. If X spoofs the address of A, that can lead
   to conflicts for upper-layer routing protocols, 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 router C, reachable through router B. If the attacker X
   spoofs the address of A, C may think that A is indeed reachable
   through router D.







Herberg & Clausen         Expires May 16, 2010                  [Page 6]


Internet-Draft          Security Threats for NHDP          November 2009


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

                                 Figure 2

4.2.2.  Link Spoofing

   Similarly, link spoofing implies that a router sends HELLO messages,
   signaling an incorrect set of neighbors.  This may take either of two
   forms: An attacker can postulate addresses of non-present neighbor
   routers in an address block of a HELLO, associated with LINK_STATUS
   TLVs.  Alternatively, a compromised router can "ignore" existing
   neighbors by not advertizing 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 router
   ignores existing neighbors, there may not be any connectivity to or
   from these routers to others routers in the MANET.  If, on the other
   hand, the router advertizing non-existing links, this can lead wrong
   topological information in the information base, which may be used by
   routing protocols.

4.3.  Replay attack

   A replay attack is, simply, where control traffic from one region of
   the network is recorded and replayed in a different region (this type
   of attack is also known as the Wormhole attack).  This may, for
   example, happen when two routers collaborate on an attack, one
   recording traffic in its proximity and tunneling it to the other
   router, which replays the traffic.  In a protocol where links are
   discovered by testing reception, this will result in extraneous link
   creation (basically, a link between the two ``attacking'' routers).
   While this may result from an attack, we note that it may also be
   intentional: if data-traffic too is relayed over the virtual link
   over the ``tunnel'', the link being detected is, indeed valid.  This
   is, for instance, used in wireless repeaters.  If data traffic is not
   carried over the virtual link, an imaginary, compromised, link has
   been created.  Replay attacks can be especially damaging if coupled
   with spoofing and playing with sequence numbers in the replayed
   messages, potentially destroying some important topology information
   in routers all over the network.


5.  Impact of inconsisent Information Bases for Routing Protocols using
    NHDP

   The different security attacks on NHDP have been presented in



Herberg & Clausen         Expires May 16, 2010                  [Page 7]


Internet-Draft          Security Threats for NHDP          November 2009


   Section 4 which lead to an inconsistent state of the topology on the
   routers.  This section describes the impact for routing protocols
   that use NHDP as underlying neighbor discovery protocol, in
   particular OLSRv2 [OLSRv2], and SMF.

5.1.  MPR Calculation

   TBD

5.2.  Routing Loops

   TBD

5.3.  Invalid or non-existing Paths to Destinations

   TBD

5.4.  Data Sinkhole

   TBD


6.  IANA Considerations

   This document contains no actions for IANA.


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.  Normative References

   [NHDP]     Clausen, T., Dean, J., and C. Dearlove, "MANET
              Neighborhood Discovery Protocol (NHDP)", work in
              progress draft-ietf-manet-nhdp-11.txt, October 2009.

   [OLSRv2]   Clausen, T., Dearlove, C., and P. Philippe, "The Optimized
              Link State Routing Protocol version 2", work in
              progress draft-ietf-manet-olsrv2-10.txt, September 2009.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5444]  Clausen, T., Dearlove, C., Dean, J., and C. Adjih,



Herberg & Clausen         Expires May 16, 2010                  [Page 8]


Internet-Draft          Security Threats for NHDP          November 2009


              "Generalized MANET Packet/Message Format", RFC 5444,
              February 2009.

   [SMF]      Macker, J., "Simplified Multicast Forwarding", work in
              progress draft-ietf-manet-smf-09.txt, July 2009.


Authors' Addresses

   Ulrich Herberg
   LIX, Ecole Polytechnique
   91128 Palaiseau Cedex,
   France

   Phone: +33-1-6933-4126
   Email: ulrich@herberg.name
   URI:   http://www.herberg.name/


   Thomas Heide Clausen
   LIX, Ecole Polytechnique
   91128 Palaiseau Cedex,
   France

   Phone: +33 6 6058 9349
   Email: T.Clausen@computer.org
   URI:   http://www.thomasclausen.org/
























Herberg & Clausen         Expires May 16, 2010                  [Page 9]