<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
	<!ENTITY RFC4949 SYSTEM
    "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4949.xml">
    <!ENTITY RFC6621 SYSTEM
    "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6621.xml">
    <!ENTITY RFC5444 SYSTEM
    "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5444.xml">
    <!ENTITY RFC6130 SYSTEM
    "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6130.xml">
    <!ENTITY RFC5497 SYSTEM
    "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5497.xml">
    <!ENTITY RFC2119 SYSTEM
    "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
    <!ENTITY RFC6779 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6779.xml">
    <!ENTITY RFC4593 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4593.xml">
]>

   <?rfc toc="yes" ?>  
   <?rfc symrefs="yes" ?>
   <?rfc sortrefs="yes"?>
   <?rfc compact="yes" ?>
   <?rfc subcompact="no" ?>
   <?rfc rfcedstyle="yes" ?>

<rfc number="7186" category="info" submissionType="IETF" consensus="yes"
  ipr="trust200902">

  <front>
    <title abbrev="Security Threats for NHDP">Security Threats for the
    Neighborhood Discovery Protocol (NHDP)</title>
	<author fullname="Jiazi Yi" initials="J" surname="Yi">
			<organization>LIX, Ecole Polytechnique</organization>
			<address>
				<postal>
<street/>
					<city>91128 Palaiseau Cedex</city>
					<country>France</country>
				</postal>
				<phone>+33 1 77 57 80 85</phone>
				<email>jiazi@jiaziyi.com</email>
				<uri>http://www.jiaziyi.com/</uri>
			</address>
	</author>
    <author fullname="Ulrich Herberg" initials="U" surname="Herberg">
			<organization>Fujitsu Laboratories of America</organization>
			<address>
				<postal>
      				<street>1240 E Arques Ave</street>
        			<city>Sunnyvale</city>
        			<region>CA</region><code>94085</code>
        			<country>USA</country>
				</postal>
				<email>ulrich@herberg.name</email>
				<uri>http://www.herberg.name/</uri>
			</address>
		</author>

	<author fullname="Thomas Heide Clausen" initials="T" surname="Clausen">
			<organization>LIX, Ecole Polytechnique</organization>
			<address>
				<postal>
<street/>
					<city>91128 Palaiseau Cedex</city>
					<country>France</country>
				</postal>
				<phone>+33 6 6058 9349</phone>
				<email>T.Clausen@computer.org</email>
				<uri>http://www.thomasclausen.org/</uri>
			</address>
	</author>

    <date month="April" year="2014"/>

    <workgroup>Mobile Ad hoc Networking (MANET)</workgroup>
    <keyword>MANET</keyword>


    <abstract>
      <t>
      This document analyzes common security threats of the
      Neighborhood Discovery Protocol (NHDP) and describes their
      potential impacts on Mobile Ad Hoc Network (MANET) routing protocols using NHDP. This document is not intended to propose solutions to the threats described. 
      </t>
    </abstract>

  </front>

  <middle>

	<section title="Introduction" anchor="introduction">
		<t>
			The Neighborhood Discovery Protocol (NHDP)
			<xref target="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 the Optimized
   Link State Routing Protocol version 2 (OLSRv2)
			<xref target="RFC7181"/> and
			Simplified Multicast Forwarding (SMF) <xref target="RFC6621"/>. The topology information, acquired by way of NHDP, serves these routing protocols by detecting and maintaining local 1-hop and 2-hop neighborhood information.
		</t>
			
		<t>
			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, it suggests that the integrity protection be addressed in a fashion appropriate to the deployment of the network.
		</t>
			
		<t>
   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 able to accommodate such common IP protection mechanisms (e.g., because of limited resources of MANET routers).

