draft-ietf-manet-nhdp-sec-threats-01.txt   draft-ietf-manet-nhdp-sec-threats-02.txt 
Mobile Ad hoc Networking (MANET) U. Herberg Mobile Ad hoc Networking (MANET) U. Herberg
Internet-Draft Fujitsu Laboratories of America Internet-Draft Fujitsu Laboratories of America
Intended status: Informational J. Yi Intended status: Informational J. Yi
Expires: April 25, 2013 T. Clausen Expires: September 21, 2013 T. Clausen
LIX, Ecole Polytechnique LIX, Ecole Polytechnique
October 22, 2012 March 20, 2013
Security Threats for NHDP Security Threats for NHDP
draft-ietf-manet-nhdp-sec-threats-01 draft-ietf-manet-nhdp-sec-threats-02
Abstract Abstract
This document analyses common security threats of the Neighborhood This document analyses common security threats of the Neighborhood
Discovery Protocol (NHDP), and describes their potential impacts on Discovery Protocol (NHDP), and describes their potential impacts on
MANET routing protocols using NHDP. MANET routing protocols using NHDP.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 25, 2013. This Internet-Draft will expire on September 21, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 22 skipping to change at page 2, line 22
4.2. Denial of Service Attack . . . . . . . . . . . . . . . . . 5 4.2. Denial of Service Attack . . . . . . . . . . . . . . . . . 5
4.3. Eavesdropping . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Eavesdropping . . . . . . . . . . . . . . . . . . . . . . 6
4.4. Incorrect HELLO Message Generation . . . . . . . . . . . . 6 4.4. Incorrect HELLO Message Generation . . . . . . . . . . . . 6
4.4.1. Identity Spoofing . . . . . . . . . . . . . . . . . . 6 4.4.1. Identity Spoofing . . . . . . . . . . . . . . . . . . 6
4.4.2. Link Spoofing . . . . . . . . . . . . . . . . . . . . 7 4.4.2. Link Spoofing . . . . . . . . . . . . . . . . . . . . 7
4.5. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 8 4.5. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 8
4.6. Message Timing Attacks . . . . . . . . . . . . . . . . . . 8 4.6. Message Timing Attacks . . . . . . . . . . . . . . . . . . 8
4.6.1. Interval Time Attack . . . . . . . . . . . . . . . . . 8 4.6.1. Interval Time Attack . . . . . . . . . . . . . . . . . 8
4.6.2. Validity Time Attack . . . . . . . . . . . . . . . . . 9 4.6.2. Validity Time Attack . . . . . . . . . . . . . . . . . 9
4.7. Indirect Jamming . . . . . . . . . . . . . . . . . . . . . 9 4.7. Indirect Jamming . . . . . . . . . . . . . . . . . . . . . 9
4.8. Attack on Link Quality Update . . . . . . . . . . . . . . 10
5. Impact of inconsistent Information Bases on Protocols 5. Impact of inconsistent Information Bases on Protocols
using NHDP . . . . . . . . . . . . . . . . . . . . . . . . . . 10 using NHDP . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. MPR Calculation . . . . . . . . . . . . . . . . . . . . . 10 5.1. MPR Calculation . . . . . . . . . . . . . . . . . . . . . 11
5.1.1. Flooding Disruption due to Identity Spoofing . . . . . 10 5.1.1. Flooding Disruption due to Identity Spoofing . . . . . 11
5.1.2. Flooding Disruption due to Link Spoofing . . . . . . . 12 5.1.2. Flooding Disruption due to Link Spoofing . . . . . . . 12
5.1.3. Broadcast Storm . . . . . . . . . . . . . . . . . . . 12 5.1.3. Broadcast Storm . . . . . . . . . . . . . . . . . . . 13
5.2. Routing Loops . . . . . . . . . . . . . . . . . . . . . . 13 5.2. Routing Loops . . . . . . . . . . . . . . . . . . . . . . 14
5.3. Invalid or Non-Existing Paths to Destinations . . . . . . 14 5.3. Invalid or Non-Existing Paths to Destinations . . . . . . 14
5.4. Data Sinkhole . . . . . . . . . . . . . . . . . . . . . . 14 5.4. Data Sinkhole . . . . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
The Neighborhood Discovery Protocol (NHDP) [RFC6130] allows routers The Neighborhood Discovery Protocol (NHDP) [RFC6130] allows routers
to acquire topological information up to two hops away from to acquire topological information up to two hops away from
themselves, by way of periodic HELLO message exchanges. The themselves, by way of periodic HELLO message exchanges. The
information acquired by NHDP is used by other protocols, such as information acquired by NHDP is used by other protocols, such as
OLSRv2 [OLSRv2] and SMF [SMF]. The topology information, acquired by OLSRv2 [OLSRv2] and SMF [RFC6621]. The topology information,
way of NHDP, serves these routing protocols for calculating paths to acquired by way of NHDP, serves these routing protocols for
all destinations in the MANET, for relay set selection for network- calculating paths to all destinations in the MANET, for relay set
wide transmissions, etc. selection for network-wide transmissions, etc.
As NHDP is typically used in wireless environments, it is potentially As NHDP is typically used in wireless environments, it is potentially
exposed to different kinds of security threats, some of which are of exposed to different kinds of security threats, some of which are of
particular significance as compared to wired networks. As wireless particular significance as compared to wired networks. As wireless
radio waves can be captured as well as transmitted by any wireless radio waves can be captured as well as transmitted by any wireless
device within radio range, there is commonly no physical protection device within radio range, there is commonly no physical protection
as otherwise known for wired networks. NHDP does not define any as otherwise known for wired networks. NHDP does not define any
explicit security measures for protecting the integrity of the explicit security measures for protecting the integrity of the
information it acquires, however suggests that this be addressed in a information it acquires, however suggests that this be addressed in a
fashion appropriate to the deployment of the network. fashion appropriate to the deployment of the network.
skipping to change at page 10, line 26 skipping to change at page 10, line 26
. . . .
. . . .
..... ..... ..... .....
. B . . B . . B . . B .
..... ..... ..... .....
t0 t1 t2 t3 t0 t1 t2 t3
Figure 3 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
mechanism.".
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.
5. Impact of inconsistent Information Bases on Protocols using NHDP 5. Impact of inconsistent Information Bases on Protocols using NHDP
This section describes the impact on protocols, using NHDP, of NHDP This section describes the impact on protocols, using NHDP, of NHDP
failing to obtain and represent accurate information, possibly as a failing to obtain and represent accurate information, possibly as a
consequence of the attacks described in Section 4. This description consequence of the attacks described in Section 4. This description
emphasizes the impacts on the MANET protocols OLSRv2 [OLSRv2], and emphasizes the impacts on the MANET protocols OLSRv2 [OLSRv2], and
SMF [SMF]. SMF [RFC6621].
5.1. MPR Calculation 5.1. MPR Calculation
MPR selection (as used in e.g., [OLSRv2] and [SMF]) uses information MPR selection (as used in e.g., [OLSRv2] and [RFC6621]) uses
about a router's 1-hop and 2-hop neighborhood, assuming that (i) this information about a router's 1-hop and 2-hop neighborhood, assuming
information is accurate, and (ii) all 1-hop neighbors are apt to act that (i) this information is accurate, and (ii) all 1-hop neighbors
as as MPR, depending on the willingness they report. Thus, a are apt to act as as MPR, depending on the willingness they report.
Compromised NHDP router will seek to manipulate the 1-hop and 2-hop Thus, a Compromised NHDP router will seek to manipulate the 1-hop and
neighborhood information in a router such as to cause the MPR 2-hop neighborhood information in a router such as to cause the MPR
selection to fail, leading to a flooding disruption of TC messages. selection to fail, leading to a flooding disruption of TC messages.
5.1.1. Flooding Disruption due to Identity Spoofing 5.1.1. Flooding Disruption due to Identity Spoofing
A Compromised NHDP router can spoof the identify of other routers, to A Compromised NHDP router can spoof the identify of other routers, to
disrupt the MPR selection, so as to cache certain parts of the disrupt the MPR selection, so as to cache certain parts of the
network from the flooding traffic. network from the flooding traffic.
In Figure 4, a Compromised NHDP router X spoofs the identity of B. 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 The link between X and C is correctly detected and listed in X's
skipping to change at page 14, line 38 skipping to change at page 15, line 28
6. Security Considerations 6. Security Considerations
This document does not specify a protocol or a procedure. The This document does not specify a protocol or a procedure. The
document, however, reflects on security considerations for NHDP and document, however, reflects on security considerations for NHDP and
MANET routing protocols using NHDP for neighborhood discovery. MANET routing protocols using NHDP for neighborhood discovery.
7. IANA Considerations 7. IANA Considerations
This document contains no actions for IANA. This document contains no actions for IANA.
8. References 8. Acknowledgments
8.1. Normative References The authors would like to gratefully acknowledge the following people
for valuable comments and technical discussions: Teco Boot, Henning
Rogge, Christopher Dearlove, John Dowdell, and the all the other
participants of IETF MANET working group.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
"Generalized MANET Packet/Message Format", RFC 5444, "Generalized MANET Packet/Message Format", RFC 5444,
February 2009. February 2009.
[RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value
Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497,
March 2009. March 2009.
[RFC6130] Clausen, T., Dean, J., and C. Dearlove, "MANET [RFC6130] Clausen, T., Dean, J., and C. Dearlove, "MANET
Neighborhood Discovery Protocol (NHDP)", RFC 6130, Neighborhood Discovery Protocol (NHDP)", RFC 6130,
April 2011. April 2011.
8.2. Informative References 9.2. Informative References
[OLSRv2] Clausen, T., Dearlove, C., Philippe, P., and U. Herberg, [OLSRv2] Clausen, T., Dearlove, C., Philippe, P., and U. Herberg,
"The Optimized Link State Routing Protocol version 2", "The Optimized Link State Routing Protocol version 2",
work in progress draft-ietf-manet-olsrv2-17.txt, work in progress draft-ietf-manet-olsrv2-18.txt,
October 2012. March 2013.
[SMF] Macker, J., "Simplified Multicast Forwarding", RFC 6621, [RFC6621] Macker, J., "Simplified Multicast Forwarding", RFC 6621,
March 2012. March 2012.
[broadcast-storm] [broadcast-storm]
Ni, S., Tseng, Y., Chen, Y., and J. Sheu, "The Broadcast Ni, S., Tseng, Y., Chen, Y., and J. Sheu, "The Broadcast
Storm Problem in a Mobile Ad Hoc Network", Proceedings of Storm Problem in a Mobile Ad Hoc Network", Proceedings of
the 5th annual ACM/IEEE international conference on Mobile the 5th annual ACM/IEEE international conference on Mobile
computing and networking, 1999. computing and networking, 1999.
Authors' Addresses Authors' Addresses
 End of changes. 18 change blocks. 
34 lines changed or deleted 71 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/