NHDP OLSRv2 integrity: Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)
A required tamper seal and freshness stamp for the control messages of wireless mesh routing protocols.
Herberg, U., Dearlove, C., and T. Clausen, "Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)", RFC 7183, DOI 10.17487/RFC7183, April 2014, <https://www.rfc-editor.org/info/rfc7183>.
@misc{rfc7183,
series = {Request for Comments},
number = 7183,
howpublished = {RFC 7183},
publisher = {RFC Editor},
doi = {10.17487/RFC7183},
url = {https://www.rfc-editor.org/info/rfc7183},
author = {U. Herberg and C. Dearlove and T. Clausen},
title = {{Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)}},
pagetotal = 15,
year = 2014,
month = apr,
} RFC text
Contents
Internet Engineering Task Force (IETF) U. Herberg
Request for Comments: 7183 Fujitsu Laboratories of America
Updates: 6130, 7181 C. Dearlove
Category: Standards Track BAE Systems ATC
ISSN: 2070-1721 T. Clausen
LIX, Ecole Polytechnique
April 2014
Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and
Optimized Link State Routing Protocol Version 2 (OLSRv2)
Abstract
This document specifies integrity and replay protection for the
Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)
and the Optimized Link State Routing Protocol version 2 (OLSRv2).
This protection is achieved by using an HMAC-SHA-256 Integrity Check
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
protocols that use the generalized packet/message format described in
RFC 5444.
This document updates RFC 6130 and RFC 7181 by mandating the
implementation of this integrity and replay protection in NHDP and
OLSRv2.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
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 (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Applicability Statement .........................................5
4. Protocol Overview and Functioning ...............................6
5. Parameters ......................................................7
6. Message Generation and Processing ...............................9
6.1. Message Content ............................................9
6.2. Message Generation ........................................10
6.3. Message Processing ........................................11
6.3.1. Validating a Message Based on Timestamp ............11
6.3.2. Validating a Message Based on Integrity Check ......12
7. Provisioning of Routers ........................................12
8. Security Considerations ........................................12
8.1. Mitigated Attacks .........................................13
8.1.1. Identity Spoofing ..................................13
8.1.2. Link Spoofing ......................................13
8.1.3. Replay Attack ......................................13
8.2. Limitations ...............................................13
9. Acknowledgments ................................................14
10. References ....................................................14
10.1. Normative References .....................................14
10.2. Informative References ...................................14
1. Introduction
This specification updates [RFC6130] and [RFC7181] by defining
mandatory-to-implement security mechanisms (for integrity and replay
protection). A deployment of these protocols may choose to employ an
alternative(s) to these mechanisms; in particular, it may choose to
protect packets rather than messages, it may choose to use an
alternative Integrity Check Value (ICV) with preferred properties,
and/or it may use an alternative timestamp. A deployment may choose
to use no such security mechanisms, but this is not recommended.
The mechanisms specified are the use of an ICV for protection of the
protocols' control messages and the use of timestamps in those
messages to prevent replay attacks. Both use the TLV mechanism
specified in [RFC5444] to add this information to the messages.
These ICV and TIMESTAMP TLVs are defined in [RFC7182]. Different ICV
TLVs are used for HELLO messages in NHDP and TC (Topology Control)
messages in OLSRv2, the former also protecting the source address of
the IP datagram that contains the HELLO message. This is because the
IP datagram source address is used by NHDP to determine the address
of a neighbor interface, and it is not necessarily otherwise
contained in the HELLO message, while OLSRv2's TC message is
forwarded in a new packet; thus, it has no single IP datagram source
address.
The mechanism specified in this document is placed in the packet/
message processing flow as indicated in Figure 1. It exists between
the packet parsing/generation function of [RFC5444] and the message
processing/generation function of NHDP and OLSRv2.
| |
Incoming | /|\ Outgoing
packet \|/ | packet
| |
+--------------------------------+
| |
| RFC 5444 packet |
| parsing/generation |
| |
+--------------------------------+
| |
Messages | /|\ Messages with
\|/ | added TLVs
| |
D +--------------------------------+
R /__________________ | |
O \ Messages | Mechanism specified in |
P (failed check) | this document |
| |
+--------------------------------+
| |
Messages | /|\ Messages
(passed check) \|/ |
| |
+--------------------------------+
| |
| NHDP/OLSRv2 message |
| processing/generation |
| |
+--------------------------------+
Figure 1: Relationship with RFC 5444 and NHDP/OLSRv2
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
Additionally, this document uses the terminology and notation of
[RFC5444], [RFC6130], [RFC7181], and [RFC7182].
3. Applicability Statement
[RFC6130] and [RFC7181] enable specifications of extensions to
recognize additional reasons for rejecting a message as "badly formed
and therefore invalid for processing", and mention security
(integrity protection) as an explicit example. This document
specifies a mechanism that provides this functionality.
Implementations of [RFC6130] and [RFC7181] MUST include this
mechanism, and deployments of [RFC6130] and [RFC7181] SHOULD use this
mechanism, except when a different security mechanism is more
appropriate.
The applicability of this mechanism is determined by its
characteristics, which are that it:
o Specifies a security mechanism that is required to be included in
conforming implementations of [RFC6130] and [RFC7181].
o Specifies an association of ICVs with protocol messages, and
specifies how to use a missing or invalid ICV as a reason to
reject a message as "badly formed and therefore invalid for
processing".
o Specifies the implementation of an ICV Message TLV, defined in
[RFC7182], using a SHA-256-based Hashed Message Authentication
Code (HMAC) applied to the appropriate message contents (and for
HELLO messages also including the IP datagram source address).
Implementations of [RFC6130] and [RFC7181] MUST support an
HMAC-SHA-256 ICV TLV, and deployments SHOULD use it except when
use of a different algorithm is more appropriate. An
implementation MAY use more than one ICV TLV in a message, as long
as they each use a different algorithm or key to calculate the
ICV.
o Specifies the implementation of a TIMESTAMP Message TLV, defined
in [RFC7182], to provide message replay protection.
Implementations of [RFC6130] and [RFC7181] using this mechanism
MUST support a timestamp based on POSIX time, and deployments
SHOULD use it if the clocks in all routers in the network can be
synchronized with sufficient precision.
o Assumes that a router that is able to generate correct integrity
check values is considered trusted.
This mechanism does not:
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
differentiated using the <key-id> field defined in an ICV TLV in
[RFC7182].)
o Specify how to distribute cryptographic material (shared secret
key(s)).
o Specify how to detect compromised routers with valid keys.
o Specify how to handle (revoke) compromised routers with valid
keys.
4. Protocol Overview and Functioning
The mechanism specified in this document provides the following
functionalities for use with messages specified by [RFC6130] and
[RFC7181]:
o Generation of ICV Message TLVs (as defined in [RFC7182]) for
inclusion in an outgoing message. An implementation of [RFC6130]
and [RFC7181] MAY use more than one ICV TLV in a message, even
with the same type extension, but these ICV TLVs MUST each use
different keys or they MUST 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 [RFC7181] 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 Message TLVs (as defined in [RFC7182]) for
inclusion in an outgoing message. An implementation of [RFC6130]
and [RFC7181] MAY use more than one ICV TLV in a message, but it
MUST NOT use the same type extension. An implementation of
[RFC6130] and [RFC7181] 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] [RFC7181]. An
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
shared by all routers.
o Verification of TIMESTAMP Message TLVs (as defined in [RFC7182])
contained in a message, in order to determine if this message MUST
be rejected as "badly formed and therefore invalid for processing"
[RFC6130] [RFC7181]. An implementation of [RFC6130] and [RFC7181]
that is able to synchronize the clocks in all routers in the
network with sufficient precision MUST at least be able to verify
a TIMESTAMP TLV using POSIX time.
ICV Packet TLVs (as defined in [RFC7182]) MAY be used by a deployment
of the multiplexing process defined in [RFC5444], either 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 equally good, and
also protects the packet header. In the case of OLSRv2, the packet
protection has different properties than the message protection,
especially for some forms of ICV. When packets contain more than one
message, the packet protection has lower overheads in space and
computation time.)
When a router generates a message on a MANET interface, this
mechanism:
o Specifies how to calculate an ICV for the message.
o Specifies how to include that ICV using an ICV Message TLV.
[RFC6130] and [RFC7181] allow for the rejection of incoming messages
prior to processing by NHDP or OLSRv2. This mechanism, when used,
specifies that a message MUST be rejected if the ICV Message TLV is
absent, or its value cannot be verified. Note that this means that
routers whose implementation of NHDP and/or OLSRv2 does not include
this specification will be ignored by routers using this mechanism,
and these two sets of routers will, by design, form disjoint MANETs.
(The unsecured MANET will retain some information about the secured
MANET, but be unable to use it, not having any recognized symmetric
links with the secured MANET.)
5. Parameters
The following router parameters are specified for use by the two
protocols; the first is required only by NHDP, but may be visible to
OLSRv2, the second is required only by OLSRv2:
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
validating the HELLO message, minus the timestamp indicated in the
TIMESTAMP TLV of the HELLO message, is greater than
MAX_HELLO_TIMESTAMP_DIFF, the HELLO message MUST be silently
discarded.
o MAX_TC_TIMESTAMP_DIFF - The maximum age that a TC message to be
validated may have. If the current POSIX time of the router
validating the TC message, minus the timestamp indicated in the
TIMESTAMP TLV of the TC message, is greater than
MAX_TC_TIMESTAMP_DIFF, the TC message MUST be silently discarded.
The following constraints apply to these parameters:
o MAX_HELLO_TIMESTAMP_DIFF > 0
o MAX_TC_TIMESTAMP_DIFF > 0
However, these bounds are insufficient: MAX_HELLO_TIMESTAMP_DIFF and
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
been sent by a router and received by all intended destinations).
For HELLO messages, this needs only cover a single hop, but TC
messages may have been forwarded a number of times. In particular,
for TC messages, if using jitter as specified in [RFC7181] and
[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
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
memory resources of routers (e.g., queuing delays, and delays for
processing ICVs). An implementation MAY set lower and/or upper
bounds on these parameters, if so, then these MUST allow values
meeting these requirements. An implementation MAY make its value of
MAX_TC_TIMESTAMP_DIFF dependent on the number of hops that a TC
message has traveled.
The above constraints assume ideal time synchronization of the clock
in all routers in the network. The parameters
MAX_HELLO_TIMESTAMP_DIFF and MAX_TC_TIMESTAMP_DIFF (and any
constraints on them) MAY be increased to allow for expected timing
differences between routers (between neighboring routers for
MAX_HELLO_TIMESTAMP_DIFF, allowing for greater separation, but
usually not per hop, for MAX_TC_TIMESTAMP_DIFF).
Note that excessively large values of these parameters defeats their
objectives, so these parameters SHOULD be as large as is required,
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 resource limitations.
In addition, when using the default message intervals and validity
times as specified in [RFC6130] and [RFC7181], 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 longer to traverse the MANET, thus even
in a perfectly synchronized network, the TC maximum delay would
usually be greater than 1 second.
A finer granularity 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
This section specifies how messages are generated and processed by
[RFC6130] and [RFC7181] when using this mechanism.
6.1. Message Content
Messages MUST have the content specified in [RFC6130] and [RFC7181],
respectively. In addition, messages that conform to this mechanism
MUST contain:
o At least one ICV Message TLV (as specified in [RFC7182]),
generated according to Section 6.2. Implementations of [RFC6130]
and [RFC7181] MUST support the following version of the ICV TLV,
but other versions MAY be used instead, or in addition, in a
deployment, if more appropriate:
* For TC messages:
+ type-extension := 1
* For HELLO messages:
+ type-extension := 2
* hash-function := 3 (SHA-256)
* cryptographic-function := 3 (HMAC)
The ICV Value MAY be truncated as specified in [RFC7182]; 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 [RFC7182]),
generated according to Section 6.2. Implementations of [RFC6130]
and [RFC7181] using this mechanism MUST support the following
version of the TIMESTAMP TLV, but other versions MAY be used
instead, or in addition, in a deployment, if more appropriate:
* type-extension := 1
6.2. Message Generation
After message generation (Section 11.1 of [RFC6130] and Section 16.1.
of [RFC7181]) and before message transmission (Section 11.2 of
[RFC6130] and Section 16.2 of [RFC7181]), the additional TLVs
specified in Section 6.1 MUST (unless already present) be added to an
outgoing message when using this mechanism.
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:
1. All ICV TLVs (if any) are temporarily removed from the message.
Any temporarily removed ICV TLVs MUST be stored, in order to be
reinserted into the message in step 5. The message size and
Message TLV Block size are updated accordingly.
2. <msg-hop-count> and <msg-hop-limit>, if present, are temporarily
set to 0.
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
size are updated accordingly.
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
are updated accordingly.
5. All ICV TLVs that were temporary removed in step 1, are restored.
The message size and Message TLV Block size are updated
accordingly.
6. <msg-hop-count> and <msg-hop-limit>, if present, are restored to
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
Both [RFC6130] and [RFC7181] specify that:
On receiving a ... message, a router MUST first check if the
message is invalid for processing by this router
[RFC6130] and [RFC7181] proceed to give a number of conditions that,
each, will lead to a rejection of the message as "badly formed and
therefore invalid for processing". When using a single timestamp
version, and a single ICV algorithm, add the following conditions to
that list, each of which, if true, MUST cause NHDP or OLSRv2 (as
appropriate) to consider the message as invalid for processing when
using this mechanism:
1. The Message TLV Block of the message does not contain exactly one
TIMESTAMP TLV of the selected version. This version
specification includes the type extension. (The Message TLV
Block may also contain TIMESTAMP TLVs of other versions.)
2. The Message TLV Block does not contain exactly one ICV TLV using
the selected algorithm and key identifier. This algorithm
specification includes the type extension, and for type
extensions 1 and 2, the hash function and cryptographic function.
(The Message TLV Block may also contain ICV TLVs using other
algorithms and key identifiers.)
3. Validation of the identified (in step 1) TIMESTAMP TLV in the
Message TLV Block of the message fails, as according to
Section 6.3.1.
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.
An implementation MAY check the existence of, and verify, either an
alternative TIMESTAMP and/or ICV TLVs or more than one TIMESTAMP and/
or ICV TLVs.
6.3.1. Validating a Message Based on Timestamp
For a TIMESTAMP Message TLV with type extension 1 (POSIX time)
identified as described in Section 6.2:
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
MAX_TC_TIMESTAMP_DIFF (for a TC message), then the message
validation fails.
2. Otherwise, the message validation succeeds.
If a deployment chooses to use a different type extension from 1,
appropriate measures MUST be taken to verify freshness of the
message.
6.3.2. Validating a Message Based on Integrity Check
For an ICV Message TLV identified as described in Section 6.2:
1. All ICV Message TLVs (including the identified ICV Message TLV)
are temporarily removed from the message, and the message size
and Message TLV Block size are updated accordingly.
2. The message's <msg-hop-count> and <msg-hop-limit> fields are
temporarily set to 0.
3. Calculate the ICV for the parameters specified in the identified
ICV Message TLV, as specified in [RFC7182].
4. If this ICV differs from the value of <ICV-data> in the ICV
Message TLV, then the message validation fails. If the
<ICV-data> has been truncated (as specified in [RFC7182], the ICV
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-hop-count> and <msg-hop-limit> fields are restored to their
previous value, and the ICV Message TLVs are returned to the
message, whose size is updated accordingly.
7. Provisioning of Routers
Before a router using this mechanism is able to generate ICVs or
validate messages, it MUST acquire the shared secret key(s) to be
used by all routers that are to participate in the network. This
specification does not define how a router acquires secret keys.
Once a router has acquired suitable key(s), it MAY be configured to
use, or not use, this mechanism. Section 23.6 of [RFC7181] provides
a rationale based on [BCP107] why no key management is specified for
OLSRv2.
8. Security Considerations
This document specifies a security mechanism for use with NHDP and
OLSRv2 that allows for mitigating several security threats.
8.1. Mitigated Attacks
This section briefly summarizes security threats that are mitigated
by the mechanism presented in this document.
8.1.1. Identity Spoofing
As only routers possessing the selected shared secret key are able to
add a valid ICV TLV to a message, identity spoofing, where an
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
is only possible to determine that it is a valid router in the
network, not to discern particular routers. Therefore, a malicious
router in possession of valid keys (e.g., a compromised router) may
still spoof the identity of another router using the same key.
8.1.2. Link Spoofing
Link spoofing, where an attacker falsely represents the existence of
a nonexistent link, or otherwise misrepresents a link's state, is
countered by the mechanism specified in this document, using the same
argument as in Section 8.1.1.
8.1.3. Replay Attack
Replay attacks are partly countered by the mechanism specified in
this document, but this depends on synchronized clocks of all routers
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
is contained in message. As an attacker cannot modify the content of
this timestamp (as it is protected by the identity check value), an
attacker cannot replay messages after this time. Within this time
interval, it is still possible to perform replay attacks; however,
the limits on the time interval are specified so that this will have
a limited effect on the operation of the protocol.
8.2. Limitations
If no synchronized clocks are available in the MANET, replay attacks
cannot be countered by the mechanism provided by this document. An
alternative version of the TIMESTAMP TLV defined in [RFC7182], with a
monotonic sequence number, may have some partial value in this case,
but will necessitate adding state to record observed message sequence
number information.
The mechanism provided by this document does not avoid or detect
security attacks by routers possessing the shared secret key that is
used to generate integrity check values for messages.
This mechanism relies on an out-of-band protocol or mechanism for
distributing the shared secret key(s) (and if an alternative
integrity check value is used, any additional cryptographic
parameters).
This mechanism does not provide a key management mechanism. Refer to
Section 23.6 of [RFC7181] for a detailed discussion why the automated
key management requirements specified in [BCP107] do not apply for
OLSRv2 and NHDP.
9. Acknowledgments
The authors would like to gratefully acknowledge the following
people: Justin Dean (NRL) and Henning Rogge (Frauenhofer FKIE).
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
"Generalized Mobile Ad Hoc Network (MANET) Packet/Message
Format", RFC 5444, February 2009.
[RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
Network (MANET) Neighborhood Discovery Protocol (NHDP)",
RFC 6130, April 2011.
[RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
"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
Hoc Networks (MANETs)", RFC 7182, April 2014.
10.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
Considerations in Mobile Ad Hoc Networks (MANETs)", RFC
5148, February 2008.
Authors' Addresses
Ulrich Herberg
Fujitsu Laboratories of America
1240 E. Arques Ave.
Sunnyvale, CA, 94085
USA
EMail: ulrich@herberg.name
URI: http://www.herberg.name/
Christopher Dearlove
BAE Systems Advanced Technology Centre
West Hanningfield Road
Great Baddow, Chelmsford
United Kingdom
Phone: +44 1245 242194
EMail: chris.dearlove@baesystems.com
URI: http://www.baesystems.com/
Thomas Heide Clausen
LIX, Ecole Polytechnique
91128 Palaiseau Cedex
France
Phone: +33 6 6058 9349
EMail: T.Clausen@computer.org
URI: http://www.thomasclausen.org/
ISO Plain Language
On this page
§1What the Document Adds
This specification updates RFC 6130 and RFC 7181 by defining security mechanisms that implementations must include, for integrity and replay protection. A deployment of these protocols may choose to employ an alternative to these mechanisms: it may choose to protect packets rather than messages, it may choose to use an alternative integrity check value with preferred properties, and it may use an alternative timestamp. A deployment may choose to use no security mechanism at all, but this is not recommended.
The mechanisms specified are the use of an integrity check value (ICV) to protect the control messages of the protocols, and the use of timestamps in those messages to prevent replay attacks. Both use the TLV mechanism of RFC 5444 to carry this information in the message, and the ICV and TIMESTAMP TLVs themselves are defined in RFC 7182.
Different ICV TLVs are used for HELLO messages in NHDP and for TC (Topology Control) messages in OLSRv2. The HELLO ICV also protects the source address of the IP datagram that carries the message, because NHDP uses that address to determine the address of a neighbour interface and it is not necessarily otherwise contained in the HELLO message. An OLSRv2 TC message, by contrast, is forwarded in a new packet and so has no single IP datagram source address.
NHDP is the protocol routers use to find out who their neighbours are, and OLSRv2 is the protocol that works out the routes. Both send control messages that any device nearby can send. This RFC says that each of those messages must carry a value that only a router with the shared key can compute, and a time stamp.
The two protocols need slightly different treatment. A HELLO message is used to work out which interface a neighbour is on, and the IP address the packet came from carries that information, so the check value covers that address too. A topology message is forwarded in a new packet each time, so it has no such address of its own.
§3What the Mechanism Covers and What It Leaves Out
RFC 6130 and RFC 7181 allow specifications of extensions to recognise additional reasons for rejecting a message as badly formed and therefore invalid for processing, and they mention security, meaning integrity protection, as an explicit example. This document specifies such a mechanism.
Implementations of RFC 6130 and RFC 7181 MUST include this mechanism, and deployments SHOULD use it, except when a different security mechanism is more appropriate.
The applicability of the mechanism rests on five characteristics. It specifies a security mechanism that conforming implementations must include. It specifies an association of integrity check values with protocol messages, and how to use a missing or invalid value as a reason to reject a message as badly formed. It specifies an ICV Message TLV of RFC 7182 using a SHA-256-based Hashed Message Authentication Code (HMAC) applied to the appropriate message contents, and for HELLO messages also to the IP datagram source address; implementations MUST support an HMAC-SHA-256 ICV TLV, and deployments SHOULD use it, and a message MAY carry more than one ICV TLV as long as each uses a different algorithm or key. It specifies the TIMESTAMP Message TLV of RFC 7182 for replay protection, using POSIX time where the clocks can be synchronised with sufficient precision. And it assumes that a router able to generate correct integrity check values is trusted.
Four things are deliberately left out. The document does not specify which key identifiers to use in a MANET where routers share more than one secret key; such keys are told apart by the key-id field of an ICV TLV. It does not specify how to distribute the cryptographic material. And it does not specify how to detect compromised routers that hold valid keys, nor how to revoke them.
The scope of the document is deliberately narrow. It says how to seal a message and how to check the seal, and it requires every implementation to support that. It does not say how the routers get the shared key in the first place, how to decide which of several keys to use, or what to do when a router that has the key turns out to be dishonest. Those are left to the deployment.
§4Where the Check Sits
The mechanism is placed in the packet and message processing flow shown in Figure 1 of the RFC. It exists between the packet parsing and generation function of RFC 5444 and the message processing and generation function of NHDP and OLSRv2.
In the outgoing direction the mechanism specifies how to calculate an integrity check value for the message and how to include that value in an ICV Message TLV. In the incoming direction it verifies the ICV and TIMESTAMP TLVs contained in a message, so that a message can be rejected as badly formed and therefore invalid for processing before NHDP or OLSRv2 processes it. A message MUST be rejected if the ICV Message TLV is absent or its value cannot be verified.
That last rule has a consequence worth stating plainly: routers whose implementation does not include this specification will be ignored by routers that use it, and the two sets of routers will by design form disjoint MANETs. The unsecured MANET will retain some information about the secured one, but will be unable to use it, having no recognised symmetric links with it.
ICV Packet TLVs, also defined in RFC 7182, MAY be used by a deployment of the multiplexing process of RFC 5444, either as well as or instead of the protection of the NHDP and OLSRv2 messages. In the case of NHDP, packet protection is equally good and also protects the packet header. In the case of OLSRv2, packet protection has different properties from message protection, especially for some forms of ICV, and when a packet contains more than one message, packet protection has lower overheads in space and computation time.
The check sits in the middle of the message handling, after the packet has been taken apart and before the routing protocol acts on what it found. On the way out it stamps the message; on the way in it checks the stamp and drops the message if the stamp does not match.
One consequence follows from the rule that a missing stamp means rejection: a router running an older implementation without this feature will not be recognised by the secured routers at all. The two groups end up as separate networks that cannot pass traffic between them.
- RFC 5444 packet parsingTakes the packet apart and builds it up
- The mechanism in this documentAdds the seal and the time stamp, and checks them on arrival
- NHDP and OLSRv2 message processingActs on the message, once it has passed the check
§5The Two Age Parameters
Two router parameters are specified for use by the two protocols. The first is required only by NHDP but may be visible to OLSRv2, and the second is required only by OLSRv2.
MAX_HELLO_TIMESTAMP_DIFF is the maximum age that a HELLO message to be validated may have. If the current POSIX time of the router validating the HELLO message, minus the timestamp in its TIMESTAMP TLV, is greater than this value, the HELLO message MUST be silently discarded. MAX_TC_TIMESTAMP_DIFF is the same thing for a TC message.
Both values must be greater than zero, but those bounds are not sufficient. Each MUST be at least as great as the maximum expected age of a message, that is the time between a message being sent by a router and reaching all its intended destinations. For a HELLO message this needs to cover a single hop, but a TC message may have been forwarded a number of times. For TC messages, if the jitter of RFC 7181 and RFC 5148 is used, the largest contribution to the age may be a delay of up to F_MAXJITTER per hop, except for the final hop. Other per-hop delays include the link layer used in the MANET and the CPU and memory resources of the routers, through queuing delays and delays for processing integrity check values. An implementation MAY set lower and upper bounds on these parameters, and MAY make its value of MAX_TC_TIMESTAMP_DIFF depend on the number of hops the message has travelled.
The constraints assume ideal time synchronisation of the clocks in all the routers. The parameters MAY be increased to allow for expected timing differences between routers, between neighbouring routers for MAX_HELLO_TIMESTAMP_DIFF and, allowing for greater separation, for MAX_TC_TIMESTAMP_DIFF. Excessively large values defeat the purpose of the parameters, so they SHOULD be as large as required and not significantly larger.
Using POSIX time allows a resolution of no more than one second, and in many MANET use cases time synchronisation much below one second is not possible because of unreliable and high-delay channels, mobility, interrupted communication and possible resource limitations. With the default message intervals and validity times of RFC 6130 and RFC 7181, where the shortest periodic message interval is 2 seconds, repeating a message within a second is actually beneficial rather than harmful, at a small bandwidth cost, and the use of jitter can make a message take that long or longer to cross the MANET, so even in a perfectly synchronised network the TC maximum delay would usually be greater than one second. A finer granularity than one 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 one second.
Each router has two settings: how old a HELLO message may be before it is thrown away, and the same for a topology message. Both must be larger than the time a message takes to reach its last recipient, or legitimate messages will be dropped. For a HELLO that is one hop, but a topology message may cross the whole network, and each hop adds a delay, so the setting for topology messages has to be much more generous.
Because the time stamp uses POSIX time, the resolution is one second. In a wireless network, where the channels are slow and the routers move, clocks that agree more closely than that are often not possible. Setting the limit too wide weakens the replay protection, so the value should be as small as the network can manage.
§6.1What a Protected Message Must Contain
Messages must have the content specified in RFC 6130 and RFC 7181 respectively. In addition, a message that conforms to this mechanism must contain at least one ICV Message TLV, as specified in RFC 7182, and at least one TIMESTAMP Message TLV of the same specification.
Implementations must support a particular version of the ICV TLV, though other versions may be used instead or in addition in a deployment if more appropriate. For TC messages the type extension is 1, and for HELLO messages it is 2. The hash function is 3, which is SHA-256, and the cryptographic function is 3, which is HMAC. The ICV value MAY be truncated as specified in RFC 7182, and the selection of an appropriate length MAY be administratively configured. A message may contain several ICV Message TLVs.
For the TIMESTAMP TLV, implementations must support type extension 1, which is POSIX time, though other versions may be used instead or in addition.
Every protected message carries at least one seal and at least one time stamp. The seal is computed with HMAC and SHA-256, the standard combination for a keyed hash. The two message types use different numbers for the same seal format, so that a HELLO seal and a topology seal cannot be confused, and the seal may be shortened to save space.
- TC messagesICV TLV with type extension 1.
- HELLO messagesICV TLV with type extension 2, and the seal also covers the IP datagram source address.
- Hash function3, which is SHA-256.
- Cryptographic function3, which is HMAC.
- Time stampTIMESTAMP TLV with type extension 1, which is POSIX time.
§6.2Adding the Seal to an Outgoing Message
After message generation, and before message transmission, the additional TLVs must be added to an outgoing message when using this mechanism. Six steps are defined for the case of a single timestamp version and a single ICV algorithm.
First, all ICV TLVs, if any, are temporarily removed from the message and stored, so that they can be reinserted later, and the message size and the Message TLV Block size are updated accordingly. Second, the msg-hop-count and msg-hop-limit fields, if present, are temporarily set to zero. Third, a TLV of type TIMESTAMP is added to the Message TLV Block, and the sizes are updated. Fourth, a TLV of type ICV is added, and the sizes are updated again. Fifth, the ICV TLVs removed in the first step are restored. Sixth, the hop count and hop limit fields are restored to their previous values.
An implementation MAY add alternative or additional TIMESTAMP and ICV TLVs. All TIMESTAMP TLVs MUST be inserted before adding the ICV TLVs.
The order of operations matters. The old seal, if there is one, is taken out first, and the hop count and hop limit are set to zero, so that the value covers the message in a form that is the same on every hop. The time stamp goes in next, then the seal is computed over the message with the time stamp in place. The old seal is then put back, and the hop count and limit are restored, because they change as the message is forwarded.
§6.3Checking an Incoming Message
Both RFC 6130 and RFC 7181 require a router to first check whether an incoming message is invalid for processing, and they list a number of conditions that each lead to a rejection of the message as badly formed and therefore invalid for processing. When using a single timestamp version and a single ICV algorithm, four further conditions are added to that list, each of which must cause NHDP or OLSRv2 to consider the message invalid.
The first is that the Message TLV Block does not contain exactly one TIMESTAMP TLV of the selected version, where the version specification includes the type extension. The block may also contain TIMESTAMP TLVs of other versions. The second is that the block does not contain exactly one ICV TLV using the selected algorithm and key identifier, where the algorithm specification includes the type extension and, for type extensions 1 and 2, the hash function and the cryptographic function. The block may also contain ICV TLVs using other algorithms and key identifiers.
The third condition is that validation of the identified TIMESTAMP TLV fails. For a TIMESTAMP TLV with type extension 1, validation fails if the current POSIX time minus the value in that TLV is greater than MAX_HELLO_TIMESTAMP_DIFF for a HELLO message or MAX_TC_TIMESTAMP_DIFF for a TC message; otherwise it succeeds. If a deployment chooses a type extension other than 1, appropriate measures must be taken to verify the freshness of the message.
The fourth condition is that validation of the identified ICV TLV fails. To validate it, all ICV Message TLVs are temporarily removed from the message and the sizes updated, the hop count and hop limit fields are temporarily set to zero, and the ICV is calculated for the parameters in the identified TLV. If this ICV differs from the value in the TLV, validation fails; if the value has been truncated, the calculated value must be truncated to the same length before the comparison. Otherwise validation succeeds, the hop count and limit are restored, and the ICV TLVs are returned to the message.
A received message has to pass four tests: there is exactly one time stamp of the agreed version, there is exactly one seal of the agreed algorithm, the time stamp is recent enough, and the seal matches the message.
The last test is done by taking the seal out of the message, zeroing the hop count and limit so that the calculation is the same as it was at the sender, recomputing the seal, and comparing it with the one that arrived. A mismatch means the message was altered in flight, or came from someone without the key.
- 1No single TIMESTAMP TLV — The Message TLV Block does not contain exactly one TIMESTAMP TLV of the selected version.
- 2No single ICV TLV — The Message TLV Block does not contain exactly one ICV TLV using the selected algorithm and key identifier.
- 3Timestamp validation failed — The message is older than the limit for its type, so it is discarded.
- 4Integrity check failed — The recomputed ICV does not match the value in the message.
§8What It Stops and What It Does Not
The document specifies a security mechanism for NHDP and OLSRv2 that mitigates several threats.
Identity spoofing, where an attacker falsely claims the identity of a valid router, is countered, because only routers possessing the selected shared secret key are able to add a valid ICV TLV to a message. When one shared key is used for all the routers in the MANET, however, it is only possible to tell that a router is valid, not to tell which router it is, so a malicious router holding the valid key may still spoof the identity of another router using the same key. Link spoofing, where an attacker falsely represents the existence of a nonexistent link or otherwise misrepresents the state of a link, is countered on the same argument.
Replay attacks are partly countered, but this depends on synchronised clocks in the MANET. An attacker that records messages to replay them later can only do so within the time interval allowed after the timestamp in the message, because the attacker cannot modify the timestamp, which is protected by the integrity check value. Within that interval replay is still possible, and the limits on the interval are set so that this has a limited effect on the operation of the protocol.
The limitations are stated plainly. If no synchronised clocks are available, replay attacks cannot be countered by this mechanism at all; an alternative version of the TIMESTAMP TLV with a monotonic sequence number may have some partial value, but needs state to record the observed sequence numbers. The mechanism does not avoid or detect attacks by routers that hold the shared secret key used to generate the integrity check values. It relies on an out-of-band mechanism for distributing the shared key and any additional cryptographic parameters, and it provides no key management mechanism; Section 23.6 of RFC 7181 discusses at length why the automated key management requirements of RFC 4107 do not apply to OLSRv2 and NHDP.
The mechanism stops an outside device from injecting messages, because it cannot compute the seal. It also limits replay: a recorded message can only be sent again within the window that the time stamp allows, because the time stamp itself is covered by the seal and cannot be changed.
Two limits are worth knowing. The replay protection depends on the clocks in the network being roughly in step, and where they are not, replay cannot be stopped at all. And the mechanism does nothing about a router that has the key and is dishonest, because such a router can produce a perfectly valid seal.