The document analyzes possible attacks on and misconfigurations of NHDP and outlines the consequences of such attacks/misconfigurations to the state maintained by NHDP in each router (and, thus, made available to protocols using this state). 
		</t>
		
		<t>
		This document is not intended to propose solutions to the threats described. <xref target="RFC7185"/> provides further information on how to enable integrity protection to NHDP, which can help mitigating the threats described related to identity spoofing. 
		</t>
		
		<t>
		It should be noted that many NHDP implementations are configurable, 
   and so an attack on the configuration system (such as <xref target="RFC6779"/>) can
   be used to adversely affect the operation of an NHDP implementation. 
   		</t>
   		
   		<t>
   The NHDP MIB module <xref target="RFC6779"/> might help monitoring some of the
   security attacks mentioned in this document.  <xref target="MGMT-SNAP"/> provides
   a snapshot of OLSRv2-routed MANET management as currently deployed,
   while <xref target="MANET-MGMT"/> is intended to provide specific guidelines on
   MANET network management considering the various MIB modules that
   have been written.
</t>

	</section>

    <section title="Terminology" anchor="terminology">

      <t>This document uses the terminology and notation defined in
"Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format" <xref target="RFC5444"/>, 
"Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)"
	<xref target="RFC6130"/>, 
and "Internet Security Glossary, Version 2" <xref target="RFC4949"/>.
      </t>
      
      <t>
      	Additionally, this document introduces the following terminology:
      	<list style="hanging">
      		<t hangText="NHDP router:">
      			A MANET router, running NHDP as specified in <xref target="RFC6130"/>.
      		</t>
      		<t hangText="Attacker:">
      			A device that is present in the network and intentionally seeks to compromise the information bases in NHDP routers.
      		</t>
      		
      		<t hangText="Compromised NHDP router:">
      			An attacker that is present in the network and 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-compromised NHDP router located in the same topological position in the network.
      		</t>

      		<t hangText="Legitimate NHDP router:">
      			An NHDP router that is not a compromised NHDP router.
      		</t>
      		


      	</list>
      </t>
    </section>
    
   <section title="NHDP Threat Overview" anchor="overview">
      	<t>
      		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 information.
      	</t>
      	
		<t>
			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.
		</t>
		
		<t>
			An Attacker has several ways of harming this neighbor discovery process: it can announce "wrong" information about its identity,  postulate nonexistent links, and replay HELLO messages. These attacks are presented in detail in <xref target="threat_description"/>.
		</t>
		
		<t>
			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 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 protocols using NHDP are described in detail in <xref target="impact"/>.</t>
    </section>
    

<section anchor="threat_description" title="Detailed Threat Description">
	<t>
		For each threat, 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 <xref target="impact"/>.
	</t>
	<t>
		For simplicity in the description, the 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.
	</t>
	<section anchor="jamming" title="Jamming">
		<t>
			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 the threat consequence of disruption <xref target="RFC4593"/>.
		</t>

		<t>
			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 unidirectional or bidirectional, 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 unjammed part of the network, which is able to maintain accurate topology maps. 
		</t>


		<t>
  If a considerable amount of HELLO messages are lost or corrupted
  due to collisions caused by a jamming attack, 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.
		</t>
	</section>
	
	<section anchor="dos" title="Denial-of-Service Attack">
		<t>
			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 <xref target="ACCT2012"/>,
			so-called Byzantine routers
			<xref target="RFC4593"/>. DoS is a form of
			interference and overload with the threat
			consequence of disruption
			<xref target="RFC4593"/>.


		</t>
		
		<t>
			By transmitting a huge amount of HELLO
			messages in a short period of time, NHDP
			routers can increase channel occupation as
			described in
			<xref target="jamming"/>. 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 it 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
			multipoint relay (MPR) calculation, may exhaust the available computational resources of the router if the Neighbor Set and 2-hop Sets have too many entries.
		</t>
		
		<t>
			By exhausting the memory, CPU, and/or 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.
		</t>
		
		<t>
		In some MANETs, the routers are powered by
		battery. Another consequence of a DoS attack in such networks
