draft-ietf-manet-nhdp-olsrv2-sec-01.txt   draft-ietf-manet-nhdp-olsrv2-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
Updates: RFC6130 (if approved) C. Dearlove Updates: RFC6130 C. Dearlove
Intended status: Standards Track BAE Systems ATC (if approved) BAE Systems ATC
Expires: September 24, 2013 T. Clausen Intended status: Standards Track T. Clausen
LIX, Ecole Polytechnique Expires: October 17, 2013 LIX, Ecole Polytechnique
March 23, 2013 April 15, 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-01 draft-ietf-manet-nhdp-olsrv2-sec-02
Abstract Abstract
This document specifies integrity and replay protection for required This document specifies integrity and replay protection for required
implementation in the MANET Neighborhood Discovery Protocol (NHDP) implementation in the MANET Neighborhood Discovery Protocol (NHDP)
and the Optimized Link State Routing Protocol version 2 (OLSRv2). and the Optimized Link State Routing Protocol version 2 (OLSRv2).
This document specifies how an included integrity check value (ICV) This document specifies how an included integrity check value (ICV)
and a timestamp TLV, defined in RFC6622bis, are used by NHDP and and a timestamp TLV, defined in RFC6622bis, are used by NHDP and
OLSRv2 for countering a number of security threats. The ICV TLV uses OLSRv2 for countering a number of security threats. The ICV TLV uses
a SHA-256 based HMAC and one or more shared secret keys. The a SHA-256 based HMAC and one or more shared secret keys. The
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 24, 2013. This Internet-Draft will expire on October 17, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
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 . . . . . . . . . . . . . . 8
6.1. Message Content . . . . . . . . . . . . . . . . . . . . . 8 6.1. Message Content . . . . . . . . . . . . . . . . . . . . . 8
6.2. Message Generation . . . . . . . . . . . . . . . . . . . . 9 6.2. Message Generation . . . . . . . . . . . . . . . . . . . . 9
6.3. Message Processing . . . . . . . . . . . . . . . . . . . . 9 6.3. Message Processing . . . . . . . . . . . . . . . . . . . . 10
6.3.1. Invalidating a Message Based on Timestamp . . . . . . 10 6.3.1. Validating a Message Based on Timestamp . . . . . . . 10
6.3.2. Invalidating a Message Based on Integrity Check . . . 10 6.3.2. Validating a Message Based on Integrity Check . . . . 11
7. Provisioning of Routers . . . . . . . . . . . . . . . . . . . 11 7. Provisioning of Routers . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9.1. Alleviated Attacks . . . . . . . . . . . . . . . . . . . . 11 9.1. Alleviated Attacks . . . . . . . . . . . . . . . . . . . . 12
9.1.1. Identity Spoofing . . . . . . . . . . . . . . . . . . 11 9.1.1. Identity Spoofing . . . . . . . . . . . . . . . . . . 12
9.1.2. Link Spoofing . . . . . . . . . . . . . . . . . . . . 11 9.1.2. Link Spoofing . . . . . . . . . . . . . . . . . . . . 12
9.1.3. Replay Attack . . . . . . . . . . . . . . . . . . . . 12 9.1.3. Replay Attack . . . . . . . . . . . . . . . . . . . . 12
9.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 12 9.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 12
10. Normative References . . . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
11. Normative References . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
This specification defines a framework of security mechanisms that This specification defines a framework of security mechanisms that
must be included in conforming implementations of the Neighborhood must be included in conforming implementations of the Neighborhood
Discovery Protocol (NHDP) [RFC6130] and the Optimized Link State Discovery Protocol (NHDP) [RFC6130] and the Optimized Link State
Routing Protocol version 2 (OLSRv2) [OLSRv2] for Mobile Ad hoc Routing Protocol version 2 (OLSRv2) [OLSRv2] for Mobile Ad hoc
NETworks (MANETs). A deployment of these protocols may choose to NETworks (MANETs). A deployment of these protocols may choose to
employ alternative(s) to these mechanisms, in particular it may employ alternative(s) to these mechanisms, in particular it may
choose to protect packets rather than messages, it may choose to use choose to protect packets rather than messages, it may choose to use
an alternative integrity check value (ICV) with preferred properties, an alternative integrity check value (ICV) with preferred properties,
or it may use an alternative timestamp. A deployment may choose to and/or it may use an alternative timestamp. A deployment may choose
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 [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 messages in
OLSRv2, the former also protecting the source address of the IP OLSRv2, the former also protecting the source address of the IP
datagram that contains the HELLO message, because the IP datagram datagram that contains the HELLO message. This is because the IP
source address is used by NHDP to determine the address of a neighbor datagram source address is used by NHDP to determine the address of a
interface, and is not necessarily otherwise contained in the HELLO neighbor interface, and is not necessarily otherwise contained in the
message. HELLO message, while OLSRv2's TC message is forwarded in a new
packet, and thus has no single IP datagram source address.
The mechanism specified in this document exists between NHDP's and The mechanism specified in this document exists between NHDP's and
OLSRv2's message processing/generation and the [RFC5444] packet OLSRv2's message processing/generation and the [RFC5444] packet
parsing/generation, as illustrated in Figure 1. parsing/generation, as illustrated in Figure 1.
| | | |
Incoming | /|\ Outgoing Incoming | /|\ Outgoing
packet \|/ | packet packet \|/ | packet
| | | |
+--------------------------------+ +--------------------------------+
skipping to change at page 5, line 23 skipping to change at page 5, line 23
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
conforming implementations of [RFC6130] and [OLSRv2]. conforming implementations of [RFC6130] and [OLSRv2].
o Specifies an association of ICVs with messages, and for using o Specifies an association of ICVs with messages, and for using
missing or invalid ICVs as such an additional reason for rejecting missing or invalid ICVs as such an additional reason for rejecting
a message as "badly formed and therefore invalid for processing". a message as "badly formed and therefore invalid for processing".
o Specifies the implementation of an ICV 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 the 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, but may use different algorithms if more
appropriate in a deployment. An implementation may also use more appropriate in a deployment. An implementation may also use more
than one ICV TLV in a message as long as they each use a different than one ICV TLV in a message, as long as they each use a
algorithm to calculate the ICV. different algorithm to calculate the ICV.
o Specifies the implementation of a TIMESTAMP TLV, defined in o Specifies the implementation of a TIMESTAMP TLV, defined in
[RFC6622bis], to provide message replay protection. Deployments [RFC6622bis], to provide message replay protection. Deployments
of [RFC6130] and [OLSRv2] using this framework SHOULD use a POSIX of [RFC6130] and [OLSRv2] using this framework SHOULD use a POSIX
time based timestamp, if the clocks in all routers in the network time based timestamp, if the clocks in all routers in the network
can be synchronized with sufficient precision. 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.
This framework does not: This framework 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 wil 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].) [RFC6622bis].)
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 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 owned by [RFC6130] and
[OLSRv2]: [OLSRv2]:
o Generation of ICV TLVs (as defined in [RFC6622bis]) for inclusion o Generation of ICV Message TLVs (as defined in [RFC6622bis]) for
in an outgoing message. An implementation of [RFC6130] 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 different
algorithm to calculate the ICV, e.g., with different hash and/or
cryptographic functions when using type extension 1 or 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 secret keys
shared by all routers.
o Generation of TIMESTAMP 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], that is able to synchronize the clocks in all and [OLSRv2] MAY use more than one ICV TLV in a message, even with
routers in the network with sufficient precision, must at least be the same type extension, but these ICV TLVs MUST each use a
able to generate a TIMESTAMP TLV using POSIX time. different algorithm to calculate the ICV, e.g., with different
hash and/or cryptographic functions when using type extension 1 or
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
secret keys shared by all routers.
o Verification of ICV TLVs contained in a message, in order to o Generation of TIMESTAMP Message TLVs (as defined in [RFC6622bis])
determine if this message MUST be rejected as "badly formed and for inclusion in an outgoing message. An implementation of
[RFC6130] and [OLSRv2] MAY use more than one ICV TLV in a message,
but not with the same type extension. An implementation of
[RFC6130] and [OLSRv2] that is able to synchronize the clocks in
all routers in the network with sufficient precision, MUST at
least be able to generate a TIMESTAMP TLV using POSIX time.
o Verification of ICV Message TLVs contained in a message, in order
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.
o Verification of a TIMESTAMP TLV (as defined in [RFC6622bis]) o Verification of TIMESTAMP Message TLVs (as defined in
contained in a message, in order to determine if this message MUST [RFC6622bis]) contained in a message, in order to determine if
be rejected as "badly formed and therefore invalid for processing" this message MUST be rejected as "badly formed and therefore
[RFC6130] [OLSRv2]. An implementation of [RFC6130] and [OLSRv2] invalid for processing" [RFC6130] [OLSRv2]. An implementation of
that is able to synchronize the clocks in all routers in the [RFC6130] and [OLSRv2] that is able to synchronize the clocks in
network with sufficient precision, must at least be able to verify all routers in the network with sufficient precision, MUST at
a TIMESTAMP TLV using POSIX time. least be able to verify a TIMESTAMP TLV using POSIX time.
ICV Packet TLVs (as defined in [RFC6622bis]) may be used by a ICV Packet TLVs (as defined in [RFC6622bis]) MAY be used by a
deployment of the multiplexing process defined in [RFC5444], either deployment of the multiplexing process defined in [RFC5444], either
as well as, or instead of, the protection of the NHDP and OLSRv2 as well as, or instead of, the protection of the NHDP and OLSRv2
messages. (Note that in the case of NHDP, the packet protection is messages. (Note that in the case of NHDP, the packet protection is
equally good, and also protects the packet header. In the case of equally good, and also protects the packet header. In the case of
OLSRv2, the packet protection has different properties than the OLSRv2, the packet protection has different properties than the
message protection, especially for some forms of ICV. When packets message protection, especially for some forms of ICV. When packets
contain more than one message, the packet protection has lower contain more than one message, the packet protection has lower
overheads in space and computation time.) overheads in space and computation time.)
When a router generates a message on a MANET interface, this When a router generates a message on a MANET interface, this
framework: framework:
o Specifies how to calculate an integrity check value for the o Specifies how to calculate an integrity check value for the
message. message.
o Specifies how to include that integrity check value using an ICV o Specifies how to include that integrity check value using an ICV
Message TLV. Message TLV.
[RFC6130] and [OLSRv2] allow for rejecting incoming messages prior to [RFC6130] and [OLSRv2] allow for rejecting incoming messages prior to
processing by NHDP or OLSRv2. This framework specifies that a processing by NHDP or OLSRv2. This framework specifies that a
message must be rejected if the ICV Message TLV is absent, or its message MUST be rejected if the ICV Message TLV is absent, or its
value cannot be verified. value cannot be verified.
5. Parameters 5. Parameters
This following router parameters is specified for use by the two This 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 43 skipping to change at page 8, line 45
+ 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)
A message MAY contain several ICV Message TLVs. The ICV Value MAY be truncated as specified in [RFC6622bis]; the
selection of an appropriate length MAY be administratively
configured. A message MAY contain several ICV Message TLVs.
o At least one TIMESTAMP Message TLV (as specified in o At least one TIMESTAMP Message TLV (as specified in [RFC6622bis]),
[RFC6622bis])"/>), generated according to Section 6.2. generated according to Section 6.2. Implementations of [RFC6130]
Implementations of [RFC6130] and [OLSRv2] using this framework and [OLSRv2] using this framework MUST support the following
MUST support the following version of the TIMESTAMP TLV, but other version of the TIMESTAMP TLV, but other versions MAY be used
versions MAY be used instead, or in addition, in a deployment, if instead, or in addition, in a deployment, if more appropriate:
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 [OLSRv2]) and before message transmission (Section 11.2 of
[RFC6130] and Section 16.2 of [OLSRv2]), the additional TLVs [RFC6130] and Section 16.2 of [OLSRv2]), 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 framework. outgoing message when using this framework.
The following processing steps MUST be performed for a cryptographic The following processing steps (when using a single timestamp version
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 is reinserted into the message in step 5. The message size and
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 is updated accordingly. the Message TLV Block. The message size and Message TLV block
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 is updated accordingly. Message TLV Block. The message size and Message TLV block size
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 is updated accordingly. The message size and Message TLV Block size are updated
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
TLVs, or more than one TIMESTAMP and/or ICV TLVs. All TIMESTAMP 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 [OLSRv2] 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 [OLSRv2] 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
skipping to change at page 10, line 21 skipping to change at page 10, line 36
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 TLVs 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
alternative TIMESTAMP and/or ICV TLVs, or more than one TIMESTAMP alternative TIMESTAMP and/or ICV TLVs, or more than one TIMESTAMP
and/or ICV TLVs. and/or ICV TLVs.
6.3.1. Invalidating 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. Invalidating 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 is are temporarily removed from the message, and the message size
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 integrity check value for the parameters specified
in the identified ICV Message TLV, as specified in [RFC6622bis]. in the identified ICV Message TLV, as specified in [RFC6622bis].
4. If this integrity check value differs from the value of <ICV- 4. If this integrity check value differs from the value of
data> in the ICV Message TLV, then the message validation fails. <ICV-data> in the ICV Message TLV, then the message validation
fails. If the <ICV-data> has been truncated (as specified in
[RFC6622bis], the integrity check value calculated in the
previous step MUST be truncated to the TLV length of the ICV
Message TLV before comparing it with the <ICV-data>.
5. Otherwise, the message validation succeeds. The message's <msg- 5. Otherwise, the message validation succeeds. The message's
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 is able to generate ICVs or validate messages, it Before a router is able to generate ICVs or validate messages, it
MUST acquire the shared secret key(s) to be used by all routers that MUST acquire the shared secret key(s) to be used by all routers that
are to participate in the network. This specification does not are to participate in the network. This specification does not
define how a router acquires secret keys. define how a router acquires secret keys.
skipping to change at page 12, line 7 skipping to change at page 12, line 27
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 is countered. add a valid ICV TLV to a message, identity spoofing is countered.
9.1.2. Link Spoofing 9.1.2. Link Spoofing
Link spoofing is countered by the framework specified in this Link spoofing is countered by the framework specified in this
document, using the same argument as in Section 9.1.1. document, using the same argument as in Section 9.1.1.
9.1.3. Replay Attack 9.1.3. Replay Attack
Replay attacks are partly counteracted by the framework specified in Replay attacks are partly countered by the framework 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 the
limits on the time interval are specified so that this will have a limits on the time interval are specified so that this will have a
limited effect on the operation of the protocol. limited effect on the operation of the protocol.
skipping to change at page 12, line 38 skipping to change at page 13, line 9
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 framework relies on an out-of-band protocol or mechanism for This framework 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 framework does not provide a key revocation mechanism. This framework does not provide a key revocation mechanism.
10. Normative References 10. Acknowledgments
The authors would like to gratefully acknowledge the following
people: Henning Rogge (Frauenhofer FKIE).
11. Normative References
[OLSRv2] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, [OLSRv2] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
"The Optimized Link State Routing Protocol version 2", "The Optimized Link State Routing Protocol version 2",
work in progress draft-ietf-manet-olsrv2-19, March 2013. 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 MANET Packet/Message Format", RFC 5444,
February 2009. February 2009.
[RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc [RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc
Network (MANET) Neighborhood Discovery Protocol (NHDP)", Network (MANET) Neighborhood Discovery Protocol (NHDP)",
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-01, March 2013. progress draft-ietf-manet-rfc6622-bis-02, April 2013.
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. 37 change blocks. 
78 lines changed or deleted 100 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/