draft-ietf-manet-nhdp-olsrv2-sec-05.txt   rfc7183.txt 
Mobile Ad hoc Networking (MANET) U. Herberg Internet Engineering Task Force (IETF) U. Herberg
Internet-Draft Fujitsu Laboratories of America Request for Comments: 7183 Fujitsu Laboratories of America
Updates: 6130, xxxx (if approved) C. Dearlove Updates: 6130, 7181 C. Dearlove
Intended status: Standards Track BAE Systems ATC Category: Standards Track BAE Systems ATC
Expires: March 14, 2014 T. Clausen ISSN: 2070-1721 T. Clausen
LIX, Ecole Polytechnique LIX, Ecole Polytechnique
September 10, 2013 April 2014
Integrity Protection for Control Messages in NHDP and OLSRv2 Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and
draft-ietf-manet-nhdp-olsrv2-sec-05 Optimized Link State Routing Protocol Version 2 (OLSRv2)
Abstract Abstract
This document specifies integrity and replay protection for the MANET This document specifies integrity and replay protection for the
Neighborhood Discovery Protocol (NHDP) and the Optimized Link State Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)
Routing Protocol version 2 (OLSRv2). This protection is achieved by and the Optimized Link State Routing Protocol version 2 (OLSRv2).
using an HMAC-SHA-256 Integrity Check Value (ICV) TLV and a timestamp This protection is achieved by using an HMAC-SHA-256 Integrity Check
TLV based on POSIX time. Value (ICV) TLV and a Timestamp TLV based on Portable Operating
System Interface (POSIX) time.
The mechanism in this specification can also be used for other The mechanism in this specification can also be used for other
protocols that use the generalized packet/message format described in protocols that use the generalized packet/message format described in
RFC 5444. RFC 5444.
This document updates RFC 6130 and RFC xxxx by mandating the This document updates RFC 6130 and RFC 7181 by mandating the
implementation of this integrity and replay protection in NHDP and implementation of this integrity and replay protection in NHDP and
OLSRv2. OLSRv2.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on March 14, 2014. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7183.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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 .....................................................4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Applicability Statement .........................................5
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 4 4. Protocol Overview and Functioning ...............................6
4. Protocol Overview and Functioning . . . . . . . . . . . . . . 6 5. Parameters ......................................................7
5. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Message Generation and Processing ...............................9
6. Message Generation and Processing . . . . . . . . . . . . . . 9 6.1. Message Content ............................................9
6.1. Message Content . . . . . . . . . . . . . . . . . . . . . 9 6.2. Message Generation ........................................10
6.2. Message Generation . . . . . . . . . . . . . . . . . . . . 10 6.3. Message Processing ........................................11
6.3. Message Processing . . . . . . . . . . . . . . . . . . . . 10 6.3.1. Validating a Message Based on Timestamp ............11
6.3.1. Validating a Message Based on Timestamp . . . . . . . 11 6.3.2. Validating a Message Based on Integrity Check ......12
6.3.2. Validating a Message Based on Integrity Check . . . . 12 7. Provisioning of Routers ........................................12
7. Provisioning of Routers . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations ........................................12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8.1. Mitigated Attacks .........................................13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8.1.1. Identity Spoofing ..................................13
9.1. Mitigated Attacks . . . . . . . . . . . . . . . . . . . . 13 8.1.2. Link Spoofing ......................................13
9.1.1. Identity Spoofing . . . . . . . . . . . . . . . . . . 13 8.1.3. Replay Attack ......................................13
9.1.2. Link Spoofing . . . . . . . . . . . . . . . . . . . . 13 8.2. Limitations ...............................................13
9.1.3. Replay Attack . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgments ................................................14
9.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 13 10. References ....................................................14
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 10.1. Normative References .....................................14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10.2. Informative References ...................................14
11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
[RFC Editor note: Please replace "xxxx" throughout this document with This specification updates [RFC6130] and [RFC7181] by defining
the RFC number assigned to [OLSRv2], and remove this note.] mandatory-to-implement security mechanisms (for integrity and replay
protection). A deployment of these protocols may choose to employ an
This specification updates [RFC6130] and [OLSRv2] by defining the alternative(s) to these mechanisms; in particular, it may choose to
mandatory to implement security mechanisms (for integrity and replay
protection). A deployment of these protocols may choose to employ
alternative(s) to these mechanisms, in particular it may choose to
protect packets rather than messages, it may choose to use an protect packets rather than messages, it may choose to use an
alternative integrity check value (ICV) with preferred properties, alternative Integrity Check Value (ICV) with preferred properties,
and/or it may use an alternative timestamp. A deployment may choose and/or it may use an alternative timestamp. A deployment may choose
to use no such security mechanisms, but this is not recommended. to use no such security mechanisms, but this is not recommended.
The mechanisms specified are the use of an ICV for protection of the The mechanisms specified are the use of an ICV for protection of the
protocols' control messages, and the use of timestamps in those protocols' control messages and the use of timestamps in those
messages to prevent replay attacks. Both use the TLV mechanism messages to prevent replay attacks. Both use the TLV mechanism
specified in [RFC5444] to add this information to the messages. specified in [RFC5444] to add this information to the messages.
These ICV and TIMESTAMP TLVs are defined in [RFC6622bis]. Different These ICV and TIMESTAMP TLVs are defined in [RFC7182]. Different ICV
ICV TLVs are used for HELLO messages in NHDP and TC (Topology TLVs are used for HELLO messages in NHDP and TC (Topology Control)
Control) messages in OLSRv2, the former also protecting the source messages in OLSRv2, the former also protecting the source address of
address of the IP datagram that contains the HELLO message. This is the IP datagram that contains the HELLO message. This is because the
because the IP datagram source address is used by NHDP to determine IP datagram source address is used by NHDP to determine the address
the address of a neighbor interface, and is not necessarily otherwise of a neighbor interface, and it is not necessarily otherwise
contained in the HELLO message, while OLSRv2's TC message is contained in the HELLO message, while OLSRv2's TC message is
forwarded in a new packet, and thus has no single IP datagram source forwarded in a new packet; thus, it has no single IP datagram source
address. address.
The mechanism specified in this document is placed in the packet/ The mechanism specified in this document is placed in the packet/
message processing flow as indicated in Figure 1. It exists between message processing flow as indicated in Figure 1. It exists between
the packet parsing/generation function of [RFC5444], and the message the packet parsing/generation function of [RFC5444] and the message
processing/generation function of NHDP and OLSRv2. processing/generation function of NHDP and OLSRv2.
| | | |
Incoming | /|\ Outgoing Incoming | /|\ Outgoing
packet \|/ | packet packet \|/ | packet
| | | |
+--------------------------------+ +--------------------------------+
| | | |
| RFC5444 packet | | RFC 5444 packet |
| parsing / generation | | parsing/generation |
| | | |
+--------------------------------+ +--------------------------------+
| | | |
Messages | /|\ Messages with Messages | /|\ Messages with
\|/ | added TLVs \|/ | added TLVs
| | | |
D +--------------------------------+ D +--------------------------------+
R /__________________ | Mechanism specified in | R /__________________ | |
O \ Messages | this document | O \ Messages | Mechanism specified in |
P (failed check) | | P (failed check) | this document |
| |
+--------------------------------+ +--------------------------------+
| | | |
Messages | /|\ Messages Messages | /|\ Messages
(passed check) \|/ | (passed check) \|/ |
| | | |
+--------------------------------+ +--------------------------------+
| | | |
| NHDP/OLSRv2 message | | NHDP/OLSRv2 message |
| processing / generation | | processing/generation |
| | | |
+--------------------------------+ +--------------------------------+
Figure 1: Relationship with RFC5444 and NHDP/OLSRv2 Figure 1: Relationship with RFC 5444 and NHDP/OLSRv2
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 "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
Additionally, this document uses the terminology and notation of Additionally, this document uses the terminology and notation of
[RFC5444], [RFC6130], [OLSRv2], and [RFC6622bis]. [RFC5444], [RFC6130], [RFC7181], and [RFC7182].
3. Applicability Statement 3. Applicability Statement
[RFC6130] and [OLSRv2] enable specifications of extensions to [RFC6130] and [RFC7181] enable specifications of extensions to
recognize additional reasons for rejecting a message as "badly formed recognize additional reasons for rejecting a message as "badly formed
and therefore invalid for processing", and mention security and therefore invalid for processing", and mention security
(integrity protection) as an explicit example. This document (integrity protection) as an explicit example. This document
specifies a mechanism that provides this functionality. specifies a mechanism that provides this functionality.
Implementations of [RFC6130] and [OLSRv2] MUST include this Implementations of [RFC6130] and [RFC7181] MUST include this
mechanism, and deployments of [RFC6130] and [OLSRv2] SHOULD use this mechanism, and deployments of [RFC6130] and [RFC7181] SHOULD use this
mechanism, except for when a different security mechanism is more mechanism, except when a different security mechanism is more
appropriate. appropriate.
The applicability of this mechanism is determined by its The applicability of this mechanism is determined by its
characteristics, which are that it: characteristics, which are that it:
o Specifies a security mechanism that is required to be included in o Specifies a security mechanism that is required to be included in
conforming implementations of [RFC6130] and [OLSRv2]. conforming implementations of [RFC6130] and [RFC7181].
o Specifies an association of ICVs with protocol messages, and o Specifies an association of ICVs with protocol messages, and
specifies how to use a missing or invalid ICV as an reason to specifies how to use a missing or invalid ICV as a reason to
reject a message as "badly formed and therefore invalid for reject a message as "badly formed and therefore invalid for
processing". processing".
o Specifies the implementation of an ICV Message TLV, defined in o Specifies the implementation of an ICV Message TLV, defined in
[RFC6622bis], using a SHA-256 based HMAC applied to the [RFC7182], using a SHA-256-based Hashed Message Authentication
appropriate message contents (and for HELLO messages also Code (HMAC) applied to the appropriate message contents (and for
including the IP datagram source address). Implementations of HELLO messages also including the IP datagram source address).
[RFC6130] and [OLSRv2] MUST support an HMAC-SHA-256 ICV TLV, and Implementations of [RFC6130] and [RFC7181] MUST support an
deployment SHOULD use it except when use of a different algorithm HMAC-SHA-256 ICV TLV, and deployments SHOULD use it except when
is more appropriate. An implementation MAY use more than one ICV use of a different algorithm is more appropriate. An
TLV in a message, as long as they each use a different algorithm implementation MAY use more than one ICV TLV in a message, as long
or key to calculate the ICV. as they each use a different algorithm or key to calculate the
ICV.
o Specifies the implementation of a TIMESTAMP Message TLV, defined o Specifies the implementation of a TIMESTAMP Message TLV, defined
in [RFC6622bis], to provide message replay protection. in [RFC7182], to provide message replay protection.
Implementations of [RFC6130] and [OLSRv2] using this mechanism Implementations of [RFC6130] and [RFC7181] using this mechanism
MUST support a POSIX time based timestamp, and deployments SHOULD MUST support a timestamp based on POSIX time, and deployments
use it if the clocks in all routers in the network can be SHOULD use it if the clocks in all routers in the network can be
synchronized with sufficient precision. synchronized with sufficient precision.
o Assumes that a router that is able to generate correct integrity o Assumes that a router that is able to generate correct integrity
check values is considered trusted. check values is considered trusted.
This mechanism does not: This mechanism does not:
o Specify which key identifiers are to be used in a MANET in which o Specify which key identifiers are to be used in a MANET in which
the routers share more than one secret key. (Such keys will be the routers share more than one secret key. (Such keys will be
differentiated using the <key-id> field defined in an ICV TLV in differentiated using the <key-id> field defined in an ICV TLV in
[RFC6622bis].) [RFC7182].)
o Specify how to distribute cryptographic material (shared secret o Specify how to distribute cryptographic material (shared secret
key(s)). key(s)).
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 (revoke) compromised routers with valid o Specify how to handle (revoke) compromised routers with valid
keys. keys.
4. Protocol Overview and Functioning 4. Protocol Overview and Functioning
The mechanism specified in this document provides the following The mechanism specified in this document provides the following
functionalities for use with messages specified by [RFC6130] and functionalities for use with messages specified by [RFC6130] and
[OLSRv2]: [RFC7181]:
o Generation of ICV Message TLVs (as defined in [RFC6622bis]) for o Generation of ICV Message TLVs (as defined in [RFC7182]) for
inclusion in an outgoing message. An implementation of [RFC6130] inclusion in an outgoing message. An implementation of [RFC6130]
and [OLSRv2] MAY use more than one ICV TLV in a message, even with and [RFC7181] MAY use more than one ICV TLV in a message, even
the same type extension, but these ICV TLVs MUST each use with the same type extension, but these ICV TLVs MUST each use
different keys, or they MUST use a different algorithm to different keys or they MUST use a different algorithm to calculate
calculate the ICV, e.g., with different hash and/or cryptographic the ICV, e.g., with different hash and/or cryptographic functions
functions when using type extension 1 or 2. An implementation of when using type extension 1 or 2. An implementation of [RFC6130]
[RFC6130] and [OLSRv2] MUST at least be able to generate an ICV and [RFC7181] MUST at least be able to generate an ICV TLV using
TLV using HMAC-SHA-256 and one or more secret keys shared by all HMAC-SHA-256 and one or more secret keys shared by all routers.
routers.
o Generation of TIMESTAMP Message TLVs (as defined in [RFC6622bis]) o Generation of TIMESTAMP Message TLVs (as defined in [RFC7182]) for
for inclusion in an outgoing message. An implementation of inclusion in an outgoing message. An implementation of [RFC6130]
[RFC6130] and [OLSRv2] MAY use more than one ICV TLV in a message, and [RFC7181] MAY use more than one ICV TLV in a message, but it
but MUST NOT use the same type extension. An implementation of MUST NOT use the same type extension. An implementation of
[RFC6130] and [OLSRv2] that is able to synchronize the clocks in [RFC6130] and [RFC7181] that is able to synchronize the clocks in
all routers in the network with sufficient precision, MUST at all routers in the network with sufficient precision MUST at least
least be able to generate a TIMESTAMP TLV using POSIX time. be able to generate a TIMESTAMP TLV using POSIX time.
o Verification of ICV Message TLVs contained in a message, in order o Verification of ICV Message TLVs contained in a message, in order
to determine if this message MUST be rejected as "badly formed and to determine if this message MUST be rejected as "badly formed and
therefore invalid for processing" [RFC6130] [OLSRv2]. An therefore invalid for processing" [RFC6130] [RFC7181]. An
implementation of [RFC6130] and [OLSRv2] MUST at least be able to implementation of [RFC6130] and [RFC7181] MUST at least be able to
verify an ICV TLV using HMAC/SHA-256 and one or more secret keys verify an ICV TLV using HMAC/SHA-256 and one or more secret keys
shared by all routers. shared by all routers.
o Verification of TIMESTAMP Message TLVs (as defined in o Verification of TIMESTAMP Message TLVs (as defined in [RFC7182])
[RFC6622bis]) contained in a message, in order to determine if contained in a message, in order to determine if this message MUST
this message MUST be rejected as "badly formed and therefore be rejected as "badly formed and therefore invalid for processing"
invalid for processing" [RFC6130] [OLSRv2]. An implementation of [RFC6130] [RFC7181]. An implementation of [RFC6130] and [RFC7181]
[RFC6130] and [OLSRv2] that is able to synchronize the clocks in that is able to synchronize the clocks in all routers in the
all routers in the network with sufficient precision, MUST at network with sufficient precision MUST at least be able to verify
least be able to verify a TIMESTAMP TLV using POSIX time. a TIMESTAMP TLV using POSIX time.
ICV Packet TLVs (as defined in [RFC6622bis]) MAY be used by a ICV Packet TLVs (as defined in [RFC7182]) MAY be used by a deployment
deployment of the multiplexing process defined in [RFC5444], either of the multiplexing process defined in [RFC5444], either as well as
as well as, or instead of, the protection of the NHDP and OLSRv2 or instead of the protection of the NHDP and OLSRv2 messages. (Note
messages. (Note that in the case of NHDP, the packet protection is that in the case of NHDP, the packet protection is equally good, and
equally good, and also protects the packet header. In the case of also protects the packet header. In the case of OLSRv2, the packet
OLSRv2, the packet protection has different properties than the protection has different properties than the message protection,
message protection, especially for some forms of ICV. When packets especially for some forms of ICV. When packets contain more than one
contain more than one message, the packet protection has lower message, the packet protection has lower overheads in space and
overheads in space and computation time.) computation time.)
When a router generates a message on a MANET interface, this When a router generates a message on a MANET interface, this
mechanism: mechanism:
o Specifies how to calculate an integrity check value for the o Specifies how to calculate an ICV for the message.
message.
o Specifies how to include that integrity check value using an ICV o Specifies how to include that ICV using an ICV Message TLV.
Message TLV.
[RFC6130] and [OLSRv2] allow for rejecting incoming messages prior to [RFC6130] and [RFC7181] allow for the rejection of incoming messages
processing by NHDP or OLSRv2. This mechanism, when used, specifies prior to processing by NHDP or OLSRv2. This mechanism, when used,
that a message MUST be rejected if the ICV Message TLV is absent, or specifies that a message MUST be rejected if the ICV Message TLV is
its value cannot be verified. Note that this means that routers absent, or its value cannot be verified. Note that this means that
whose implementation of NHDP and/or OLSRv2 does not include this routers whose implementation of NHDP and/or OLSRv2 does not include
specification will be ignored by routers using this mechanism, and this specification will be ignored by routers using this mechanism,
these two sets of routers will, by design, form disjoint MANETs. and these two sets of routers will, by design, form disjoint MANETs.
(The unsecured MANET will retain some information about the secured (The unsecured MANET will retain some information about the secured
MANET, but be unable to use it, not having any recognized symmetric MANET, but be unable to use it, not having any recognized symmetric
links with the secured MANET.) links with the secured MANET.)
5. Parameters 5. Parameters
This following router parameters are specified for use by the two The following router parameters are specified for use by the two
protocols; the first is required only by NHDP, but may be visible to protocols; the first is required only by NHDP, but may be visible to
OLSRv2, the second is required only by OLSRv2: OLSRv2, the second is required only by OLSRv2:
o MAX_HELLO_TIMESTAMP_DIFF - The maximum age that a HELLO message to o MAX_HELLO_TIMESTAMP_DIFF - The maximum age that a HELLO message to
be validated may have. If the current POSIX time of the router be validated may have. If the current POSIX time of the router
validating the HELLO message, minus the timestamp indicated in the validating the HELLO message, minus the timestamp indicated in the
TIMESTAMP TLV of the HELLO message, is greater than TIMESTAMP TLV of the HELLO message, is greater than
MAX_HELLO_TIMESTAMP_DIFF, the HELLO message MUST be silently MAX_HELLO_TIMESTAMP_DIFF, the HELLO message MUST be silently
discarded. discarded.
skipping to change at page 8, line 12 skipping to change at page 8, line 17
validating the TC message, minus the timestamp indicated in the validating the TC message, minus the timestamp indicated in the
TIMESTAMP TLV of the TC message, is greater than TIMESTAMP TLV of the TC message, is greater than
MAX_TC_TIMESTAMP_DIFF, the TC message MUST be silently discarded. MAX_TC_TIMESTAMP_DIFF, the TC message MUST be silently discarded.
The following constraints apply to these parameters: The following constraints apply to these parameters:
o MAX_HELLO_TIMESTAMP_DIFF > 0 o MAX_HELLO_TIMESTAMP_DIFF > 0
o MAX_TC_TIMESTAMP_DIFF > 0 o MAX_TC_TIMESTAMP_DIFF > 0
These bounds are however insufficient, MAX_HELLO_TIMESTAMP_DIFF and However, these bounds are insufficient: MAX_HELLO_TIMESTAMP_DIFF and
MAX_TC_TIMESTAMP_DIFF MUST be least as great as the maximum expected MAX_TC_TIMESTAMP_DIFF MUST be least as great as the maximum expected
"age" of a message (i.e., the time difference between a message has "age" of a message (i.e., the time difference between a message has
been sent by a router and received by all intended destinations). been sent by a router and received by all intended destinations).
For HELLO messages this needs only cover a single hop, but TC For HELLO messages, this needs only cover a single hop, but TC
messages may have been forwarded a number of times. In particular messages may have been forwarded a number of times. In particular,
for TC messages, if using jitter as specified in [OLSRv2] and for TC messages, if using jitter as specified in [RFC7181] and
[RFC5148], the largest contribution the age may be a delay of up to [RFC5148], the largest contribution the age may be a delay of up to
F_MAXJITTER per hop (except the final hop) that the message has F_MAXJITTER per hop (except the final hop) that the message has
traveled. Other factors in the delay of both message types, per hop, traveled. Other factors in the delay of both message types, per hop,
may include the link-layer that is used in the MANET, and CPU and may include the link-layer that is used in the MANET, and CPU and
memory resources of routers (e.g., queuing delays, and delays for memory resources of routers (e.g., queuing delays, and delays for
processing ICVs). An implementation MAY set lower and/or upper processing ICVs). An implementation MAY set lower and/or upper
bounds on these parameters, if so, then these MUST allow values bounds on these parameters, if so, then these MUST allow values
meeting these requirements. An implementation MAY make its value of meeting these requirements. An implementation MAY make its value of
MAX_TC_TIMESTAMP_DIFF dependent on the number of hops that a TC MAX_TC_TIMESTAMP_DIFF dependent on the number of hops that a TC
message has traveled. message has traveled.
skipping to change at page 8, line 45 skipping to change at page 8, line 50
MAX_HELLO_TIMESTAMP_DIFF, allowing for greater separation, but MAX_HELLO_TIMESTAMP_DIFF, allowing for greater separation, but
usually not per hop, for MAX_TC_TIMESTAMP_DIFF). usually not per hop, for MAX_TC_TIMESTAMP_DIFF).
Note that excessively large values of these parameters defeats their Note that excessively large values of these parameters defeats their
objectives, so these parameters SHOULD be as large as is required, objectives, so these parameters SHOULD be as large as is required,
but not significantly larger. but not significantly larger.
Using POSIX time allows a resolution of no more than one second. In Using POSIX time allows a resolution of no more than one second. In
many MANET use cases, time synchronization much below one second is many MANET use cases, time synchronization much below one second is
not possible because of unreliable and high-delay channels, mobility, not possible because of unreliable and high-delay channels, mobility,
interrupted communication, and possible limited resources. interrupted communication, and possible resource limitations.
In addition, when using the default message intervals and validity In addition, when using the default message intervals and validity
times as specified in [RFC6130] and [OLSRv2], where the shortest times as specified in [RFC6130] and [RFC7181], where the shortest
periodic message interval is 2 seconds, repeating the message within periodic message interval is 2 seconds, repeating the message within
a second is actually beneficial rather than harmful (at a small a second is actually beneficial rather than harmful (at a small
bandwidth cost). Also, the use of [RFC5148] jitter can cause a bandwidth cost). Also, the use of [RFC5148] jitter can cause a
message to take that long or more to traverse the MANET, thus even in message to take that long or longer to traverse the MANET, thus even
a perfectly synchronized network, the TC maximum delay would usually in a perfectly synchronized network, the TC maximum delay would
be greater than 1 second. usually be greater than 1 second.
A finer granulatity than 1 second, and thus the use of an alternative A finer granularity than 1 second, and thus the use of an alternative
timestamp, is however RECOMMENDED in cases where, possibly due to timestamp, is however RECOMMENDED in cases where, possibly due to
fast moving routers, message validity times are below 1 second. fast moving routers, message validity times are below 1 second.
6. Message Generation and Processing 6. Message Generation and Processing
This section specifies how messages are generated and processed by This section specifies how messages are generated and processed by
[RFC6130] and [OLSRv2] when using this mechanism. [RFC6130] and [RFC7181] when using this mechanism.
6.1. Message Content 6.1. Message Content
Messages MUST have the content specified in [RFC6130] and [OLSRv2] Messages MUST have the content specified in [RFC6130] and [RFC7181],
respectively. In addition, messages that conform to this mechanism respectively. In addition, messages that conform to this mechanism
MUST contain: MUST contain:
o At least one ICV Message TLV (as specified in [RFC6622bis]), o At least one ICV Message TLV (as specified in [RFC7182]),
generated according to Section 6.2. Implementations of [RFC6130] generated according to Section 6.2. Implementations of [RFC6130]
and [OLSRv2] MUST support the following version of the ICV TLV, and [RFC7181] MUST support the following version of the ICV TLV,
but other versions MAY be used instead, or in addition, in a but other versions MAY be used instead, or in addition, in a
deployment, if more appropriate: deployment, if more appropriate:
* For TC messages: * For TC messages:
+ type-extension := 1 + type-extension := 1
* For HELLO messages: * For HELLO messages:
+ type-extension := 2 + type-extension := 2
* hash-function := 3 (SHA-256) * hash-function := 3 (SHA-256)
* cryptographic-function := 3 (HMAC) * cryptographic-function := 3 (HMAC)
The ICV Value MAY be truncated as specified in [RFC6622bis]; the The ICV Value MAY be truncated as specified in [RFC7182]; the
selection of an appropriate length MAY be administratively selection of an appropriate length MAY be administratively
configured. A message MAY contain several ICV Message TLVs. configured. A message MAY contain several ICV Message TLVs.
o At least one TIMESTAMP Message TLV (as specified in [RFC6622bis]), o At least one TIMESTAMP Message TLV (as specified in [RFC7182]),
generated according to Section 6.2. Implementations of [RFC6130] generated according to Section 6.2. Implementations of [RFC6130]
and [OLSRv2] using this mechanism MUST support the following and [RFC7181] using this mechanism MUST support the following
version of the TIMESTAMP TLV, but other versions MAY be used version of the TIMESTAMP TLV, but other versions MAY be used
instead, or in addition, in a deployment, if more appropriate: instead, or in addition, in a deployment, if more appropriate:
* type-extension := 1 * type-extension := 1
6.2. Message Generation 6.2. Message Generation
After message generation (Section 11.1 of [RFC6130] and Section 16.1. After message generation (Section 11.1 of [RFC6130] and Section 16.1.
of [OLSRv2]) and before message transmission (Section 11.2 of of [RFC7181]) and before message transmission (Section 11.2 of
[RFC6130] and Section 16.2 of [OLSRv2]), the additional TLVs [RFC6130] and Section 16.2 of [RFC7181]), the additional TLVs
specified in Section 6.1 MUST (unless already present) be added to an specified in Section 6.1 MUST (unless already present) be added to an
outgoing message when using this mechanism. outgoing message when using this mechanism.
The following processing steps (when using a single timestamp version The following processing steps (when using a single timestamp version
and a single ICV algorithm) MUST be performed for a cryptographic and a single ICV algorithm) MUST be performed for a cryptographic
algorithm that is used for generating an ICV for a message: algorithm that is used for generating an ICV for a message:
1. All ICV TLVs (if any) are temporarily removed from the message. 1. All ICV TLVs (if any) are temporarily removed from the message.
Any temporarily removed ICV TLVs MUST be stored, in order to be Any temporarily removed ICV TLVs MUST be stored, in order to be
reinserted into the message in step 5. The message size and reinserted into the message in step 5. The message size and
Message TLV Block size are updated accordingly. Message TLV Block size are updated accordingly.
2. <msg-hop-count> and <msg-hop-limit>, if present, are temporarily 2. <msg-hop-count> and <msg-hop-limit>, if present, are temporarily
set to 0. set to 0.
3. A TLV of type TIMESTAMP, as specified in Section 6.1, is added to 3. A TLV of type TIMESTAMP, as specified in Section 6.1, is added to
the Message TLV Block. The message size and Message TLV block the Message TLV Block. The message size and Message TLV Block
size are updated accordingly. size are updated accordingly.
4. A TLV of type ICV, as specified in Section 6.1, is added to the 4. A TLV of type ICV, as specified in Section 6.1, is added to the
Message TLV Block. The message size and Message TLV block size Message TLV Block. The message size and Message TLV Block size
are updated accordingly. are updated accordingly.
5. All ICV TLVs that were temporary removed in step 1, are restored. 5. All ICV TLVs that were temporary removed in step 1, are restored.
The message size and Message TLV Block size are updated The message size and Message TLV Block size are updated
accordingly. accordingly.
6. <msg-hop-count> and <msg-hop-limit>, if present, are restored to 6. <msg-hop-count> and <msg-hop-limit>, if present, are restored to
their previous values. their previous values.
An implementation MAY add either alternative TIMESTAMP and/or ICV An implementation MAY add either alternative TIMESTAMP and/or ICV
TLVs, or more than one TIMESTAMP and/or ICV TLVs. All TIMESTAMP TLVs TLVs or more than one TIMESTAMP and/or ICV TLVs. All TIMESTAMP TLVs
MUST be inserted before adding ICV TLVs. MUST be inserted before adding ICV TLVs.
6.3. Message Processing 6.3. Message Processing
Both [RFC6130] and [OLSRv2] specify that: Both [RFC6130] and [RFC7181] specify that:
"On receiving a ... message, a router MUST first check if the On receiving a ... 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] and [OLSRv2] proceed to give a number of conditions that, [RFC6130] and [RFC7181] proceed to give a number of conditions that,
each, will lead to a rejection of the message as "badly formed and each, will lead to a rejection of the message as "badly formed and
therefore invalid for processing". When using a single timestamp therefore invalid for processing". When using a single timestamp
version, and a single ICV algorithm, the following conditions to that version, and a single ICV algorithm, add the following conditions to
list, each of which, if true, MUST cause NHDP or OLSRv2 (as that list, each of which, if true, MUST cause NHDP or OLSRv2 (as
appropriate) to consider the message as invalid for processing when appropriate) to consider the message as invalid for processing when
using this mechanism: using this mechanism:
1. The Message TLV Block of the message does not contain exactly one 1. The Message TLV Block of the message does not contain exactly one
TIMESTAMP TLV of the selected version. This version TIMESTAMP TLV of the selected version. This version
specification includes the type extension. (The Message TLV specification includes the type extension. (The Message TLV
Block may also contain TIMESTAMP TLVs of other versions.) Block may also contain TIMESTAMP TLVs of other versions.)
2. The Message TLV block does not contain exactly one ICV TLV using 2. The Message TLV Block does not contain exactly one ICV TLV using
the selected algorithm and key identifier. This algorithm the selected algorithm and key identifier. This algorithm
specification includes the type extension, and for type specification includes the type extension, and for type
extensions 1 and 2, the hash function and cryptographic function. extensions 1 and 2, the hash function and cryptographic function.
(The Message TLV Block may also contain ICV TLVs using other (The Message TLV Block may also contain ICV TLVs using other
algorithms and key identifiers.) algorithms and key identifiers.)
3. Validation of the identified (in step 1) TIMESTAMP TLV in the 3. Validation of the identified (in step 1) TIMESTAMP TLV in the
Message TLV block of the message fails, as according to Message TLV Block of the message fails, as according to
Section 6.3.1. Section 6.3.1.
4. Validation of the identified (in step 2) ICV TLV in the Message 4. Validation of the identified (in step 2) ICV TLV in the Message
TLV block of the message fails, as according to Section 6.3.2. TLV Block of the message fails, as according to Section 6.3.2.
An implementation MAY check the existence of, and verify, either An implementation MAY check the existence of, and verify, either an
alternative TIMESTAMP and/or ICV TLVs, or more than one TIMESTAMP alternative TIMESTAMP and/or ICV TLVs or more than one TIMESTAMP and/
and/or ICV TLVs. or ICV TLVs.
6.3.1. Validating a Message Based on Timestamp 6.3.1. Validating a Message Based on Timestamp
For a TIMESTAMP Message TLV with type extension 1 (POSIX time) For a TIMESTAMP Message TLV with type extension 1 (POSIX time)
identified as described in Section 6.2: identified as described in Section 6.2:
1. If the current POSIX time minus the value of that TIMESTAMP TLV 1. If the current POSIX time minus the value of that TIMESTAMP TLV
is greater than MAX_HELLO_TIMESTAMP_DIFF (for a HELLO message) or is greater than MAX_HELLO_TIMESTAMP_DIFF (for a HELLO message) or
MAX_TC_TIMESTAMP_DIFF (for a TC message) then the message MAX_TC_TIMESTAMP_DIFF (for a TC message), then the message
validation fails. validation fails.
2. Otherwise, the message validation succeeds. 2. Otherwise, the message validation succeeds.
If a deployment chooses to use a different type extension from 1, If a deployment chooses to use a different type extension from 1,
appropriate measures MUST be taken to verify freshness of the appropriate measures MUST be taken to verify freshness of the
message. message.
6.3.2. Validating a Message Based on Integrity Check 6.3.2. Validating a Message Based on Integrity Check
For an ICV Message TLV identified as described in Section 6.2: For an ICV Message TLV identified as described in Section 6.2:
1. All ICV Message TLVs (including the identified ICV Message TLV) 1. All ICV Message TLVs (including the identified ICV Message TLV)
are temporarily removed from the message, and the message size are temporarily removed from the message, and the message size
and Message TLV block size are updated accordingly. and Message TLV Block size are updated accordingly.
2. The message's <msg-hop-count> and <msg-hop-limit> fields are 2. The message's <msg-hop-count> and <msg-hop-limit> fields are
temporarily set to 0. temporarily set to 0.
3. Calculate the integrity check value for the parameters specified 3. Calculate the ICV for the parameters specified in the identified
in the identified ICV Message TLV, as specified in [RFC6622bis]. ICV Message TLV, as specified in [RFC7182].
4. If this integrity check value differs from the value of 4. If this ICV differs from the value of <ICV-data> in the ICV
<ICV-data> in the ICV Message TLV, then the message validation Message TLV, then the message validation fails. If the
fails. If the <ICV-data> has been truncated (as specified in <ICV-data> has been truncated (as specified in [RFC7182], the ICV
[RFC6622bis], the integrity check value calculated in the calculated in the previous step MUST be truncated to the TLV
previous step MUST be truncated to the TLV length of the ICV length of the ICV Message TLV before comparing it with the
Message TLV before comparing it with the <ICV-data>. <ICV-data>.
5. Otherwise, the message validation succeeds. The message's 5. Otherwise, the message validation succeeds. The message's
<msg-hop-count> and <msg-hop-limit> fields are restored to their <msg-hop-count> and <msg-hop-limit> fields are restored to their
previous value, and the ICV Message TLVs are returned to the previous value, and the ICV Message TLVs are returned to the
message, whose size is updated accordingly. message, whose size is updated accordingly.
7. Provisioning of Routers 7. Provisioning of Routers
Before a router using this mechanism is able to generate ICVs or Before a router using this mechanism is able to generate ICVs or
validate messages, it MUST acquire the shared secret key(s) to be validate messages, it MUST acquire the shared secret key(s) to be
used by all routers that are to participate in the network. This used by all routers that are to participate in the network. This
specification does not define how a router acquires secret keys. specification does not define how a router acquires secret keys.
Once a router has acquired suitable key(s) it MAY be configured to Once a router has acquired suitable key(s), it MAY be configured to
use, or not use, this mechanism. Section 23.6 of [OLSRv2] provides a use, or not use, this mechanism. Section 23.6 of [RFC7181] provides
rationale based on [BCP107] why no key management is specified for a rationale based on [BCP107] why no key management is specified for
OLSRv2. OLSRv2.
8. IANA Considerations 8. Security Considerations
This document has no actions for IANA.
[This section may be removed by the RFC Editor.]
9. Security Considerations
This document specifies a security mechanism for use with NHDP and This document specifies a security mechanism for use with NHDP and
OLSRv2 that allows for mitigating several security threats. OLSRv2 that allows for mitigating several security threats.
9.1. Mitigated Attacks 8.1. Mitigated Attacks
This section briefly summarizes security threats that are mitigated This section briefly summarizes security threats that are mitigated
by the mechanism presented in this document. by the mechanism presented in this document.
9.1.1. Identity Spoofing 8.1.1. Identity Spoofing
As only routers possessing the selected shared secret key are able to As only routers possessing the selected shared secret key are able to
add a valid ICV TLV to a message, identity spoofing, where an add a valid ICV TLV to a message, identity spoofing, where an
attacker falsely claims an identity of a valid router, is countered. attacker falsely claims an identity of a valid router, is countered.
When using one or more shared keys for all routers in the MANET, it When using one or more shared keys for all routers in the MANET, it
is only possible to determine that it is a valid router in the is only possible to determine that it is a valid router in the
network, not to discern particular routers. Therefore, a malicious network, not to discern particular routers. Therefore, a malicious
router in possession of valid keys (e.g., a compromised router) may router in possession of valid keys (e.g., a compromised router) may
still spoof the identity of another router using the same key. still spoof the identity of another router using the same key.
9.1.2. Link Spoofing 8.1.2. Link Spoofing
Link spoofing, where an attacker falsely represents the existence of Link spoofing, where an attacker falsely represents the existence of
a non-existent link, or otherwise misrepresents a link's state, is a nonexistent link, or otherwise misrepresents a link's state, is
countered by the mechanism specified in this document, using the same countered by the mechanism specified in this document, using the same
argument as in Section 9.1.1. argument as in Section 8.1.1.
9.1.3. Replay Attack 8.1.3. Replay Attack
Replay attacks are partly countered by the mechanism specified in Replay attacks are partly countered by the mechanism specified in
this document, but this depends on synchronized clocks of all routers this document, but this depends on synchronized clocks of all routers
in the MANET. An attacker that records messages to replay them later in the MANET. An attacker that records messages to replay them later
can only do so in the selected time interval after the timestamp that can only do so in the selected time interval after the timestamp that
is contained in message. As an attacker cannot modify the content of is contained in message. As an attacker cannot modify the content of
this timestamp (as it is protected by the identity check value), an this timestamp (as it is protected by the identity check value), an
attacker cannot replay messages after this time. Within this time attacker cannot replay messages after this time. Within this time
interval it is still possible to perform replay attacks, however the interval, it is still possible to perform replay attacks; however,
limits on the time interval are specified so that this will have a the limits on the time interval are specified so that this will have
limited effect on the operation of the protocol. a limited effect on the operation of the protocol.
9.2. Limitations 8.2. Limitations
If no synchronized clocks are available in the MANET, replay attacks If no synchronized clocks are available in the MANET, replay attacks
cannot be countered by the mechanism provided by this document. An cannot be countered by the mechanism provided by this document. An
alternative version of the TIMESTAMP TLV defined in [RFC6622bis], alternative version of the TIMESTAMP TLV defined in [RFC7182], with a
with a monotonic sequence number, may have some partial value in this monotonic sequence number, may have some partial value in this case,
case, but will necessitate adding state to record observed message but will necessitate adding state to record observed message sequence
sequence number information. number information.
The mechanism provided by this document does not avoid or detect The mechanism provided by this document does not avoid or detect
security attacks by routers possessing the shared secret key that is security attacks by routers possessing the shared secret key that is
used to generate integrity check values for messages. used to generate integrity check values for messages.
This mechanism relies on an out-of-band protocol or mechanism for This mechanism relies on an out-of-band protocol or mechanism for
distributing the shared secret key(s) (and if an alternative distributing the shared secret key(s) (and if an alternative
integrity check value is used, any additional cryptographic integrity check value is used, any additional cryptographic
parameters). parameters).
This mechanism does not provide a key management mechanism. Refer to This mechanism does not provide a key management mechanism. Refer to
[OLSRv2], Section 23.6, for a detailed discussion why the automated Section 23.6 of [RFC7181] for a detailed discussion why the automated
key management requirements specified in [BCP107] do not apply for key management requirements specified in [BCP107] do not apply for
OLSRv2 and NHDP. OLSRv2 and NHDP.
10. Acknowledgments 9. Acknowledgments
The authors would like to gratefully acknowledge the following The authors would like to gratefully acknowledge the following
people: Justin Dean (NRL), and Henning Rogge (Frauenhofer FKIE). people: Justin Dean (NRL) and Henning Rogge (Frauenhofer FKIE).
11. References
11.1. Normative References 10. References
[OLSRv2] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, 10.1. Normative References
"The Optimized Link State Routing Protocol version 2",
work in progress draft-ietf-manet-olsrv2-19, March 2013.
[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 Mobile Ad Hoc Network (MANET) Packet/Message
February 2009. Format", RFC 5444, February 2009.
[RFC6130] Clausen, T., Dean, J., and C. Dearlove, "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.
[RFC6622bis] [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
Herberg, U., Clausen, T., and C. Dearlove, "Integrity "The Optimized Link State Routing Protocol Version 2", RFC
7181, April 2014.
[RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity
Check Value and Timestamp TLV Definitions for Mobile Ad Check Value and Timestamp TLV Definitions for Mobile Ad
Hoc Networks (MANETs)", work in Hoc Networks (MANETs)", RFC 7182, April 2014.
progress draft-ietf-manet-rfc6622-bis-02, April 2013.
11.2. Informative References 10.2. Informative References
[BCP107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic [BCP107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
Key Management", BCP 107, RFC 4107, June 2005. Key Management", BCP 107, RFC 4107, June 2005.
[RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter [RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter
Considerations in Mobile Ad Hoc Networks (MANETs)", Considerations in Mobile Ad Hoc Networks (MANETs)", RFC
RFC 5148, February 2008. 5148, February 2008.
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
URI: http://www.herberg.name/ URI: http://www.herberg.name/
Christopher Dearlove Christopher Dearlove
BAE Systems Advanced Technology Centre BAE Systems Advanced Technology Centre
West Hanningfield Road West Hanningfield Road
Great Baddow, Chelmsford Great Baddow, Chelmsford
United Kingdom United Kingdom
Phone: +44 1245 242194 Phone: +44 1245 242194
Email: chris.dearlove@baesystems.com EMail: chris.dearlove@baesystems.com
URI: http://www.baesystems.com/ URI: http://www.baesystems.com/
Thomas Heide Clausen Thomas Heide Clausen
LIX, Ecole Polytechnique LIX, Ecole Polytechnique
91128 Palaiseau Cedex, 91128 Palaiseau Cedex
France France
Phone: +33 6 6058 9349 Phone: +33 6 6058 9349
Email: T.Clausen@computer.org EMail: T.Clausen@computer.org
URI: http://www.thomasclausen.org/ URI: http://www.thomasclausen.org/
 End of changes. 96 change blocks. 
236 lines changed or deleted 219 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/