is that the power will be drained quickly by unnecessary processing,
transmitting, and receiving of messages. 
		</t>
	</section>
	
	<section anchor="eavesdropping" title="Eavesdropping and Traffic Analysis">
		<t>
			Eavesdropping, sometimes referred to 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.
		</t>

		<t>
  Eavesdropping does not pose a direct threat to the network or 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. However, eavesdropping can provide network information
  required for enabling other attacks, such as the identity of
  communicating NHDP routers, detection of link characteristics, 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. <xref target="RFC4593"/>
			would categorize the threat consequence as
			disclosure.
		</t>
		
		<t>
			Traffic analysis normally follows
			eavesdropping, which is the process of
			intercepting messages in order to deduce
			information from communication patterns. It
			can be performed even when HELLO messages are encrypted (encryption is not a part of NHDP), for example:
		<list style="symbols">
		<t>
			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). 
		</t>
		
		<t>
			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 could be guessed.
		</t>
		</list>
		</t>
		
		<t>
			<xref target="RFC4593"/> would categorize the threat consequence as disclosure. 
		</t>
	</section>
	<section anchor="incorrect_hello" title="Incorrect HELLO Message Generation">
		<t>
			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.
		</t>
		<section anchor="identity_spoof" title="Identity Spoofing">
			<t>
				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 an IP address, which is
not its own, in an address block of a HELLO message, and associating this address with a LOCAL_IF Address Block TLV <xref target="IJNSIA2010"/>.
			</t>
			<t>
				An NHDP router receiving that 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 a symmetric neighbor after another HELLO exchange).
			</t>
			<t>
				Identity spoofing is particularly 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. <xref target="RFC4593"/> would categorize the threat consequences as disclosure and deception. 
				</t>
				<t>

				<xref target="fig_identity_spoof_1hop"/>
depicts a simple example. In that example, NHDP router A is in radio range of
NHDP router C, but not of the compromised NHDP router X. &nbsp;If X spoofs the
address of A, that can lead to conflicts for a routing protocol that uses NHDP, and therefore for wrong path calculations as well as incorrect data traffic forwarding.  
				
			</t>
			

				<figure anchor="fig_identity_spoof_1hop" align='center'><artwork>
.---.    .---.    .---.
| A |----| C |----| X |
'---'    '---'    '---'
					</artwork><postamble/></figure>
					
				<t>

				<xref
				target="fig_identity_spoof_2hop"/>
				depicts another  example. In this
				example, NHDP router A is two hops away from NHDP
				router C, reachable through NHDP
				router B. &nbsp;If the compromised NHDP
				router X spoofs the address of A, NHDP
				router D will take A as its 1-hop neighbor, and C may think that A is indeed reachable through D. 

				<figure anchor="fig_identity_spoof_2hop" align='center'><artwork>
.---.    .---.    .---.    .---.    .---.
| A |----| B |----| C |----| D |----| X |
'---'    '---'    '---'    '---'    '---'
					</artwork><postamble/></figure>
			</t>
		</section>
		<section anchor="link_spoofing" title="Link Spoofing">
			<t>
				Similar to identity spoofing, link spoofing
implies that a compromised NHDP router sends HELLO messages, signaling an
incorrect set of neighbors. This is sometimes referred to as falsification
<xref target="RFC4593"/>, and in NHDP it may take either of two forms:
				<list style="symbols">
					<t>
						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.
					</t>
					<t>
						A compromised NHDP router can "ignore" otherwise existing neighbors by not advertising them in its HELLO messages.
					</t>
				</list>
			</t>
					
			<t>
				The effect of link spoofing with
				respect to NHDP are twofold, depending
				on the two cases mentioned above: 
<list style="symbols">
<t>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
  for these NHDP routers to or from other NHDP routers in the MANET. </t>
<t>
On the other hand, if the compromised NHDP router advertises
nonexistent links, this will lead to inclusion of topological
information in the information base, describing nonexistent links in
the network (which, then, may be used by other protocols using NHDP in
place of other, existing, links). 
</t>
</list>
<xref target="RFC4593"/> would categorize the threat consequences as usurpation, deception, and disruption. 
			</t>
		</section>
	</section>
			
	<section anchor="replay_attack" title="Replay Attack">
		<t>
			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). <xref target="RFC4593"/> would categorize this as a falsification and interference threat with threat consequences of usurpation, deception, and disruption.

		</t>
				
		<t>
			While this situation may result from an
			attack, it may also be intentional: if data traffic is
