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]