draft-ietf-manet-nhdp-olsrv2-sec-04.txt   draft-ietf-manet-nhdp-olsrv2-sec-05.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: February 15, 2014 T. Clausen Expires: March 14, 2014 T. Clausen
LIX, Ecole Polytechnique LIX, Ecole Polytechnique
August 14, 2013 September 10, 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-04 draft-ietf-manet-nhdp-olsrv2-sec-05
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 February 15, 2014. This Internet-Draft will expire on March 14, 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 32 skipping to change at page 2, line 32
5. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Message Generation and Processing . . . . . . . . . . . . . . 9 6. Message Generation and Processing . . . . . . . . . . . . . . 9
6.1. Message Content . . . . . . . . . . . . . . . . . . . . . 9 6.1. Message Content . . . . . . . . . . . . . . . . . . . . . 9
6.2. Message Generation . . . . . . . . . . . . . . . . . . . . 10 6.2. Message Generation . . . . . . . . . . . . . . . . . . . . 10
6.3. Message Processing . . . . . . . . . . . . . . . . . . . . 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 . . . . 12 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 . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9.1. Alleviated Attacks . . . . . . . . . . . . . . . . . . . . 13 9.1. Mitigated Attacks . . . . . . . . . . . . . . . . . . . . 13
9.1.1. Identity Spoofing . . . . . . . . . . . . . . . . . . 13 9.1.1. Identity Spoofing . . . . . . . . . . . . . . . . . . 13
9.1.2. Link Spoofing . . . . . . . . . . . . . . . . . . . . 13 9.1.2. Link Spoofing . . . . . . . . . . . . . . . . . . . . 13
9.1.3. Replay Attack . . . . . . . . . . . . . . . . . . . . 13 9.1.3. Replay Attack . . . . . . . . . . . . . . . . . . . . 13
9.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 13 9.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . . 14 11.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 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 the
framework of security mechanisms (for integrity and replay mandatory to implement security mechanisms (for integrity and replay
protection) that must be included in conforming implementations of protection). A deployment of these protocols may choose to employ
those protocols (the Neighborhood Discovery Protocol, NHDP, and the alternative(s) to these mechanisms, in particular it may choose to
Optimized Link State Routing Protocol version 2, OLSRv2). A protect packets rather than messages, it may choose to use an
deployment of these protocols may choose to employ alternative(s) to alternative integrity check value (ICV) with preferred properties,
these mechanisms, in particular it may choose to protect packets and/or it may use an alternative timestamp. A deployment may choose
rather than messages, it may choose to use an alternative integrity to use no such security mechanisms, but this is not recommended.
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 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 (Topology ICV TLVs are used for HELLO messages in NHDP and TC (Topology
Control) messages in OLSRv2, the former also protecting the source Control) messages in OLSRv2, the former also protecting the source
address of the IP datagram that contains the HELLO message. This is address of the IP datagram that contains the HELLO message. This is
because the IP datagram source address is used by NHDP to determine because the IP datagram source address is used by NHDP to determine
skipping to change at page 5, line 6 skipping to change at page 5, line 6
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 specifications of extensions to [RFC6130] and [OLSRv2] enable specifications of extensions to
recognize additional reasons for rejecting a message as "badly formed recognize additional reasons for rejecting a message as "badly formed
and therefore invalid for processing", and mention security and therefore invalid for processing", and mention security
(integrity protection) as an explicit example. This document (integrity protection) as an explicit example. This document
specifies a framework that provides this functionality. specifies a mechanism 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 mechanism, and deployments of [RFC6130] and [OLSRv2] SHOULD use this
framework, except for when a different security mechanism is more mechanism, except for when a different security mechanism is more
appropriate. appropriate.
The applicability of this framework is determined by its The applicability of this mechanism is determined by its
characteristics, which are that it: characteristics, which are that it:
o Specifies a security framework that is required to be included in o Specifies a security mechanism that is required to be included in
conforming implementations of [RFC6130] and [OLSRv2]. conforming implementations of [RFC6130] and [OLSRv2].
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). Implementations of
[RFC6130] and [OLSRv2] using this framework SHOULD use an HMAC/ [RFC6130] and [OLSRv2] MUST support an HMAC-SHA-256 ICV TLV, and
SHA-256 ICV TLV, except when use of a different algorithm is more deployment SHOULD use it except when use of a different algorithm
appropriate in a deployment. An implementation MAY use more than is more appropriate. An implementation MAY use more than one ICV
one ICV TLV in a message, as long as they each use a different TLV in a message, as long as they each use a different algorithm
algorithm to calculate the ICV. or key to calculate the ICV.
o Specifies the implementation of a TIMESTAMP Message TLV, defined o Specifies the implementation of a TIMESTAMP Message TLV, defined
in [RFC6622bis], to provide message replay protection. in [RFC6622bis], to provide message replay protection.
Deployments of [RFC6130] and [OLSRv2] using this framework SHOULD Implementations of [RFC6130] and [OLSRv2] using this mechanism
use a POSIX time based timestamp, if the clocks in all routers in MUST support a POSIX time based timestamp, and deployments SHOULD
the network can be synchronized with sufficient precision. 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 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 mechanism does not:
o Specify which key identifiers are to be used in a MANET in which o Specify which key identifiers are to be used in a MANET in which
the routers share more than one secret key. (Such keys will be the routers share more than one secret key. (Such keys will be
differentiated using the <key-id> field defined in an ICV TLV in differentiated using the <key-id> field defined in an ICV TLV in
[RFC6622bis].) [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 mechanism specified in this document provides the following
functionalities for use with messages specified by [RFC6130] and functionalities for use with messages specified by [RFC6130] and
[OLSRv2]: [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
different algorithm to calculate the ICV, e.g., with different different keys, or they MUST use a different algorithm to
hash and/or cryptographic functions when using type extension 1 or calculate the ICV, e.g., with different hash and/or cryptographic
2. An implementation of [RFC6130] and [OLSRv2] MUST at least be functions when using type extension 1 or 2. An implementation of
able to generate an ICV TLV using HMAC/SHA-256 and one or more [RFC6130] and [OLSRv2] MUST at least be able to generate an ICV
secret keys shared by all routers. TLV using HMAC-SHA-256 and one or more 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 MUST NOT use 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
skipping to change at page 7, line 12 skipping to change at page 7, line 16
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: mechanism:
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, when used, specifies processing by NHDP or OLSRv2. This mechanism, when used, specifies
that a message MUST be rejected if the ICV Message TLV is absent, or 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 its value cannot be verified. Note that this means that routers
whose implementation of NHDP and/or OLSRv2 does not include this whose implementation of NHDP and/or OLSRv2 does not include this
specification will be ignored by routers using this framework, and specification will be ignored by routers using this mechanism, and
these two sets of routers will, by design, form disjoint MANETs. these two sets of routers will, by design, form disjoint MANETs.
(The unsecured MANET will retain some information about the secured (The unsecured MANET will retain some information about the secured
MANET, but be unable to use it, not having any recognized symmetric MANET, but be unable to use it, not having any recognized symmetric
links with the secured MANET.) links with the secured MANET.)
5. Parameters 5. Parameters
This following router parameters are specified for use by the two 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:
skipping to change at page 9, line 12 skipping to change at page 9, line 15
a perfectly synchronized network, the TC maximum delay would usually a perfectly synchronized network, the TC maximum delay would usually
be greater than 1 second. be greater than 1 second.
A finer granulatity than 1 second, and thus the use of an alternative A finer granulatity than 1 second, and thus the use of an alternative
timestamp, is however RECOMMENDED in cases where, possibly due to timestamp, is however RECOMMENDED in cases where, possibly due to
fast moving routers, message validity times are below 1 second. fast moving routers, message validity times are below 1 second.
6. Message Generation and Processing 6. Message Generation and Processing
This section specifies how messages are generated and processed by This section specifies how messages are generated and processed by
[RFC6130] and [OLSRv2] when using this framework. [RFC6130] and [OLSRv2] when using this mechanism.
6.1. Message Content 6.1. Message Content
Messages MUST have the content specified in [RFC6130] and [OLSRv2] Messages MUST have the content specified in [RFC6130] and [OLSRv2]
respectively. In addition, messages that conform to this framework respectively. In addition, messages that conform to this mechanism
will contain: MUST 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 9, line 44 skipping to change at page 9, line 47
* hash-function := 3 (SHA-256) * hash-function := 3 (SHA-256)
* cryptographic-function := 3 (HMAC) * cryptographic-function := 3 (HMAC)
The ICV Value MAY be truncated as specified in [RFC6622bis]; the The ICV Value MAY be truncated as specified in [RFC6622bis]; the
selection of an appropriate length MAY be administratively selection of an appropriate length MAY be administratively
configured. A message MAY contain several ICV Message TLVs. configured. A message MAY contain several ICV Message TLVs.
o At least one TIMESTAMP Message TLV (as specified in [RFC6622bis]), o At least one TIMESTAMP Message TLV (as specified in [RFC6622bis]),
generated according to Section 6.2. Implementations of [RFC6130] generated according to Section 6.2. Implementations of [RFC6130]
and [OLSRv2] using this framework MUST support the following and [OLSRv2] using this mechanism MUST support the following
version of the TIMESTAMP TLV, but other versions MAY be used version of the TIMESTAMP TLV, but other versions MAY be used
instead, or in addition, in a deployment, if more appropriate: instead, or in addition, in a deployment, if more appropriate:
* type-extension := 1 * type-extension := 1
6.2. Message Generation 6.2. Message Generation
After message generation (Section 11.1 of [RFC6130] and Section 16.1. After message generation (Section 11.1 of [RFC6130] and Section 16.1.
of [OLSRv2]) and before message transmission (Section 11.2 of of [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 mechanism.
The following processing steps (when using a single timestamp version The following processing steps (when using a single timestamp version
and a single ICV algorithm) MUST be performed for a cryptographic and a single ICV algorithm) MUST be performed for a cryptographic
algorithm that is used for generating an ICV for a message: algorithm that is used for generating an ICV for a message:
1. All ICV TLVs (if any) are temporarily removed from the message. 1. All ICV TLVs (if any) are temporarily removed from the message.
Any temporarily removed ICV TLVs MUST be stored, in order to be Any temporarily removed ICV TLVs MUST be stored, in order to be
reinserted into the message in step 5. The message size and reinserted into the message in step 5. The message size and
Message TLV Block size are updated accordingly. Message TLV Block size are updated accordingly.
skipping to change at page 11, line 8 skipping to change at page 11, line 14
"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
version, and a single ICV algorithm, the following conditions to that version, and a single ICV algorithm, the following conditions to that
list, each of which, if true, MUST cause NHDP or OLSRv2 (as list, each of which, if true, MUST cause NHDP or OLSRv2 (as
appropriate) to consider the message as invalid for processing when appropriate) to consider the message as invalid for processing when
using this framework: using this mechanism:
1. The Message TLV Block of the message does not contain exactly one 1. The Message TLV Block of the message does not contain exactly one
TIMESTAMP TLV of the selected version. This version TIMESTAMP TLV of the selected version. This version
specification includes the type extension. (The Message TLV specification includes the type extension. (The Message TLV
Block may also contain TIMESTAMP TLVs of other versions.) Block may also contain TIMESTAMP TLVs of other versions.)
2. The Message TLV block does not contain exactly one ICV TLV using 2. The Message TLV block does not contain exactly one ICV TLV using
the selected algorithm and key identifier. This algorithm the selected algorithm and key identifier. This algorithm
specification includes the type extension, and for type specification includes the type extension, and for type
extensions 1 and 2, the hash function and cryptographic function. extensions 1 and 2, the hash function and cryptographic function.
skipping to change at page 12, line 33 skipping to change at page 12, line 34
previous step MUST be truncated to the TLV length of the ICV previous step MUST be truncated to the TLV length of the ICV
Message TLV before comparing it with the <ICV-data>. Message TLV before comparing it with the <ICV-data>.
5. Otherwise, the message validation succeeds. The message's 5. Otherwise, the message validation succeeds. The message's
<msg-hop-count> and <msg-hop-limit> fields are restored to their <msg-hop-count> and <msg-hop-limit> fields are restored to their
previous value, and the ICV Message TLVs are returned to the previous value, and the ICV Message TLVs are returned to the
message, whose size is updated accordingly. message, whose size is updated accordingly.
7. Provisioning of Routers 7. Provisioning of Routers
Before a router using this framework is able to generate ICVs or Before a router using this mechanism is able to generate ICVs or
validate messages, it MUST acquire the shared secret key(s) to be validate messages, it MUST acquire the shared secret key(s) to be
used by all routers that are to participate in the network. This used by all routers that are to participate in the network. This
specification does not define how a router acquires secret keys. specification does not define how a router acquires secret keys.
Once a router has acquired suitable key(s) it MAY be configured to Once a router has acquired suitable key(s) it MAY be configured to
use, or not use, this framework. Section 23.6 of [OLSRv2] provides a use, or not use, this mechanism. Section 23.6 of [OLSRv2] provides a
rationale based on [BCP107] why no key management is specified for rationale based on [BCP107] why no key management is specified for
OLSRv2. 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 mechanism for use with NHDP and
OLSRv2 that allows for alleviating several security threats. OLSRv2 that allows for mitigating several security threats.
9.1. Alleviated Attacks 9.1. Mitigated Attacks
This section briefly summarizes security threats that are alleviated This section briefly summarizes security threats that are mitigated
by the framework presented in this document. by the mechanism presented in this document.
9.1.1. Identity Spoofing 9.1.1. Identity Spoofing
As only routers possessing the selected shared secret key are able to As only routers possessing the selected shared secret key are able to
add a valid ICV TLV to a message, identity spoofing, where an add a valid ICV TLV to a message, identity spoofing, where an
attacker falsely claims an identity of a valid router, is countered. attacker falsely claims an identity of a valid router, is countered.
When using one or more shared keys for all routers in the MANET, it
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.
9.1.2. Link Spoofing 9.1.2. Link Spoofing
Link spoofing, where an attacker falsely represents the existence of Link spoofing, where an attacker falsely represents the existence of
a non-existent link, or otherwise misrepresents a link's state, is a non-existent link, or otherwise misrepresents a link's state, is
countered by the framework specified in this document, using the same countered by the mechanism specified in this document, using the same
argument as in Section 9.1.1. argument as in Section 9.1.1.
9.1.3. Replay Attack 9.1.3. Replay Attack
Replay attacks are partly countered by the framework specified in Replay attacks are partly countered by the mechanism specified in
this document, but this depends on synchronized clocks of all routers this document, but this depends on synchronized clocks of all routers
in the MANET. An attacker that records messages to replay them later in the MANET. An attacker that records messages to replay them later
can only do so in the selected time interval after the timestamp that can only do so in the selected time interval after the timestamp that
is contained in message. As an attacker cannot modify the content of is contained in message. As an attacker cannot modify the content of
this timestamp (as it is protected by the identity check value), an this timestamp (as it is protected by the identity check value), an
attacker cannot replay messages after this time. Within this time attacker cannot replay messages after this time. Within this time
interval it is still possible to perform replay attacks, however the interval it is still possible to perform replay attacks, however 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.
9.2. Limitations 9.2. Limitations
If no synchronized clocks are available in the MANET, replay attacks If no synchronized clocks are available in the MANET, replay attacks
cannot be countered by the framework provided by this document. An cannot be countered by the mechanism provided by this document. An
alternative version of the TIMESTAMP TLV defined in [RFC6622bis], alternative version of the TIMESTAMP TLV defined in [RFC6622bis],
with a monotonic sequence number, may have some partial value in this with a monotonic sequence number, may have some partial value in this
case, but will necessitate adding state to record observed message case, but will necessitate adding state to record observed message
sequence number information. sequence number information.
The framework provided by this document does not avoid or detect The mechanism provided by this document does not avoid or detect
security attacks by routers possessing the shared secret key that is security attacks by routers possessing the shared secret key that is
used to generate integrity check values for messages. used to generate integrity check values for messages.
This framework relies on an out-of-band protocol or mechanism for This mechanism relies on an out-of-band protocol or mechanism for
distributing the shared secret key(s) (and if an alternative distributing the shared secret key(s) (and if an alternative
integrity check value is used, any additional cryptographic integrity check value is used, any additional cryptographic
parameters). parameters).
This framework does not provide a key revocation mechanism. This mechanism does not provide a key management mechanism. Refer to
[OLSRv2], Section 23.6, for a detailed discussion why the automated
key management requirements specified in [BCP107] do not apply for
OLSRv2 and NHDP.
10. Acknowledgments 10. Acknowledgments
The authors would like to gratefully acknowledge the following The authors would like to gratefully acknowledge the following
people: Henning Rogge (Frauenhofer FKIE). people: Justin Dean (NRL), and Henning Rogge (Frauenhofer FKIE).
11. References 11. References
11.1. Normative References 11.1. 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
 End of changes. 37 change blocks. 
62 lines changed or deleted 69 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/