also 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. 
		</t>
		
		<t>
		Compared to incorrect HELLO message attacks described
		in <xref target="incorrect_hello"/>, the messages used
		in replay attacks 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's Integrity Check Value (ICV) was correctly calculated.
		</t>

	</section>
			
		
	<section anchor="timing_attacks" title="Message Timing Attacks">
		<t>
			In NHDP, each HELLO message contains a
			"validity time" (the amount of time
			that information in that control message
			should be considered valid before being
			discarded) and may contain an "interval
			time" field (the amount of time until the next control message of the same type should be expected) <xref target="RFC5497"/>.
		</t>

		<section anchor="interval_timing_attack" title="Interval Time Attack">
			<t>
				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)
				bidirectional 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.  If that expectation
   is not met, the link quality for the link A-B will be decreased.
   Thus, X may cause NHDP router B's estimate of the link quality for
   the link A-B to fall below the minimum considered useful, so the
   link would not be used <xref target="CPSCOM2011"/>. 

<xref target="RFC4593"/> would categorize the threat consequence as usurpation. 
			</t>
		</section>

		<section anchor="validity_timing_attack" title="Validity Time Attack">
			<t>

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.  The sending of a low validity time can be caused by
intended malicious behaviors or simply misconfiguration in the NHDP
routers.

 <xref target="RFC4593"/> would categorize the threat consequence as usurpation. 
			</t>
		</section>

	</section>
			
			
	<section anchor="indirect_jamming" title="Indirect Channel Overloading">
		<t>
			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
			that processes this control traffic. With this
			traffic originating from legitimate NHDP
			routers, the malicious device may remain
			undetected in the wider network. It is a form
			of interference and overload with the threat consequence of disruption <xref target="RFC4593"/>.
		</t>

				
		<t>
			<xref target="fig_indirect_jamming"/>
			illustrates Indirect Channel Overloading with
			NHDP. A compromised NHDP router X advertises a
			symmetric spoofed link to the nonexistent NHDP
			router B (at time t0). Router A selects X as
			MPR upon reception of the HELLO then triggers
			a HELLO at t1. Overhearing this triggered
			HELLO, the attacker sends another HELLO at t2,
			advertising the link to B as lost; this causes
			NHDP router A to deselect the attacker as MPR,
			and to send another triggered message at
			t3. The cycle may be repeated, where the link
			X-B is advertised alternately as LOST and SYM.
				
			<figure anchor="fig_indirect_jamming" align='center'><artwork>
             MPRs(X)                   MPRs()
.---.        .---.        .---.        .---.
| A |        | A |        | A |        | A |
'---'        '---'        '---'        '---'
  |            |            |            |
  | SYM(B)     |            | LOST(B)    |
  |            |            |            |
.---.        .---.        .---.        .---.
| X |        | X |        | X |        | X |
'---'        '---'        '---'        '---'
  .            .
  .            .
  .            .
.....        .....
. B .        . B .
.....        .....

 t0           t1           t2           t3
				</artwork><postamble/>
			</figure>
					
		</t>		
	</section>
	
	<section anchor="link_update" title="Attack on Link Quality Update">
		<t>According to NHDP <xref target="RFC6130"/>:

<list><t>
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" mechanism.
</t></list>
		</t>
		<t>
			Section 14.4 of NHDP <xref target="RFC6130"/>
			then lists several examples of which
			information can be used to update link
			quality. One of the listed examples uses packet exchanges
			between neighbor routers (as described in <xref target="RFC5444"/>), 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. 
		</t>
		
		<t>
			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 a sequential packet
			sequence number from neighbor routers, a
			compromised NHDP 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 may remove the
			neighbor when the link quality drops below
			HYST_REJECT.
		</t>
	</section>
</section>
		

