draft-ietf-manet-nhdp-sec-threats-04.txt   draft-ietf-manet-nhdp-sec-threats-05.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: December 8, 2013 T. Clausen Expires: December 12, 2013 T. Clausen
LIX, Ecole Polytechnique LIX, Ecole Polytechnique
June 6, 2013 June 10, 2013
Security Threats for NHDP Security Threats for NHDP
draft-ietf-manet-nhdp-sec-threats-04 draft-ietf-manet-nhdp-sec-threats-05
Abstract Abstract
This document analyzes common security threats of the Neighborhood This document analyzes 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. This document is not intended to MANET routing protocols using NHDP. This document is not intended to
propose solutions to the threats described. propose solutions to the threats described.
Status of this Memo Status of this Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 December 8, 2013. This Internet-Draft will expire on December 12, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 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
skipping to change at page 2, line 33 skipping to change at page 2, line 33
4.8. Attack on Link Quality Update . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 11 using NHDP . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. MPR Calculation . . . . . . . . . . . . . . . . . . . . . 11 5.1. MPR Calculation . . . . . . . . . . . . . . . . . . . . . 11
5.1.1. Flooding Disruption due to Identity Spoofing . . . . . 11 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 . . . . . . . . . . . . . . . . . . . 13 5.1.3. Broadcast Storm . . . . . . . . . . . . . . . . . . . 13
5.2. Routing Loops . . . . . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . . . . . 15 5.4. Data Sinkhole . . . . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
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 [I-D.ietf-manet-olsrv2] and SMF [RFC6621]. The topology OLSRv2 [I-D.ietf-manet-olsrv2] and SMF [RFC6621]. The topology
information, acquired by way of NHDP, serves these routing protocols information, acquired by way of NHDP, serves these routing protocols
by detecting and maintaining local 1-hop and 2-hop neighborhood by detecting and maintaining local 1-hop and 2-hop neighborhood
skipping to change at page 15, line 18 skipping to change at page 15, line 18
routers (by eavesdropping, for example), the Compromised NHDP router routers (by eavesdropping, for example), the Compromised NHDP router
can represent a "data sinkhole" for its 1-hop and 2-hop neighbors. 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 Data packets that come across its neighbors may be forwarded to the
Compromised NHDP router instead of to the real destination. The Compromised NHDP router instead of to the real destination. The
packet can then be dropped, manipulated, duplicated, etc., by the packet can then be dropped, manipulated, duplicated, etc., by the
Compromised NHDP router. As shown in Figure 8, if the Compromised Compromised NHDP router. As shown in Figure 8, if the Compromised
NHDP router X spoofs the identity of NHDP router E, all the data 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 packets to E that cross NHDP routers A and B will be sent to NHDP
router X, instead of to E. router X, instead of to E.
6. Security Considerations 6. Future Work
This document does not propose solutions to mitigate the security
threats described in Section 4. However, this section aims at
driving new work by suggesting which threats discussed in Section 4
could be addressed in new protocol work, which in deployment, and
which by applications:
o Section 4.1: Jamming - If a single router or a small area of the
MANET is jammed, protocols could be specified that increase link
metrics in NHDP for the jammed links. When a routing protocol,
such as OLSRv2, uses NHDP for neighborhood discovery, other paths
leading "around" the jammed area would be preferred, and therefore
mitigate the threat to some extent.
o Section 4.2: DoS - DoS using a massive amount of HELLO messages
can be mitigated by admitting only trusted routers to the network.
[I-D.ietf-manet-nhdp-olsrv2-sec] specifies a mechanism for adding
Integrity Check Values (ICVs) to HELLO messages and therefore
providing an admittance mechanism for NHDP routers to a MANET.
(Note that adding ICVs adds itself a new DoS attack vector, as ICV
verification requires CPU and memory resources.) Using ICVs does
however not address the problem of compromised routers. Detecting
compromised routers could be addressed in new work.
[I-D.ietf-manet-nhdp-olsrv2-sec] mandates to implement a security
mechanism based on shared keys, which makes excluding single
compromised routers difficult; work could be done to facilitate
revocation mechanisms in certain MANET use cases where routers
have sufficient capabilities to support asymmetric keys.
o Section 4.3: Eavesdropping - [I-D.ietf-manet-nhdp-olsrv2-sec] adds
ICVs to HELLO messages, but does not encrypt them. Therefore,
eavesdropping of control traffic is not mitigated. Future work
could provide encryption of control traffic for sensitive MANET
topologies. Note that, other than using a single shared secret
key, encryption to a potentially a priori unknown set of
neighbors, especially without multiplying overheads, is non-
trivial.
o Section 4.4.2: Link spoofing - [I-D.ietf-manet-nhdp-olsrv2-sec]
provides certain protection against link spoofing, but an NHDP
Router has to "trust" the originator of a HELLO that the
advertized links are correct. For example, if a router A reports
a link to B, routers receiving HELLOs from A have to trust that B
is actually a (symmetric) neighbor of A. New protocol work could
address protection of links without overly increasing space and
time overheads. An immediate suggestion for deployments is to
protect routers against being compromised and distributing keys
only to trusted routers.
o Section 4.5: Replay Attacks - [I-D.ietf-manet-nhdp-olsrv2-sec]
provides certain protection against replay attacks, using ICVs and
timestamps. It is still feasible to replay control messages
within limited time. A suggestion for deployments is to provide
time synchronization between routers. New work could provide time
synchronization mechanisms for certain MANET use cases, or specify
a mechanism using nonces instead of time stamps in HELLO messages.
o Section 4.4.1: Identity spoofing, Section 4.6: Message timing
attacks, Section 4.7: Indirect channel overloading, and
Section 4.8: Attack on link quality update -
[I-D.ietf-manet-nhdp-olsrv2-sec] provides protection against these
attacks, assuming that routers are not compromised.
7. Security Considerations
This document does not specify a protocol or a procedure. The 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 8. IANA Considerations
This document contains no actions for IANA. This document contains no actions for IANA.
8. Acknowledgments 9. Acknowledgments
The authors would like to gratefully acknowledge the following people The authors would like to gratefully acknowledge the following people
for valuable comments and technical discussions: Teco Boot, Henning for valuable comments and technical discussions: Teco Boot, Henning
Rogge, Christopher Dearlove, John Dowdell, and the all the other Rogge, Christopher Dearlove, John Dowdell, and the all the other
participants of IETF MANET working group. participants of IETF MANET working group.
9. References 10. References
9.1. Normative References 10.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 Mobile Ad Hoc Network (MANET) Packet/Message "Generalized Mobile Ad Hoc Network (MANET) Packet/Message
Format", RFC 5444, February 2009. Format", RFC 5444, 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., Dearlove, C., and J. Dean, "Mobile Ad Hoc [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
Network (MANET) Neighborhood Discovery Protocol (NHDP)", Network (MANET) Neighborhood Discovery Protocol (NHDP)",
RFC 6130, April 2011. RFC 6130, April 2011.
9.2. Informative References 10.2. Informative References
[I-D.ietf-manet-nhdp-olsrv2-sec] [I-D.ietf-manet-nhdp-olsrv2-sec]
Herberg, U., Dearlove, C., and T. Clausen, "Integrity Herberg, U., Dearlove, C., and T. Clausen, "Integrity
Protection for Control Messages in NHDP and OLSRv2", Protection for Control Messages in NHDP and OLSRv2",
draft-ietf-manet-nhdp-olsrv2-sec-02 (work in progress), draft-ietf-manet-nhdp-olsrv2-sec-02 (work in progress),
April 2013. April 2013.
[I-D.ietf-manet-olsrv2] [I-D.ietf-manet-olsrv2]
Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
"The Optimized Link State Routing Protocol version 2", "The Optimized Link State Routing Protocol version 2",
 End of changes. 11 change blocks. 
17 lines changed or deleted 82 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/