draft-ietf-manet-nhdp-olsrv2-sec-03.txt   draft-ietf-manet-nhdp-olsrv2-sec-04.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
Updates: 6130, xxxx (if approved) C. Dearlove Updates: 6130, xxxx (if approved) C. Dearlove
Intended status: Standards Track BAE Systems ATC Intended status: Standards Track BAE Systems ATC
Expires: January 3, 2014 T. Clausen Expires: February 15, 2014 T. Clausen
LIX, Ecole Polytechnique LIX, Ecole Polytechnique
July 2, 2013 August 14, 2013
Integrity Protection for Control Messages in NHDP and OLSRv2 Integrity Protection for Control Messages in NHDP and OLSRv2
draft-ietf-manet-nhdp-olsrv2-sec-03 draft-ietf-manet-nhdp-olsrv2-sec-04
Abstract Abstract
This document specifies integrity and replay protection for the MANET This document specifies integrity and replay protection for the MANET
Neighborhood Discovery Protocol (NHDP) and the Optimized Link State Neighborhood Discovery Protocol (NHDP) and the Optimized Link State
Routing Protocol version 2 (OLSRv2). This protection is achieved by Routing Protocol version 2 (OLSRv2). This protection is achieved by
using an HMAC-SHA-256 Integrity Check Value (ICV) TLV and a timestamp using an HMAC-SHA-256 Integrity Check Value (ICV) TLV and a timestamp
TLV based on POSIX time. TLV based on POSIX time.
The mechanism in this specification can also be used for other The mechanism in this specification can also be used for other
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 January 3, 2014. This Internet-Draft will expire on February 15, 2014.
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 23 skipping to change at page 2, line 23
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 . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . 8 6. Message Generation and Processing . . . . . . . . . . . . . . 9
6.1. Message Content . . . . . . . . . . . . . . . . . . . . . 8 6.1. Message Content . . . . . . . . . . . . . . . . . . . . . 9
6.2. Message Generation . . . . . . . . . . . . . . . . . . . . 9 6.2. Message Generation . . . . . . . . . . . . . . . . . . . . 10
6.3. Message Processing . . . . . . . . . . . . . . . . . . . . 10 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 . . . . 11 6.3.2. Validating a Message Based on Integrity Check . . . . 12
7. Provisioning of Routers . . . . . . . . . . . . . . . . . . . 12 7. Provisioning of Routers . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9.1. Alleviated Attacks . . . . . . . . . . . . . . . . . . . . 12 9.1. Alleviated Attacks . . . . . . . . . . . . . . . . . . . . 13
9.1.1. Identity Spoofing . . . . . . . . . . . . . . . . . . 12 9.1.1. Identity Spoofing . . . . . . . . . . . . . . . . . . 13
9.1.2. Link Spoofing . . . . . . . . . . . . . . . . . . . . 12 9.1.2. Link Spoofing . . . . . . . . . . . . . . . . . . . . 13
9.1.3. Replay Attack . . . . . . . . . . . . . . . . . . . . 12 9.1.3. Replay Attack . . . . . . . . . . . . . . . . . . . . 13
9.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 13 9.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . . 14 11.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
[RFC Editor note: Please replace "xxxx" throughout this document with [RFC Editor note: Please replace "xxxx" throughout this document with
the RFC number assigned to [OLSRv2], and remove this note.] the RFC number assigned to [OLSRv2], and remove this note.]
This specification updates [RFC6130] and [OLSRv2] by defining a This specification updates [RFC6130] and [OLSRv2] by defining a
framework of security mechanisms (for integrity and replay framework of security mechanisms (for integrity and replay
protection) that must be included in conforming implementations of protection) that must be included in conforming implementations of
those protocols (the Neighborhood Discovery Protocol, NHDP, and the those protocols (the Neighborhood Discovery Protocol, NHDP, and the
skipping to change at page 3, line 27 skipping to change at page 3, line 27
rather than messages, it may choose to use an alternative integrity rather than messages, it may choose to use an alternative integrity
check value (ICV) with preferred properties, and/or it may use an check value (ICV) with preferred properties, and/or it may use an
alternative timestamp. A deployment may choose to use no such alternative timestamp. A deployment may choose to use no such
security mechanisms, but this is not recommended. 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 [RFC6622bis]. Different
ICV TLVs are used for HELLO messages in NHDP and TC messages in ICV TLVs are used for HELLO messages in NHDP and TC (Topology
OLSRv2, the former also protecting the source address of the IP Control) messages in OLSRv2, the former also protecting the source
datagram that contains the HELLO message. This is because the IP address of the IP datagram that contains the HELLO message. This is
datagram source address is used by NHDP to determine the address of a because the IP datagram source address is used by NHDP to determine
neighbor interface, and is not necessarily otherwise contained in the the address of a neighbor interface, and is not necessarily otherwise
HELLO message, while OLSRv2's TC message is forwarded in a new contained in the HELLO message, while OLSRv2's TC message is
packet, and thus has no single IP datagram source address. forwarded in a new packet, and thus has no single IP datagram source
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
| | | |
skipping to change at page 4, line 20 skipping to change at page 4, line 20
| | | |
| RFC5444 packet | | RFC5444 packet |
| parsing / generation | | parsing / generation |
| | | |
+--------------------------------+ +--------------------------------+
| | | |
Messages | /|\ Messages with Messages | /|\ Messages with
\|/ | added TLVs \|/ | added TLVs
| | | |
D +--------------------------------+ D +--------------------------------+
R /__________________ | | R /__________________ | Mechanism specified in |
O \ Messages | This specification | O \ Messages | this document |
P (failed check) | | P (failed check) | |
+--------------------------------+ +--------------------------------+
| | | |
Messages | /|\ Messages Messages | /|\ Messages
(passed check) \|/ | (passed check) \|/ |
| | | |
+--------------------------------+ +--------------------------------+
| | | |
| NHDP/OLSRv2 message | | NHDP/OLSRv2 message |
| processing / generation | | processing / generation |
skipping to change at page 4, line 49 skipping to change at page 4, line 49
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], [OLSRv2], and [RFC6622bis].
3. Applicability Statement 3. Applicability Statement
[RFC6130] and [OLSRv2] enable extensions to recognize additional [RFC6130] and [OLSRv2] enable specifications of extensions to
reasons for rejecting a message as "badly formed and therefore recognize additional reasons for rejecting a message as "badly formed
invalid for processing", and mention security (integrity protection) and therefore invalid for processing", and mention security
as an explicit example. This document specifies a framework that (integrity protection) as an explicit example. This document
provides this functionality. specifies a framework that provides this functionality.
Implementations of [RFC6130] and [OLSRv2] MUST include this Implementations of [RFC6130] and [OLSRv2] MUST include this
framework, and deployments of [RFC6130] and [OLSRv2] SHOULD use this framework, and deployments of [RFC6130] and [OLSRv2] SHOULD use this
framework, except for when a different security mechanism is more framework, except for when a different security mechanism is more
appropriate. appropriate.
The applicability of this framework is determined by its The applicability of this framework is determined by its
characteristics, which are that it: characteristics, which are that it:
o Specifies a security framework that is required to be included in o Specifies a security framework that is required to be included in
skipping to change at page 5, line 29 skipping to change at page 5, line 29
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 an 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 [RFC6622bis], using a SHA-256 based HMAC applied to the
appropriate message contents (and for HELLO messages also appropriate message contents (and for HELLO messages also
including the IP datagram source address). Deployments of including the IP datagram source address). Deployments of
[RFC6130] and [OLSRv2] using this framework SHOULD use an HMAC/ [RFC6130] and [OLSRv2] using this framework SHOULD use an HMAC/
SHA-256 ICV TLV, but MAY use different algorithms if more SHA-256 ICV TLV, except when use of a different algorithm is more
appropriate in a deployment. An implementation MAY also use more appropriate in a deployment. An implementation MAY use more than
than one ICV TLV in a message, as long as they each use a one ICV TLV in a message, as long as they each use a different
different algorithm to calculate the ICV. algorithm 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 [RFC6622bis], to provide message replay protection.
Deployments of [RFC6130] and [OLSRv2] using this framework SHOULD Deployments of [RFC6130] and [OLSRv2] using this framework SHOULD
use a POSIX time based timestamp, if the clocks in all routers in use a POSIX time based timestamp, if the clocks in all routers in
the network can be synchronized with sufficient precision. the network can be 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.
skipping to change at page 6, line 13 skipping to change at page 6, line 13
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 framework specified in this document provides the following The framework specified in this document provides the following
functionalities for use with messages owned by [RFC6130] and functionalities for use with messages specified by [RFC6130] and
[OLSRv2]: [OLSRv2]:
o Generation of ICV Message TLVs (as defined in [RFC6622bis]) for o Generation of ICV Message TLVs (as defined in [RFC6622bis]) 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 [OLSRv2] MAY use more than one ICV TLV in a message, even with
the same type extension, but these ICV TLVs MUST each use a the same type extension, but these ICV TLVs MUST each use a
different algorithm to calculate the ICV, e.g., with different different algorithm to calculate the ICV, e.g., with different
hash and/or cryptographic functions when using type extension 1 or hash and/or cryptographic functions when using type extension 1 or
2. An implementation of [RFC6130] and [OLSRv2] MUST at least be 2. An implementation of [RFC6130] and [OLSRv2] MUST at least be
able to generate an ICV TLV using HMAC/SHA-256 and one or more able to generate an ICV TLV using HMAC/SHA-256 and one or more
secret keys shared by all routers. secret keys shared by all routers.
o Generation of TIMESTAMP Message TLVs (as defined in [RFC6622bis]) o Generation of TIMESTAMP Message TLVs (as defined in [RFC6622bis])
for inclusion in an outgoing message. An implementation of for inclusion in an outgoing message. An implementation of
[RFC6130] and [OLSRv2] MAY use more than one ICV TLV in a message, [RFC6130] and [OLSRv2] MAY use more than one ICV TLV in a message,
but not with the same type extension. An implementation of but MUST NOT use the same type extension. An implementation of
[RFC6130] and [OLSRv2] that is able to synchronize the clocks in [RFC6130] and [OLSRv2] 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 be able to generate a TIMESTAMP TLV using POSIX time. least 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] [OLSRv2]. An
implementation of [RFC6130] and [OLSRv2] MUST at least be able to implementation of [RFC6130] and [OLSRv2] 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.
skipping to change at page 8, line 39 skipping to change at page 8, line 39
MAX_HELLO_TIMESTAMP_DIFF and MAX_TC_TIMESTAMP_DIFF (and any MAX_HELLO_TIMESTAMP_DIFF and MAX_TC_TIMESTAMP_DIFF (and any
constraints on them) MAY be increased to allow for expected timing constraints on them) MAY be increased to allow for expected timing
differences between routers (between neighboring routers for differences between routers (between neighboring routers for
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
many MANET use cases, time synchronization much below one second is
not possible because of unreliable and high-delay channels, mobility,
interrupted communication, and possible limited resources.
In addition, when using the default message intervals and validity
times as specified in [RFC6130] and [OLSRv2], where the shortest
periodic message interval is 2 seconds, repeating the message within
a second is actually beneficial rather than harmful (at a small
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
a perfectly synchronized network, the TC maximum delay would usually
be greater than 1 second.
A finer granulatity than 1 second, and thus the use of an alternative
timestamp, is however RECOMMENDED in cases where, possibly due to
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 framework. [RFC6130] and [OLSRv2] when using this framework.
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 [OLSRv2]
respectively. In addition, in order to conform to this framework, respectively. In addition, messages that conform to this framework
each message MUST contain: will contain:
o At least one ICV Message TLV (as specified in [RFC6622bis]), o At least one ICV Message TLV (as specified in [RFC6622bis]),
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 [OLSRv2] 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
skipping to change at page 12, line 14 skipping to change at page 12, line 38
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 framework is able to generate ICVs or Before a router using this framework 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 framework. use, or not use, this framework. Section 23.6 of [OLSRv2] provides a
rationale based on [BCP107] why no key management is specified for
OLSRv2.
8. IANA Considerations 8. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
[This section may be removed by the RFC Editor.] [This section may be removed by the RFC Editor.]
9. Security Considerations 9. Security Considerations
This document specifies a security framework for use with NHDP and This document specifies a security framework for use with NHDP and
skipping to change at page 14, line 19 skipping to change at page 14, line 44
RFC 6130, April 2011. RFC 6130, April 2011.
[RFC6622bis] [RFC6622bis]
Herberg, U., Clausen, T., and C. Dearlove, "Integrity 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)", work in
progress draft-ietf-manet-rfc6622-bis-02, April 2013. progress draft-ietf-manet-rfc6622-bis-02, April 2013.
11.2. Informative References 11.2. Informative References
[BCP107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
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 5148, February 2008. RFC 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,
 End of changes. 19 change blocks. 
40 lines changed or deleted 64 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/