<section anchor="impact" title="Impact of Inconsistent Information Bases on Protocols using NHDP">
	<t>
		This section describes the impact on protocols that
		use NHDP when NHDP fails to obtain and represent accurate information, possibly as a consequence of the attacks described in <xref target="threat_description"/>. This description emphasizes the impacts on the MANET protocols OLSRv2 <xref target="RFC7181"/> and SMF <xref target="RFC6621"/>.
	</t>
			
	<section title="MPR Calculation">
		<t>
			MPR selection (as used in 
			<xref target="RFC7181"/> and
			<xref target="RFC6621"/>, for example) uses
			information about a router's 1-hop and 2-hop
			neighborhood, assuming that (i) this
			information is accurate, and (ii) each 1-hop
			neighbor is apt to act as MPR, depending on
			the willingness it reports. Thus, a
			compromised NHDP router may seek to manipulate
			the 1-hop and 2-hop neighborhood information
			in a router so as to cause the MPR selection
			to fail, leading to a flooding disruption of
			traffic control messages. This can result in
			incomplete topology advertisement or can degrade the optimized flooding to classical flooding. 
		</t>
				
		<section title="Flooding Disruption due to Identity Spoofing">
			<t>
				A compromised NHDP router can spoof
				the identify of other routers in order to
disrupt the MPR selection, so as to prevent certain parts of the network from
receiving flooded traffic <xref target="IJNSIA2010"/>. 
			</t>
					
			<t>
				In
				<xref
				target="fig_flooding_1hop_duplicate"/>,
				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 B:{B-E},
				X:{X-C, X-E}, and D:{D-E, D-C}, respectively. 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. 

				<figure anchor="fig_flooding_1hop_duplicate" align='center'><artwork>
.---.    .---.    .---.
| E |----| D |----| C |
'---'    '---'    '---'
  |        |        .
  |        |        .
.---.    .---.    .---.
| B |----| A |----| X | 
'---'    '---'    '---'
                  spoofs B
					</artwork><postamble/></figure>


				If B and X (i) accept MPR selection
				and (ii) forward flooded traffic 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.
			</t>
			
			<t>
				<figure anchor="fig_flooding_2hop_duplicate" align='center'><artwork>
                   .---.
                   | D |
                   '---'
                     |
                     |
 .---.    .---.    .---.    .---.    .---.
 | X |----| A |----| B |----| C |----| E |... 
 '---'    '---'    '---'    '---'    '---'
spoofs E
					</artwork><postamble/></figure>


				In
				<xref
				target="fig_flooding_2hop_duplicate"/>,
				the compromised NHDP router X spoofs
				the identity of E, i.e., routers A and
				C both receive HELLOs from a router
				identifying itself as E. &nbsp;For router B,
				routers 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 B or transiting via B, and router X (and routers to the "right" of it) will not receive flooded traffic. 
			</t>
		</section>
				
		<section title="Flooding Disruption due to Link Spoofing">
			<t>

A compromised NHDP router can also spoof links to other NHDP
routers, thereby making itself appear as the most appealing
candidate to be MPR for its neighbors, possibly to the exclusion of
other NHDP routers in the neighborhood.  (In particular, this can
occur if the compromised NHDP router spoofs links to all other NHDP
routers in the neighborhood, plus to one NHDP router outside the
neighborhood.)

 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.,
				traffic control messages in OLSRv2 or
				data traffic in SMF) that it can then drop or otherwise manipulate.
			</t>
					
			<t>
				In the network in <xref target="fig_hello_link_spoofing2"/>, the compromised NHDP router X spoofs links to the existing router C,  as well as to a fictitious W. &nbsp;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 for MPR than B, as X appears to cover all neighbors of B, plus W.

				<figure anchor="fig_hello_link_spoofing2" align='center'><artwork>
                            ,---.    .....
                            | S |    . C .
                            '---'    .....
                              |        .
                              |        .
 .---.    .---.    .---.    .---.    .---.
 | D |----| C |----| B |----| A |----| X |
 '---'    '---'    '---'    '---'    '---'
                                       .
                                       .
                                     .....
                                     . W .
                                     .....
					</artwork><postamble/></figure>


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

		<section title="Broadcast Storm">
			<t>
				A 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 that can result in redundancy, contention, and collisions <xref target="MOBICOM99"/>. 
			</t>
					
			<t>
				As shown in
				<xref target="fig_classic_flooding"/>,
				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 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-and-link spoofing for all of
				NHDP router A's 1-hop neighbors,
				thereby forcing NHDP router A to
				select all its neighbors as MPR and
				disabling the optimization sought by the MPR mechanism. 
			</t>
					
					
			<figure anchor="fig_classic_flooding" align='center'><artwork>
