draft-ietf-manet-nhdp-sec-01.txt   draft-ietf-manet-nhdp-sec-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: Standards Track T. Clausen Intended status: Standards Track T. Clausen
Expires: September 13, 2012 LIX, Ecole Polytechnique Expires: November 30, 2012 LIX, Ecole Polytechnique
March 12, 2012 May 29, 2012
Using Integrity Check Values and Timestamps in NHDP Using Integrity Check Values and Timestamps For Router Admittance in
draft-ietf-manet-nhdp-sec-01 NHDP
draft-ietf-manet-nhdp-sec-02
Abstract Abstract
This document specifies a security extension to the MANET Neighbor This document specifies a security extension to the MANET
Discovery Protocol (NHDP). The extension introduces the use of Neighborhood Discovery Protocol (NHDP). The extension introduces the
Integrity Check Values (ICVs) and Timestamps in HELLO messages in use of Integrity Check Values (ICVs) and Timestamps in HELLO messages
order to counter a selection of security threats to NHDP. in order to provide a router admittance mechanism, and therefore to
counter a selection of security threats to 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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 September 13, 2012. This Internet-Draft will expire on November 30, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 3 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 4
4. Protocol Overview and Functioning . . . . . . . . . . . . . . 4 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 5
5. HELLO Message Content . . . . . . . . . . . . . . . . . . . . 5 5. HELLO Message Content . . . . . . . . . . . . . . . . . . . . 5
6. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 5 6. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 6
7. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 6 7. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 6
8. Validating ICVs . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Invalidating a Message Based on ICVs . . . . . . . . . . . 7
9. Validating a Timestamp . . . . . . . . . . . . . . . . . . . . 7 7.2. Invalidating a Message Based on Timestamps . . . . . . . . 8
10. Provisioning of NHDP Routers . . . . . . . . . . . . . . . . . 8 8. Provisioning of NHDP Routers . . . . . . . . . . . . . . . . . 9
11. Summary of NHDP Interaction . . . . . . . . . . . . . . . . . 8 9. Summary of NHDP Interaction . . . . . . . . . . . . . . . . . 9
12. Security Threats Alleviation Analysis . . . . . . . . . . . . 9 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
12.1. Jamming . . . . . . . . . . . . . . . . . . . . . . . . . 9 11. Security Considerations . . . . . . . . . . . . . . . . . . . 9
12.2. Identity Spoofing . . . . . . . . . . . . . . . . . . . . 9 11.1. Alleviated Attacks . . . . . . . . . . . . . . . . . . . . 10
12.3. Link Spoofing . . . . . . . . . . . . . . . . . . . . . . 9 11.1.1. Identity Spoofing . . . . . . . . . . . . . . . . . . 10
12.4. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 9 11.1.2. Link Spoofing . . . . . . . . . . . . . . . . . . . . 10
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 11.1.3. Replay Attack . . . . . . . . . . . . . . . . . . . . 10
14. Security Considerations . . . . . . . . . . . . . . . . . . . 10 11.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 10
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
16. Normative References . . . . . . . . . . . . . . . . . . . . . 10 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
13.1. Normative References . . . . . . . . . . . . . . . . . . . 11
13.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
This document specifies the use of Integrity Check Values (ICVs) in This document specifies the use of Integrity Check Values (ICVs) for
the MANET Neighborhood Discovery Protocol (NHDP) [RFC6130] for router admittance in the MANET Neighborhood Discovery Protocol (NHDP)
countering a selection of the security threats analyzed in [RFC6130]. It specifies the use of such ICVs for validating the
[NHDP-sec-threats]. It specifies the use of such ICVs for validating identity of the originator of a HELLO message, for validating of the
the identity of the originator of a HELLO message, for validating of content (i.e., the links being advertised) of a HELLO message, and
the content (i.e., the links being advertised) of a HELLO message, for validating the message integrity.
and for validating the message integrity. The protection so offered
against the threats in [NHDP-sec-threats] is evaluated.
This document uses the TLVs defined in [packetbb-sec] within NHDP This document uses the TLVs defined in [RFC6622] within NHDP HELLO
HELLO messages, and specifies extensions (as enabled by Section 16 in messages, and specifies extensions (as enabled by Section 16 in
[RFC6130]) to the HELLO message processing. [RFC6130]) to the HELLO message processing.
Schematically, the mechanism specified in this document inserts
itself between [RFC6130] processing/generation of HELLO messages and
[RFC5444] encoding/decoding as illustrated in Figure 1.
Incoming | | Outgoing
HELLO Message | /|\ HELLO Message
| |
| |
\|/ |
| |
+--------------------------------+
| |
| RFC5444 Parser / Generator |
| |
+--------------------------------+
| |
Hello Message \|/ /|\ RFC6622 ICVs
Parsed | | added
D +--------------------------------+
R /_________________ | |
O \ICV not | This Specification |
P Verified | |
+--------------------------------+
| |
ICV verified \|/ /|\ HELLO Message
| | Generated
+--------------------------------+
| |
| RFC6130 |
| Processing/Generation |
+--------------------------------+
Figure 1: Relationship with RFC5444 and RFC6130.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119]. 2119 [RFC2119].
Additionally, this document uses the terminology of [RFC5444], Additionally, this document uses the terminology of [RFC5444],
[packetbb-sec], [RFC6130] and [NHDP-sec-threats]. [RFC6130], and [RFC6622].
Additionally, this document introduces the following terminology: Additionally, this document introduces the following terminology:
NHDP Router: A MANET router, running NHDP as specified in [RFC6130]. NHDP Router:
A MANET router, running NHDP as specified in [RFC6130].
3. Applicability Statement 3. Applicability Statement
[RFC6130] enables extensions to recognize additional reasons for [RFC6130] enables extensions to recognize additional reasons for
rejecting a message as malformed, and mentions security as an rejecting a message as "badly formed and therefore invalid for
explicit example. processing", and mentions security as an explicit example.
This document: This document:
o Specifies an extension to [RFC6130] by providing a framework for o Specifies an extension to [RFC6130] by providing a framework for
associating ICVs to messages and for using such invalid ICVs as associating ICVs to messages and for using such invalid ICVs as
one such "additional reason" for rejecting a message as malformed. one such "additional reason" for rejecting a message as "badly
formed and therefore invalid for processing".
o Uses the containers for carrying ICVs and timestamps, as well as o Uses the containers for carrying ICVs and timestamps, as well as
the registries for cryptographic code-points, specified in the registries for cryptographic code-points, specified in
[packetbb-sec]. [RFC6622].
o Is applicable where ICVs are an appropriate security solution. o Is applicable where ICVs are an appropriate security solution.
Note that the choice of the cryptographic algorithm are to be made Note that the choice of the cryptographic function are to be made
for each given deployment, and that the choice of such is out of for each given deployment, and that the choice of such is out of
scope for this document. scope for this document.
o Assumes that a router which is able to generate correct ICVs o Assumes that a router which is able to generate correct ICVs
(e.g., has valid cryptographic keys), is considered trusted. (e.g., has valid cryptographic keys), is considered trusted.
o Assumes that the TLV type extension of the ICV Message TLV, as o Assumes that the TLV type extension of the ICV Message TLV, as
defined in [packetbb-sec] is 1, i.e., that an ICV is composed of a defined in [RFC6622] is 1, i.e., that an ICV is composed of a
cryptographic function over a hash value of the message as defined cryptographic function over a hash value of the message as defined
in Section 12 of [packetbb-sec]. in Section 12 of [RFC6622].
This document does NOT: This document does NOT:
o Specify how to distribute cryptographic keys, shared secrets, o Specify how to distribute cryptographic keys, shared secrets,
parameters for cryptographic algorithms, etc. parameters for cryptographic functions, etc.
o Specify how to detect compromised routers with valid keys. o Specify how to detect compromised routers with valid keys.
o Specify how to handle compromised routers with valid keys, i.e., o Specify how to handle compromised routers with valid keys, i.e.,
key-revocation etc. key-revocation etc.
4. Protocol Overview and Functioning 4. Protocol Overview and Functioning
The framework presented in this document provides two The framework presented in this document provides two
functionalities: functionalities:
o Generation of an ICV for an outgoing HELLO message. o Generation of an ICV for an outgoing HELLO message.
o Verification of an ICV in order to determine if an incoming HELLO o Verification of an ICV in order to determine if an incoming HELLO
message SHOULD be rejected as malformed. message MUST be rejected as "badly formed and therefore invalid
for processing" [RFC6130].
When an NHDP Router generates a HELLO message on an interface, this When an NHDP Router generates a HELLO message on an interface, this
extension: extension:
o Specifies how to calculate an ICV for the message. o Specifies how to calculate an ICV for the message.
o Specifies how to include that ICV by way of a TLV. o Specifies how to include that ICV by way of a TLV.
The framework allows to add several ICVs with different hash and The framework allows for adding several ICVs with different hash and
cryptographic functions. cryptographic functions.
[RFC6130] allows to reject incoming HELLO messages prior to [RFC6130] allows for rejecting incoming HELLO messages prior to
processing by NHDP. This extension specifies that for each ICV TLV processing by NHDP. This extension specifies that for each ICV TLV
in the Message TLV Block of an incoming message, the message MUST be in the Message TLV Block of an incoming message, the message MUST be
rejected if the ICV can not be verified. rejected if the ICV can not be verified.
5. HELLO Message Content 5. HELLO Message Content
HELLO messages MUST be generated as specified in [RFC6130]. In HELLO messages MUST have the content as specified in [RFC6130]. In
addition, in order to conform to this specification, each HELLO addition, in order to conform to this specification, each HELLO
message MUST contain: message MUST contain:
o A <msg-orig-addr> element (as specified in [RFC5444]). o A <msg-orig-addr> element (as specified in [RFC5444]).
o A <msg-seq-num> element (as specified in [RFC5444]). o A <msg-seq-num> element (as specified in [RFC5444]).
o One, or more, ICV TLVs (as specified in [packetbb-sec]), generated o One or more ICV TLVs (as specified in [RFC6622]), generated
according to Section 6. according to Section 6.
If protection against replay attacks is desired, then a HELLO message If protection against replay attacks is desired, then a HELLO message
MUST also contain: MUST also contain:
o A TIMESTAMP TLV (as specified in [packetbb-sec]). o A TIMESTAMP TLV (as specified in [RFC6622]).
6. HELLO Message Generation 6. HELLO Message Generation
After the HELLO message generation and before HELLO message After HELLO message generation ([RFC6130] Section 11.1) and before
transmission, as permitted by [RFC6130], the additional elements HELLO message transmission ([RFC6130] Section 11.2), as permitted by
specified in Section 5 MUST (unless already present) be added to an [RFC6130] Section 12.1, the additional elements specified in
outgoing HELLO message. Section 5 MUST (unless already present) be added to an outgoing HELLO
message.
The following processing steps MUST be taken for each cryptographic The following processing steps MUST be taken for each cryptographic
algorithm that is used for generating ICVs for a HELLO message: algorithm that is used for generating ICVs for a HELLO message:
1. All existing TLVs (if any) of type ICV are temporarily removed 1. All existing TLVs (if any) of type ICV are temporarily removed
from the message. Any temporarily removed TLVs MUST be stored, from the message. Any temporarily removed TLVs MUST be stored,
for being reinserted into the message in step 5. for being reinserted into the message in step 5.
2. The message size is recalculated to the size of the message 2. The message size is recalculated to the size of the message
without the temporarily removed ICV TLVs. without the temporarily removed ICV TLVs.
3. The ICV value is calculated over the whole message (as resulting 3. The ICV value is calculated over the whole message (as resulting
after step 2) according to the chosen hash and cryptographic after step 2) according to the chosen hash and cryptographic
function and according to Section 12.1 of [packetbb-sec]. function and according to Section 12.1 of [RFC6622].
4. A TLV of type ICV and with type extension 1 is added in the 4. A TLV of type ICV and with type extension 1 is added in the
message TLV block, with the content according to Section 12.1 of Message TLV block, with the content according to Section 12.1 of
[packetbb-sec]. [RFC6622].
5. All other ICV TLVs that have been temporary removed, are 5. All other ICV TLVs that have been temporary removed, are
restored. restored.
6. The message size is recalculated, including the new ICV TLV as 6. The message size is recalculated, including the new ICV TLV as
well as any restored temporarily removed ICV TLVs. well as any restored temporarily removed ICV TLVs.
7. HELLO Message Processing 7. HELLO Message Processing
[RFC6130] specifies that: [RFC6130] specifies that:
"On receiving a HELLO message, a router MUST first check if the "On receiving a HELLO message, a router MUST first check if the
message is invalid for processing by this router" message is invalid for processing by this router"
[RFC6130] proceeds to give a number of conditions that, each, will [RFC6130] proceeds to give a number of conditions that, each, will
lead to a rejection of the HELLO message. This document adds the lead to a rejection of the HELLO message as "badly formed and
following conditions to that list which, if true, MUST cause NHDP to therefore invalid for processing". This document adds the following
consider the HELLO message as invalid for processing: conditions to that list which, if true, MUST cause NHDP to consider
the HELLO message as invalid for processing:
o The HELLO message does not include a <msg-orig-addr> element. o The HELLO message does not include a <msg-orig-addr> element.
o The HELLO message does not include a <msg-seq-num> element. o The HELLO message does not include a <msg-seq-num> element.
o The Message TLV block of the HELLO message contains more than one o The Message TLV block of the HELLO message contains more than one
TIMESTAMP TLV with the same "Type Extension". TIMESTAMP TLV with the same type extension.
o Any ICV in the Message TLV block of the HELLO message is invalid,
according to Section 8.
o The value of the TIMESTAMP TLV of the message is invalid as o Validation of ICVs in the Message TLV block of the HELLO message
specified in Section 9. fails, according to Section 7.1.
8. Validating ICVs o If protection against replay attacks is desired, validation of the
TIMESTAMP TLV of the message fails, according to Section 7.2.
The included ICVs in an incoming HELLO message are processed as 7.1. Invalidating a Message Based on ICVs
follows:
1. For each ICV Message TLV in the HELLO message, the ICV TLV is 1. For each ICV Message TLV in the HELLO message, the ICV TLV is
temporarily removed if: temporarily removed if:
* The ICV TLV "Type Extension" is not equal to 1; OR * The ICV Message TLV type extension is not equal to 1; OR
* The ICV TLV "Type Extension" is equal to 1, AND the hash * The ICV Message TLV type extension is equal to 1, AND the hash
function and the cryptographic function indicated in that ICV function and the cryptographic function indicated in that ICV
TLV are unknown to the NHDP Router. Messsage TLV are unknown to the NHDP Router.
2. If no ICV TLVs remain after step 1, validation fails and the 2. If no ICV Message TLVs remain after step 1, then validation
message MUST be considered invalid for processing and MUST be fails:
discarded.
3. Otherwise, the message with the remaining ICV TLVs (henceforth: * The HELLO message MUST be considered "badly formed and
"Known ICV TLVs") is processed as follows: therefore invalid for processing", and MUST be discarded.
1. All Known ICV TLVs are temporarily removed from the message, 3. Otherwise, the HELLO message with the remaining ICV Message TLVs
and the message size is recalculated. (henceforth: "Known ICV Message TLVs") is processed as follows:
2. Each of the temporarily removed Known ICV TLVs from the step 1. All Known ICV Message TLVs are temporarily removed from the
above is, then, validated as follows: message, and the message size is recalculated.
2. Each of the temporarily removed Known ICV Message TLVs from
the step above is, then, processed as follows:
+ Calculate the message-hash-value over the HELLO message, + Calculate the message-hash-value over the HELLO message,
using the hash function indicated by <hash-function> in using the hash function indicated by <hash-function> in
the ICV TLV. the Known ICV Message TLV.
+ Calculate the message-ICV-Value over the resulting + Calculate the message-ICV-Value over the resulting
message-hash-value, using the cryptographic function, and message-hash-value, using the cryptographic function, and
the key ID, indicated by <cryptographic-function> and the key ID, indicated by <cryptographic-function> and
<key-id> in the ICV TLV. <key-id> in the Known ICV Message TLV.
+ If message-ICV-Value differs from the value of <ICV-data> + If message-ICV-Value differs from the value of <ICV-data>
in the ICV, then the ICV validation has failed: in the Known ICV Message TLV, then validation fails:
- The HELLO message MUST be considered invalid for - The HELLO message MUST be considered "badly formed and
processing and MUST be discarded. therefore invalid for processing", and MUST be
discarded.
4. Then: 4. Otherwise, the message is considered (with respect to this
specification) "valid for processing", and:
A. All temporarily removed ICV TLVs are restored (i.e., all ICV A. All temporarily removed ICV Message TLVs (i.e., all ICV TLVs
TLVs temporarily removed in both step 1 and step 3). temporarily removed in both step 1 and step 3) are restored.
B. The message size is restored. B. The message size is restored.
5. The message can now be processed according to [RFC6130]. 7.2. Invalidating a Message Based on Timestamps
9. Validating a Timestamp
If an NHDP Router is configured to require protection against replay
attacks, then TIMESTAMP TLVs in incoming HELLO messages MUST be
validated. Unless this validation succeeds, the HELLO message MUST
be discarded.
In order to undertake this validation, an NHDP Router which requires An NHDP Router which requires protection against replay attacks MUST:
protection against replay attacks MUST:
o Be configured with a list of TIMESTAMP "Type Extensions", which it o Be configured with a list of TIMESTAMP type extensions, which it
supports. supports.
o For each of these TIMESTAMP "Type Extensions", define o For each of these TIMESTAMP type extensions, define
MAX_TIMESTAMP_DIFF as the maximum allowed difference between the MAX_TIMESTAMP_DIFF as the maximum allowed difference between the
"expected timestamp value" and the "timestamp value" encoded in "expected timestamp value" and the "timestamp value" encoded in
the TIMESTAMP TLV of an incoming HELLO message (e.g., to the TIMESTAMP TLV of an incoming HELLO message (e.g., to
accommodate for propagation delays across a network). accommodate for propagation delays across a network).
An incoming HELLO message MUST be considered invalid if: A HELLO message MUST be considered "badly formed and therefore
invalid for processing", and MUST be discarded if either of the two
following conditions are true:
o The Message TLV Block of the HELLO message does not contain a o The Message TLV Block of the HELLO message does not contain a
TIMESTAMP TLV with a "Type Extension" matching (one of) the TIMESTAMP TLV with a type extension matching (one of) the
timestamp types, known by the receiving NHDP Router. timestamp types, known by the receiving NHDP Router.
o The Message TLV Block of the HELLO message does contain a o The Message TLV Block of the HELLO message does contain a
TIMESTAMP TLV with a Type Extension matching (one of) the TIMESTAMP TLV with a type extension matching (one of) the
timestamp types, known by the receiving NHDP Router, but where the timestamp types, known by the receiving NHDP Router, but where the
value of that TIMESTAMP TLV differs from the expected value by value of that TIMESTAMP TLV differs from the expected value by
more than MAX_TIMESTAMP_DIFF. more than MAX_TIMESTAMP_DIFF.
10. Provisioning of NHDP Routers 8. Provisioning of NHDP Routers
Before an NHDP Router is able to generate ICVs or validate messages, Before an NHDP Router is able to generate ICVs or validate messages,
it MUST acquire the cryptographic key(s) and any parameters of the it MUST acquire the cryptographic key(s) and any parameters of the
cryptographic algorithm from all other routers that are to cryptographic function from all other routers that are to participate
participate in the network. This document does not specify how a in the network. This document does not specify how a router acquires
router acquires the cryptographic keys and parameters used in the the cryptographic keys and parameters used in the MANET.
MANET.
11. Summary of NHDP Interaction 9. Summary of NHDP Interaction
When using the NHDP security extension, specified in this document, When using the NHDP security extension, specified in this document,
the following MUST be observed: the following MUST be observed:
o HELLO messages MUST be generated according to [RFC6130]. o HELLO messages MUST be generated according to [RFC6130].
o Outgoing HELLO messages, generated by [RFC6130] MUST be processed o Outgoing HELLO messages, generated by [RFC6130], MUST be processed
according to Section 6 after their generation and prior to their according to Section 6 after their generation and prior to their
transmission by [RFC6130], in order that (an) ICV TLV(s) can be transmission by [RFC6130], in order that (an) ICV TLV(s) can be
generated and inserted, as allowed by Section 16 in [RFC6130]. generated and inserted, as allowed by Section 16 in [RFC6130].
o Any other extension to [RFC6130] which adds information to a HELLO o Any other extension to [RFC6130] which adds information to a HELLO
message MUST do so prior to the HELLO message being handed off for message MUST do so prior to the HELLO message being handed off for
ICV generation according to this specification. ICV generation according to this specification.
o An incoming HELLO message MUST be processed according to Section 7 o An incoming HELLO message MUST be processed according to Section 7
prior to processing by [RFC6130] as allowed in Section 16 in prior to processing by [RFC6130] as allowed in Section 16 in
[RFC6130]. [RFC6130].
o Any other NHDP extension, which has added information to a HELLO o Any other NHDP extension, which has added information to a HELLO
message and which wishes that the HELLO message is rejected if an message and which wishes that the HELLO message is rejected if an
ICV is not valid, MUST likewise process the HELLO message only ICV is not valid, MUST likewise process the HELLO message only
after its processing according to this specification. after its processing according to this specification.
12. Security Threats Alleviation Analysis 10. IANA Considerations
This document has no actions for IANA.
11. Security Considerations
This document specifies a protocol extension to NHDP which allows for
alleviating some of the security threats of NHDP analyzed in
[NHDP-sec-threats].
11.1. Alleviated Attacks
This section briefly summarizes which of the security threats, from This section briefly summarizes which of the security threats, from
among those detailed in [NHDP-sec-threats], that are alleviated by among those detailed in [NHDP-sec-threats], that are alleviated by
the framework presented in this document. the framework presented in this document.
12.1. Jamming 11.1.1. Identity Spoofing
Since jamming is a physical layer issue, it cannot be alleviated by
protocols on the routing layer. This framework does not counteract
jamming attacks.
12.2. Identity Spoofing
As only NHDP Routers possessing valid cryptographic keys are able to As only NHDP Routers possessing valid cryptographic keys are able to
add ICV TLVs HELLO messages, in a way which permits that these be add ICV TLVs HELLO messages, in a way which permits that these be
validated successfully, identity spoofing is counteracted. validated successfully, identity spoofing is counteracted.
12.3. Link Spoofing 11.1.2. Link Spoofing
Link spoofing is counteracted by the framework specified in this Link spoofing is counteracted by the framework specified in this
document, with the same argument as in Section 12.2. A router document, with the same argument as in Section 11.1.1. A router
without access to valid cryptographic keys cannot generate valid ICVs without access to valid cryptographic keys cannot generate valid ICVs
for inclusion in a HELLO message. for inclusion in a HELLO message.
12.4. Replay Attack 11.1.3. Replay Attack
Replay attacks are only counteracted if TIMESTAMP TLVs are included Replay attacks are only counteracted if TIMESTAMP TLVs are included
in HELLO messages. This is optional, and depends on synchronized in HELLO messages. This is optional, and depends on synchronized
clocks of all routers in the MANET. An attacker which records clocks of all routers in the MANET. An attacker which records
messages to replay them later can only do so in the time interval messages to replay them later can only do so in the time interval
between the timestamp that is contained in the TIMESTAMP TLV and between the timestamp that is contained in the TIMESTAMP TLV and
MAX_TIMESTAMP_DIFF seconds later. As an attacker cannot modify the MAX_TIMESTAMP_DIFF later. As an attacker cannot modify the content
content of the TIMESTAMP TLV (since it does not possess the valid of the TIMESTAMP TLV (since it does not possess the valid
cryptographic keys for generating valid ICV TLVs), it cannot replay cryptographic keys for generating valid ICV TLVs), it cannot replay
messages after this time interval. Within this time interval, messages after this time interval. Within this time interval,
however, it is still possible to replay attacks. however, it is still possible to perform replay attacks.
13. IANA Considerations
This document has no actions for IANA.
14. Security Considerations 11.2. Limitations
This document specifies a protocol extension to NHDP which allows to Since jamming is a physical layer issue, it cannot be alleviated by
alleviate some of the security threats of NHDP analyzed in protocols on the routing layer. This framework does not counteract
[NHDP-sec-threats]. jamming attacks.
If no synchronized clocks are available in the MANET, replay attacks If no synchronized clocks are available in the MANET, replay attacks
cannot be counteracted by the framework provided by this document. cannot be counteracted by the framework provided by this document.
The framework provided by this document does not avoid or detect The framework provided by this document does not avoid or detect
security attacks by routers possessing the cryptographic keys that security attacks by routers possessing the cryptographic keys that
are used to generate ICVs for messages. are used to generate ICVs for messages.
This document depends on the quality of the used cipher algorithm and This document depends on the quality of the used cipher algorithm and
hash function, and is as such subject the same security hash function, and is as such subject the same security
considerations as applies to these. considerations as applies to these.
This document relies on an out-of-band protocol or mechanism for This document relies on an out-of-band protocol or mechanism for
distributing keys and cryptographic parameters. The security distributing keys and cryptographic parameters. The security
considerations of such protocol or mechanism also apply. considerations of such protocol or mechanism also apply.
This document does also not provide a key revocation mechanism. This document does also not provide a key revocation mechanism.
15. Acknowledgments 12. Acknowledgments
The authors would like to thank Jiazi Yi (Ecole Polytechnique) for The authors would like to thank Jiazi Yi (Ecole Polytechnique) for
his review and comments to this document. his review and comments to this document.
16. Normative References 13. References
[NHDP-sec-threats] 13.1. Normative References
Herberg, U., Clausen, T., and J. Yi, "Security Threats for
NHDP", work in
progress draft-herberg-manet-nhdp-sec-threats-01.txt,
March 2012.
[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.
[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, March 2011. RFC 6130, March 2011.
[packetbb-sec] [RFC6622] Herberg, U. and T. Clausen, "Integrity Check Value and
Herberg, U. and T. Clausen, "Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks
Timestamp TLV Definitions for MANETs", work in (MANETs)", RFC 6622, May 2012.
progress draft-ietf-manet-packetbb-sec-09.txt, March 2012.
13.2. Informative References
[NHDP-sec-threats]
Herberg, U., Clausen, T., and J. Yi, "Security Threats for
NHDP", work in
progress draft-ietf-manet-nhdp-sec-threats-00.txt,
April 2012.
Authors' Addresses Authors' Addresses
Ulrich Herberg Ulrich Herberg
Fujitsu Laboratories of America Fujitsu Laboratories of America
1240 E. Arques Ave. 1240 E. Arques Ave.
Sunnyvale, CA, 94085, Sunnyvale, CA, 94085,
USA USA
Email: ulrich@herberg.name Email: ulrich@herberg.name
 End of changes. 70 change blocks. 
146 lines changed or deleted 184 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/