.---. 
| B |
'---' 
  |
  |
.---.    .---.      .....
| A |----| X | .  . . Y .
'---'    '---'      .....
         spoofs B
					</artwork></figure>
				</section>
			</section>
			
			<section title="Routing Loops">
				<t>
					Inconsistent information bases, provided by NHDP to other protocols, can also cause routing loops. In <xref target="fig_loop"/>, the compromised NHDP router X spoofs the identity of NHDP router E. &nbsp;NHDP router D has data traffic to send to NHDP router A. &nbsp;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 NHDP router E. &nbsp;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. &nbsp;A loop between the NHDP routers D and E is thus created. 
				</t>
				<figure anchor="fig_loop" align='center'><artwork>
      .---.    .---.    .---.    .---.    .---.    
      | A |----| B |----| C |----| D |----| E |
      '---'    '---'    '---'    '---'    '---'
        |
        |
      .---.
      | X |
      '---' 
      spoofs E
					</artwork></figure>
			</section>
			
			<section title="Invalid or Nonexistent Paths to Destinations">
				<t>
					By reporting inconsistent
					topology information in NHDP,
					the invalid links and routers
					can be propagated as link
					state information with traffic
					control messages and results
					in route failure. As
					illustrated in
					<xref target="fig_loop"/>, 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 about the nonexistent link {A-E} reported by the compromised NHDP router X. 
				</t>
			</section>
			
			<section title="Data Sinkhole">
				<t>
					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 <xref target="fig_loop"/>, 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.
				</t>
			</section>
		</section>

<section anchor="future_work" title="Future Work">
	<t>
		This document does not propose solutions to mitigate the
security threats described in <xref target="threat_description"/>. 

However, this section aims at
driving new work by suggesting which threats discussed in <xref target="threat_description"/>
could be addressed by deployments or applications.

<list style="symbols">
	<t><xref target="jamming"/>: 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 would mitigate the threat to
some extent.
	</t>

	<t><xref target="dos"/>: DoS - A DoS attack using a massive amount of HELLO messages can be
mitigated by admitting only trusted routers to the network.
<xref target="RFC7185"/> 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 
creates a new DoS attack vector, as ICV verification requires CPU and
memory resources.)  However, using ICVs does not address the
problem of compromised routers. Detecting compromised routers could be
addressed in new work. <xref target="RFC7185"/> mandates
implementation of a
security mechanism that is based on shared keys and 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.</t>

	<t><xref target="eavesdropping"/>: Eavesdropping - <xref target="RFC7185"/> 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 topologies. 

Note that, other than using a single shared secret key, providing
encryption of traffic among a set of neighbors (when that set
is potentially undetermined) is nontrivial, especially without
multiplying overheads.

With traffic analysis, attackers could still deduce the
network information like HELLO message triggering and HELLO message
size, even though the HELLO messages are encrypted. </t>

	<t><xref target="link_spoofing"/>: Link spoofing - <xref target="RFC7185"/> provides certain protection
against link spoofing, but an NHDP router has to "trust" the
originator of a HELLO that the advertised 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 the space and time overheads. An immediate
suggestion for deployments is to protect routers against being
compromised and to distribute keys only to trusted routers.</t>


	<t><xref target="replay_attack"/>: Replay Attacks -
	  <xref target="RFC7185"/> uses ICVs and
   timestamps to provide some protection against replay attacks.

It is still feasible to replay control messages within a 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 timestamps in HELLO messages.</t>

	<t><xref target="identity_spoof"/>:  Identity spoofing; <xref target="timing_attacks"/>: Message timing
attacks; <xref target="indirect_jamming"/>: Indirect
channel overloading; and <xref target="link_update"/>: Attack on link quality update -
<xref target="RFC7185"/> provides protection against these attacks, assuming
the routers are not compromised.
	</t>
	</list>
	</t>
	
</section>
		

<section anchor="Security" title="Security Considerations">
			<t>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.</t>
		</section>
		
		
<section title="Acknowledgments" anchor="acknowledgments">
	<t>
		The authors would like to gratefully acknowledge the
		following people for valuable comments and technical
		discussions: Teco Boot, Henning Rogge, Christopher
		Dearlove, John Dowdell, Joseph Macker, and all the
		other participants of the IETF MANET working group. 
	</t>
</section>


  </middle>

  <back>
<references title="Normative References">

	&RFC6130;
	&RFC5444;
	&RFC5497;
	
</references>
		
<references title="Informative References"> 
			&RFC4949;
			&RFC6621;
			&RFC4593;

<!-- draft-clausen-manet-olsrv2-management-snapshot: I-D Exists-->
<reference anchor='MGMT-SNAP'>
<front>
<title>Snapshot of OLSRv2-Routed MANET Management</title>

<author initials='T' surname='Clausen' fullname='Thomas Clausen'>
    <organization />
</author>

<author initials='U' surname='Herberg' fullname='Ulrich Herberg'>
    <organization />
</author>

<date month='February' day='11' year='2014' />

<abstract><t>This document describes how Mobile Ad Hoc Networks (MANETs) are typically managed, in terms of pre-deployment management, as well as rationale and means of monitoring and management of MANET routers running the routing protocol OLSRv2 and its constituent protocol NHDP.  Apart from pre-deployment management for setting up IP addresses and security related credentials, OLSRv2 only needs routers to agree one single parameter (called "C").  Other parameters for tweaking network performance may be determined during operation of the network, and need not be the same in all routers.  This, using MIB modules and related management protocols such as SNMP (or possibly other, less "chatty", protocols).  In addition, for debugging purposes, monitoring data and performance related counters can be sent to the Network Management Station (NMS) via standardized management protocols.</t></abstract>

</front>

<seriesInfo name="Work" value="in Progress"/>
</reference>


<!-- draft-nguyen-manet-management-00 - Expired -->
<reference anchor='MANET-MGMT'>
<front>
<title>Network Management of Mobile Ad hoc Networks (MANET): Architecture, Use Cases, and Applicability</title>

<author initials='J' surname='Nguyen' fullname='James Nguyen'>
    <organization />
</author>

<author initials='R' surname='Cole' fullname='Robert Cole'>
    <organization />
</author>

<author initials='U' surname='Herberg' fullname='Ulrich Herberg'>
    <organization />
</author>

<author initials='J' surname='Yi' fullname='Jiazi Yi'>
    <organization />
</author>

<author initials='J' surname='Dean' fullname='Justin Dean'>
    <organization />
</author>

<date month='February' year='2013' />

<abstract><t>This document aims at providing an extended architecture, use case and applicability statement for management of MANETs, as a guideline for how to manage MANETs.  This document describes different management activities, such as network configuration, monitoring of state, monitoring of performance, fault management, and software upgrades.  Different aspects of a MANET management architecture are illustrated (e.g., distributed vs. centralized management, flat vs. hierarchical management, management of an entire network vs. an individual router, etc.) and contrasted to the NMS architecture in the Internet.  A desciption of typical MANET use cases relevant for management is followed by an overview of current standard management protocols that can be used in MANETs.</t></abstract>

</front>

<seriesInfo name="Work" value="in Progress"/>

</reference>

<!-- draft-ietf-manet-olsrv2-19 in cluster -->
<reference anchor='RFC7181'>
<front>
<title>The Optimized Link State Routing Protocol Version 2</title>

<author initials='T' surname='Clausen' fullname='Thomas Clausen'>
    <organization />
</author>

<author initials='C' surname='Dearlove' fullname='Christopher Dearlove'>
    <organization />
</author>

<author initials='P' surname='Jacquet' fullname='Philippe Jacquet'>
    <organization />
</author>

<author initials='U' surname='Herberg' fullname='Ulrich Herberg'>
    <organization />
</author>

<date month='April' year='2014' />

<abstract><t>This specification describes version 2 of the Optimized Link State Routing (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs).</t></abstract>

</front>

<seriesInfo name="RFC" value="7181"/>

</reference>

<!-- draft-ietf-manet-nhdp-olsrv2-sec-03 in cluster -->
<reference anchor='RFC7185'>
<front>
<title>Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and
Optimized Link State Routing Protocol Version 2 (OLSRv2)
</title>

<author initials='U' surname='Herberg' fullname='Ulrich Herberg'>
    <organization />
</author>

<author initials='C' surname='Dearlove' fullname='Christopher Dearlove'>
    <organization />
</author>

<author initials='T' surname='Clausen' fullname='Thomas Clausen'>
    <organization />
</author>

<date month='April' year='2014' />

<abstract><t>This document specifies integrity and replay protection for the MANET Neighborhood Discovery Protocol (NHDP) and the Optimized Link State Routing Protocol version 2 (OLSRv2).  This protection is achieved by using an HMAC-SHA-256 Integrity Check Value (ICV) TLV and a Timestamp TLV based on POSIX time.  The mechanism in this specification can also be used for other protocols that use the generalized packet/message format described in RFC 5444.  This document updates RFC 6130 and RFC xxxx by mandating the implementation of this integrity and replay protection in NHDP and OLSRv2.</t></abstract>

</front>
<seriesInfo name="RFC" value="7185"/>

</reference>
			&RFC6779;
			
			<reference anchor="MOBICOM99">
				<front>
					<title>The Broadcast Storm Problem in a Mobile Ad Hoc Network</title>
					<author initials="S.Y." surname="Ni" fullname="S. Ni">
						<organization/>
					</author>
					<author initials="Y.C." surname="Tseng" fullname="Y.C. Tseng">
						<organization/>
					</author>
					<author initials="Y.S." surname="Chen" fullname="Y.S. Chen">
						<organization/>
					</author>
					<author initials="J.P." surname="Sheu" fullname="J.P. Sheu">
						<organization/>
					</author>
					<date month="" year="1999"/>
				</front>
				<seriesInfo name="Proceedings" value="of the 5th annual ACM/IEEE international conference on Mobile computing and networking"/>
			</reference>
			
			<reference anchor="IJNSIA2010">
				<front>
					<title>Security Issues in the Optimized Link State Routing Protocol version 2</title>
					<author initials="U.H." surname="Herberg" fullname="U. Herberg">
					</author>
					<author initials="T.C." surname="Clausen" fullname="T. Clausen">
					</author>
					<date month="April" year="2010"/>
				</front>
				<seriesInfo name="International Journal" value="of Network Security &amp; Its Applications"/>
			</reference>
			
			<reference anchor="CPSCOM2011">
				<front>
					<title>Vulnerability Analysis of the Simple Multicast Forwarding (SMF) Protocol for Mobile Ad Hoc Networks</title>
					<author initials="J.Y." surname="Yi" fullname="J. Yi">
					</author>
					<author initials="T.C." surname="Clausen" fullname="T. Clausen">
					</author>
					<author initials="U.H." surname="Herberg" fullname="U. Herberg">
					</author>
					<date month="October" year="2011"/>
				</front>
				<seriesInfo name="Proceedings" value="of the IEEE International Conference on Cyber, Physical, and Social Computing (CPSCom)"/>
			</reference>
			
			<reference anchor="ACCT2012">
				<front>
					<title>DoS Attacks in Mobile Ad Hoc Networks: A Survey</title>
					<author initials="R.H.J." surname="Jhaveri" fullname=" R.H. Jhaveri">
					</author>
					<author initials="S.J." surname="Patel" fullname="S.J. Patel">
					</author>
					<date month="January" year="2012"/>
				</front>
				<seriesInfo name="Second International Conference on" value="Advanced Computing &amp; Communication Technologies (ACCT)"/>
			</reference>

</references>

  </back>
</rfc>
