draft-ietf-manet-olsrv2-18.txt   draft-ietf-manet-olsrv2-19.txt 
Mobile Ad hoc Networking (MANET) T. Clausen Mobile Ad hoc Networking (MANET) T. Clausen
Internet-Draft LIX, Ecole Polytechnique Internet-Draft LIX, Ecole Polytechnique
Intended status: Standards Track C. Dearlove Intended status: Standards Track C. Dearlove
Expires: September 19, 2013 BAE Systems ATC Expires: September 24, 2013 BAE Systems ATC
P. Jacquet P. Jacquet
Alcatel-Lucent Bell Labs Alcatel-Lucent Bell Labs
U. Herberg U. Herberg
Fujitsu Laboratories of America Fujitsu Laboratories of America
March 18, 2013 March 23, 2013
The Optimized Link State Routing Protocol version 2 The Optimized Link State Routing Protocol version 2
draft-ietf-manet-olsrv2-18 draft-ietf-manet-olsrv2-19
Abstract Abstract
This specification describes version 2 of the Optimized Link State This specification describes version 2 of the Optimized Link State
Routing (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs). Routing (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 19, 2013. This Internet-Draft will expire on September 24, 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 5, line 8 skipping to change at page 5, line 8
24.4. Message TLV Types . . . . . . . . . . . . . . . . . . . . 91 24.4. Message TLV Types . . . . . . . . . . . . . . . . . . . . 91
24.5. Address Block TLV Types . . . . . . . . . . . . . . . . . 92 24.5. Address Block TLV Types . . . . . . . . . . . . . . . . . 92
24.6. NBR_ADDR_TYPE and MPR Values . . . . . . . . . . . . . . 95 24.6. NBR_ADDR_TYPE and MPR Values . . . . . . . . . . . . . . 95
25. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 95 25. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 95
26. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 96 26. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 96
27. References . . . . . . . . . . . . . . . . . . . . . . . . . 96 27. References . . . . . . . . . . . . . . . . . . . . . . . . . 96
27.1. Normative References . . . . . . . . . . . . . . . . . . 96 27.1. Normative References . . . . . . . . . . . . . . . . . . 96
27.2. Informative References . . . . . . . . . . . . . . . . . 97 27.2. Informative References . . . . . . . . . . . . . . . . . 97
Appendix A. Constraints . . . . . . . . . . . . . . . . . . . . 98 Appendix A. Constraints . . . . . . . . . . . . . . . . . . . . 98
Appendix B. Example Algorithm for Calculating MPRs . . . . . . . 102 Appendix B. Example Algorithm for Calculating MPRs . . . . . . . 102
B.1. Additional Notation . . . . . . . . . . . . . . . . . . . 103 B.1. Additional Notation . . . . . . . . . . . . . . . . . . . 102
B.2. MPR Selection Algorithm . . . . . . . . . . . . . . . . . 103 B.2. MPR Selection Algorithm . . . . . . . . . . . . . . . . . 103
Appendix C. Example Algorithm for Calculating the Routing Set . 104 Appendix C. Example Algorithm for Calculating the Routing Set . 104
C.1. Local Interfaces and Neighbors . . . . . . . . . . . . . 104 C.1. Local Interfaces and Neighbors . . . . . . . . . . . . . 104
C.2. Add Neighbor Routers . . . . . . . . . . . . . . . . . . 105 C.2. Add Neighbor Routers . . . . . . . . . . . . . . . . . . 105
C.3. Add Remote Routers . . . . . . . . . . . . . . . . . . . 105 C.3. Add Remote Routers . . . . . . . . . . . . . . . . . . . 105
C.4. Add Neighbor Addresses . . . . . . . . . . . . . . . . . 107 C.4. Add Neighbor Addresses . . . . . . . . . . . . . . . . . 107
C.5. Add Remote Routable Addresses . . . . . . . . . . . . . . 107 C.5. Add Remote Routable Addresses . . . . . . . . . . . . . . 107
C.6. Add Attached Networks . . . . . . . . . . . . . . . . . . 108 C.6. Add Attached Networks . . . . . . . . . . . . . . . . . . 108
C.7. Add 2-Hop Neighbors . . . . . . . . . . . . . . . . . . . 109 C.7. Add 2-Hop Neighbors . . . . . . . . . . . . . . . . . . . 108
Appendix D. TC Message Example . . . . . . . . . . . . . . . . . 109 Appendix D. TC Message Example . . . . . . . . . . . . . . . . . 109
Appendix E. Flow and Congestion Control . . . . . . . . . . . . 112 Appendix E. Flow and Congestion Control . . . . . . . . . . . . 111
1. Introduction 1. Introduction
The Optimized Link State Routing protocol version 2 (OLSRv2) is the The Optimized Link State Routing protocol version 2 (OLSRv2) is the
successor to OLSR (version 1) as published in [RFC3626]. Compared to successor to OLSR (version 1) as published in [RFC3626]. Compared to
[RFC3626], OLSRv2 retains the same basic mechanisms and algorithms, [RFC3626], OLSRv2 retains the same basic mechanisms and algorithms,
enhanced by the ability to use a link metric other than hop count in enhanced by the ability to use a link metric other than hop count in
the selection of shortest routes. OLSRv2 also uses a more flexible the selection of shortest routes. OLSRv2 also uses a more flexible
and efficient signaling framework, and includes some simplification and efficient signaling framework, and includes some simplification
of the messages being exchanged. of the messages being exchanged.
skipping to change at page 83, line 33 skipping to change at page 83, line 33
appropriate TLVs, or of network addresses associated with new appropriate TLVs, or of network addresses associated with new
TLVs, access to such information after appropriate updates have TLVs, access to such information after appropriate updates have
been recorded in the Information Bases in this protocol. been recorded in the Information Bases in this protocol.
o Through requesting that a message be generated at a specific time. o Through requesting that a message be generated at a specific time.
In that case, message generation MUST still respect the In that case, message generation MUST still respect the
constraints in [RFC6130] and Section 5.4.3. constraints in [RFC6130] and Section 5.4.3.
23. Security Considerations 23. Security Considerations
As a proactive routing protocol, this protocol is a potential target As a proactive routing protocol, OLSRv2 is a potential target for
for various attacks. This section presents the envisioned security various attacks. This section presents the envisioned security
architecture for OLSRv2, and gives guidelines on how to provide architecture for OLSRv2, and gives guidelines on how to provide
integrity, confidentiality, and integration into external routing integrity, confidentiality, and integration into external routing
domains. domains. Separately specified mandatory security mechanisms are
summarised, and some observations on key management are given.
23.1. Security Architecture 23.1. Security Architecture
OLSRv2 integrates into the architecture specified in Appendix A of OLSRv2 integrates into the architecture specified in Appendix A of
[RFC5444], in [RFC5498], and in Section 16 of [RFC6130], the latter [RFC5444], in [RFC5498], and in Section 16 of [RFC6130], the latter
by using and extending its messages and Information Bases. by using and extending its messages and Information Bases.
As part of this architecture, OLSRv2, and [RFC6130], recognize that As part of this architecture, OLSRv2, and [RFC6130], recognize that
there may be external reasons for rejecting messages that would be there may be external reasons for rejecting messages that would be
considered "badly formed" or "insecure", e.g., if a digital signature considered "badly formed" or "insecure", e.g., if an Integrity Check
included in a message by an external mechanism cannot be verified. Value (ICV) included in a message by an external mechanism cannot be
This architecture allows options as to whether and how to implement verified. This architecture allows options as to whether and how to
security features, reflecting the situation that MANET routing implement security features, reflecting the situation that MANET
protocol deployment domains have varying security requirements, routing protocol deployment domains have varying security
ranging from "practically unbreakable" to "virtually none". This requirements, ranging from "practically unbreakable" to "virtually
approach allows MANET routing protocol specifications to remain none". This approach allows MANET routing protocol specifications to
generic, with extensions to them, and/or extensions to the remain generic, with extensions to them, and/or extensions to the
multiplexing and demultiplexing process described in Appendix A of multiplexing and demultiplexing process described in Appendix A of
[RFC5444], providing security mechanisms appropriate to a given [RFC5444], providing security mechanisms appropriate to a given
deployment domain. deployment domain.
The following sections provide guidelines how to provide integrity, The following sections provide guidelines how to provide integrity,
confidentiality, and integration with external routing domains in confidentiality, and integration with external routing domains in
such extensions. such extensions.
23.2. Integrity 23.2. Integrity
Each router injects topological information into the network by Each router injects topological information into the network by
transmitting HELLO messages and, for some routers, also TC messages. transmitting HELLO messages and, for some routers, also TC messages.
If some routers for some reason, malice or malfunction, inject If some routers for some reason, malice or malfunction, inject
invalid control traffic, network integrity may be compromised. invalid control traffic, network integrity may be compromised.
Therefore, message, or packet, authentication is recommended. Therefore, message, or packet, authentication is strongly advised.
Different such situations may occur, for example: Different such situations may occur, for example:
1. A router generates TC messages, advertising links to non-neighbor 1. A router generates TC messages, advertising links to non-neighbor
routers; routers;
2. A router generates TC messages, pretending to be another router; 2. A router generates TC messages, pretending to be another router;
3. A router generates HELLO messages, advertising non-neighbor 3. A router generates HELLO messages, advertising non-neighbor
routers; routers;
skipping to change at page 84, line 51 skipping to change at page 85, line 4
8. A router forwards broadcast control messages unaltered, but does 8. A router forwards broadcast control messages unaltered, but does
not forward unicast data traffic; not forward unicast data traffic;
9. A router "replays" previously recorded control traffic from 9. A router "replays" previously recorded control traffic from
another router. another router.
Authentication of the originator router for control messages (for Authentication of the originator router for control messages (for
situations 2, 4 and 5), and of the individual links announced in the situations 2, 4 and 5), and of the individual links announced in the
control messages (for situations 1 and 3), may be used as a control messages (for situations 1 and 3), may be used as a
countermeasure. However to prevent routers from repeating old (and countermeasure. However to prevent routers from repeating old (and
correctly authenticated) information (situation 9) temporal correctly authenticated) information (situation 9) additional
information (a timestamp) is required, allowing a router to information is required (e.g., a timestamp or sequence number),
positively identify such replayed messages. allowing a router to positively identify such replayed messages.
In general, digital signatures and other required security In general, ICVs (e.g., digital signatures) and other required
information may be transmitted within the HELLO and TC messages, or security information can be transmitted within the HELLO and TC
within a packet header, using the TLV mechanism. Either option messages, or within a packet header, using the TLV mechanism. Either
permits "secured" and "unsecured" routers to coexist in the same option permits different levels of protection to coexist in the same
network, if desired. network, if desired.
An important consideration is that all control messages (HELLO An important consideration is that all control messages (HELLO
messages and TC messages) are transmitted to all routers in the 1-hop messages and TC messages) are transmitted to all routers in the 1-hop
neighborhood and some control messages (TC messages) are flooded to neighborhood and some control messages (TC messages) are flooded to
all routers in the network. This is done in a packet that is all routers in the network. This is done in a packet that is
transmitted to all routers in the 1-hop neighborhood, the current set transmitted to all routers in the 1-hop neighborhood, the current set
of which may not be known. Thus, a control message, or packet, used of which may not be known. Thus, a control message, or packet, used
by this protocol is always contained in a transmission destined for by this protocol is always contained in a transmission destined for
multiple destinations, and it is important that the authentication multiple destinations, and it is important that the authentication
skipping to change at page 85, line 32 skipping to change at page 85, line 33
authenticity of a message or packet. authenticity of a message or packet.
[RFC6622bis] specifies a common exchange format for cryptographic [RFC6622bis] specifies a common exchange format for cryptographic
information in the form of Packet TLVs, Message TLVs, and Address information in the form of Packet TLVs, Message TLVs, and Address
Block TLVs, as specified in [RFC5444]. These may be used (and Block TLVs, as specified in [RFC5444]. These may be used (and
shared) among MANET routing protocol security extensions. In shared) among MANET routing protocol security extensions. In
particular, [RFC6622bis] specifies the format of TLVs for containing particular, [RFC6622bis] specifies the format of TLVs for containing
Integrity Check Values (ICVs), i.e., signatures, for providing Integrity Check Values (ICVs), i.e., signatures, for providing
integrity, as well as TLVs for containing temporal information for integrity, as well as TLVs for containing temporal information for
preventing replay attacks. [RFC6622bis] specifies registries for preventing replay attacks. [RFC6622bis] specifies registries for
using different ciphers and formats of temporal information. Failure using different ciphers and formats of temporal information. When
to verify an ICV included can be used as a reason to reject an using ICV TLVs in an OLSRv2 deployment, failure to verify an ICV
incoming message or packet as "invalid", according to Section 12.1 of included mandates to reject an incoming message or packet as
[RFC6130], and according to Section 16.3.1 of this specification, "invalid", according to Section 12.1 of [RFC6130], and according to
when using the multiplexing and demultiplexing process described in Section 16.3.1 of this specification, when using the multiplexing and
Appendix A of [RFC5444]. demultiplexing process described in Appendix A of [RFC5444].
Any security extension that uses [RFC6622bis] must specify how to [RFC6622bis] specifies how to insert IVCs into generated messages,
insert IVCs in generated messages, how to verify incoming messages, how to verify incoming messages, and to reject "insecure" messages
and to reject "insecure" messages (i.e., messages without an ICV or (i.e., messages without an ICV or with an ICV that cannot be
with an ICV that cannot be verified) when operating in a secure mode. verified). Different MANET deployments may, as a result of the
Different MANET deployments may, as a result of their purpose for purpose for which they are used and the possibility and nature of
which they are used and the possibility and nature of their their configuration, require different ICV algorithms and timestamps,
configuration, require different ICV algorithms and timestamps, and or multiple keys, and thus a security extension may use any of the
thus a security extension may use any of the different options different options provided in [RFC6622bis].
provided in [RFC6622bis].
23.3. Confidentiality 23.3. Confidentiality
OLSRv2 periodically MPR floods topological information to all routers OLSRv2 periodically MPR floods topological information to all routers
in the network. Hence, if used in an unprotected network, in in the network. Hence, if used in an unprotected network, in
particular an unprotected wireless network, the network topology is particular an unprotected wireless network, the network topology is
revealed to anyone who successfully listens to the control messages. revealed to anyone who successfully listens to the control messages.
This information may serve an attacker to acquire details about the This information may serve an attacker to acquire details about the
topology, and therefore to initiate more effective attacks against topology, and therefore to initiate more effective attacks against
routers in the routing domain e.g., by spoofing addresses of routers routers in the routing domain e.g., by spoofing addresses of routers
skipping to change at page 87, line 8 skipping to change at page 87, line 8
A recommended way of extending connectivity from an external routing A recommended way of extending connectivity from an external routing
domain to this routing domain, which is routed using this protocol, domain to this routing domain, which is routed using this protocol,
is to assign an IP prefix (under the authority of the routers/ is to assign an IP prefix (under the authority of the routers/
gateways connecting this routing domain with the external routing gateways connecting this routing domain with the external routing
domain) exclusively to this routing domain, and to configure the domain) exclusively to this routing domain, and to configure the
gateways to advertise routes for that IP prefix into the external gateways to advertise routes for that IP prefix into the external
routing domain. routing domain.
23.5. Mandatory Security Mechanisms 23.5. Mandatory Security Mechanisms
A conformant implementation of OLSRv2 MUST, at a minimum, implement A conformant implementation of OLSRv2 MUST, at minimum, implement the
the security mechanisms specified in [OLSRv2-integrity], providing security mechanisms specified in [OLSRv2-integrity], providing
integrity and replay protection of OLSRv2 control messages, including integrity and replay protection of OLSRv2 control messages, including
of HELLO messages specified by [RFC6130] that are used by OLSRv2, by of HELLO messages specified by [RFC6130] and used by OLSRv2, by
including an Integrity Check Value (ICV) TLV and a timestamp TLV. inclusion of a timestamp TLV and an Integrity Check Value (ICV) TLV.
The ICV TLV uses a SHA-256 based HMAC and a single shared secret key. This ICV TLV uses a SHA-256 based HMAC and one or more manually
The timestamp TLV is based on POSIX time, assuming router time managed shared secret keys. The timestamp TLV is based on POSIX
synchronization. time, assuming router time synchronization.
The baseline use case, for which this security mechanism provides The baseline use case, for which this security mechanism provides
adequate integrity protection without rekeying, is for short-lived adequate integrity protection without rekeying, is for short-lived
(for example up to a couple of months) OLSRv2 deployments. (for example up to a couple of months) OLSRv2 deployments.
Any deployment of OLSRv2 SHOULD use an appropriate security Any deployment of OLSRv2 SHOULD use the security mechanism specified
mechanism, possibly different from the one described in in [OLSRv2-integrity], but MAY use another mechanism if more
[OLSRv2-integrity]. For example, for longer-term OLSRv2 deployments, appropriate in an OLSRv2 deployment. For example, for longer-term
alternative security mechanisms (e.g., including re-keying) SHOULD be OLSRv2 deployments, alternative security mechanisms (e.g., re-keying)
considered. SHOULD be considered.
23.6. Key Management 23.6. Key Management
This specification does not mandate automatic key management (AKM) as This specification, including [OLSRv2-integrity], does not mandate
part of the security architecture for OLSRv2. While certain use automatic key management (AKM) as part of the security architecture
cases for OLSRv2 may lend themselves to AKM, the baseline assumption for OLSRv2. While some use cases for OLSRv2 may require AKM, the
is that many use cases do not, for the reasons detailed below. baseline assumption is that many use cases do not, for the reasons
detailed below.
Bootstrapping a key is hard in a radio network, where it is - in Bootstrapping a key is hard in a radio network, where it is - in
general - not possible to determine from where a received signal was general - not possible to determine from where a received signal was
transmitted, or if two transmissions come from the same or from transmitted, or if two transmissions come from the same or from
different sources. different sources.
A widespread use of radio networks, mobile phone networks, works A widespread use of radio networks, mobile phone networks, works
under the assumptions that (i) secret information is embedded in under the assumptions that (i) secret information is embedded in
mobile phones at manufacture, and (ii) a centralized database of this mobile phones at manufacture, and (ii) a centralized database of this
is accessible during the network lifetime. is accessible during the network lifetime.
However, as a primary use case of a MANET is to provide connectivity As a primary use case of a MANET is to provide connectivity without
absent centralized entities, and with minimal management, a solution centralized entities, and with minimal management, a solution such as
such as that used in a mobile phone network is not feasible. In many described in the previous paragraph is not feasible. In many
instances, a cryptographic authority may not be present in the MANET instances, a cryptographic authority may not be present in the MANET
at all, since such a cryptographic authority would be too vulnerable. at all, since such a cryptographic authority would be too vulnerable.
Due to the potentially dynamic topology of a MANET, a cryptographic Due to the potentially dynamic topology of a MANET, a cryptographic
authority may also become unreachable (to some or all of the MANET authority may also become unreachable (to some or all of the MANET
routers) without prior warning. routers) without prior warning.
[BCP107] provides guidelines for cryptographic key management. [BCP107] provides guidelines for cryptographic key management.
Specifically, Section 2.1 describes requirements for when AKM is Specifically, Section 2.1 sets forth requirements for when AKM is
required, and Section 2.2 describes conditions under which manual key required, and Section 2.2 sets forth conditions under which manual
management is acceptable. key management is acceptable.
Section 2.1 of [BCP107] stipulates that "Automated key management Section 2.1 of [BCP107] stipulates that "Automated key management
MUST be used if any of [a set of given] conditions hold". These MUST be used if any of [a set of given] conditions hold". These
conditions are listed below, for each of which arguments are provided conditions are listed below, for each of which arguments are provided
as to their applicability for the baseline use case of OLSRv2. as to their applicability for the baseline use case of OLSRv2.
A party will have to manage n^2 static keys, where n may become A party will have to manage n^2 static keys, where n may become
large. large.
The baseline use case of OLSRv2 uses only one key in the whole The baseline use case of OLSRv2 uses only one or a small set of
MANET. manually managed shared secrets in the whole MANET.
Any stream cipher (such as RC4 [TK], AES-CTR [NIST], or AES-CCM Any stream cipher (such as RC4 [TK], AES-CTR [NIST], or AES-CCM
[WHF]) is used. [WHF]) is used.
A stream cipher is not envisioned to be used for generating ICVs A stream cipher is not envisioned for use to generate ICVs for
for OLSRv2 control messages. OLSRv2 control messages.
An initialization vector (IV) might be reused, especially an implicit An initialization vector (IV) might be reused, especially an implicit
IV. Note that random or pseudo-random explicit IVs are not a problem IV. Note that random or pseudo-random explicit IVs are not a problem
unless the probability of repetition is high. unless the probability of repetition is high.
An IV is not envisioned to be used for generating ICVs for OLSRv2 An IV is not envisioned for use to generate ICVs for OLSRv2
control messages. control messages.
Large amounts of data might need to be encrypted in a short time, Large amounts of data might need to be encrypted in a short time,
causing frequent change of the short-term session key. causing frequent change of the short-term session key.
Integrity Check Values (ICVs) are required only for OLSRv2 control Integrity Check Values (ICVs) are required only for OLSRv2 control
messages, which are low-volume messages. messages, which are low-volume messages.
Long-term session keys are used by more than two parties. Multicast Long-term session keys are used by more than two parties. Multicast
is a necessary exception, but multicast key management standards are is a necessary exception, but multicast key management standards are
skipping to change at page 89, line 24 skipping to change at page 89, line 24
a reasonable approach in any of [a given set of] situations". These a reasonable approach in any of [a given set of] situations". These
situation are listed below, for each of which arguments are provided situation are listed below, for each of which arguments are provided
as to their applicability for the baseline use case of OLSRv2. as to their applicability for the baseline use case of OLSRv2.
The environment has very limited available bandwidth or very high The environment has very limited available bandwidth or very high
round-trip times. Public key systems tend to require long messages round-trip times. Public key systems tend to require long messages
and lots of computation; symmetric key alternatives, such as and lots of computation; symmetric key alternatives, such as
Kerberos, often require several round trips and interaction with Kerberos, often require several round trips and interaction with
third parties. third parties.
Bandwidth is limited, both by being a radio environment, and by As previously noted, there may not be the required infrastructure
the need for any signaling to consume a minimal proportion (cryptographic authority) present (or, if present, may not be
thereof. A system such as Kerberos would therefore be reachable) in the MANET. Bandwidth in a MANET is commonly
inappropriate - and as previously noted, there may not be the limited, both by being a radio environment, and by the need for
required infrastructure (cryptographic authority) present - or, if any signaling to consume a minimal proportion thereof, and round
present, reachable - in the MANET. trip times may also be significant.
The information being protected has low value. The information being protected has low value.
This depends on the OLSRv2 use case, but the information being This depends on the OLSRv2 use case, but the information being
protected is OLSRv2 control traffic, which is of moderate value. protected is OLSRv2 control traffic, which is of at least moderate
value, thus this case does not apply.
The total volume of traffic over the entire lifetime of the long-term The total volume of traffic over the entire lifetime of the long-term
session key will be very low. session key will be very low.
Integrity Check Values (ICVs) are required only for OLSRv2 control Integrity Check Values (ICVs) are required only for OLSRv2 control
messages, which are low-volume messages. messages, which are low-volume messages.
The scale of each deployment is very limited The scale of each deployment is very limited
A typical use case for OLSRv2 may involve only tens of devices - A typical use case for OLSRv2 may involve only tens of devices -
skipping to change at page 97, line 16 skipping to change at page 97, line 16
Value Time in Mobile Ad Hoc Networks (MANETs)", Value Time in Mobile Ad Hoc Networks (MANETs)",
RFC 5497, March 2009. RFC 5497, March 2009.
[RFC5498] Chakeres, I., "IANA Allocations for Mobile Ad Hoc [RFC5498] Chakeres, I., "IANA Allocations for Mobile Ad Hoc
Network (MANET) Protocols", RFC 5498, March 2009. Network (MANET) Protocols", RFC 5498, March 2009.
[RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile [RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile
Ad Hoc Network (MANET) Neighborhood Discovery Ad Hoc Network (MANET) Neighborhood Discovery
Protocol (NHDP)", RFC 6130, April 2011. Protocol (NHDP)", RFC 6130, April 2011.
[RFC6622bis] Herberg, U., Clausen, T., and C. Dearlove,
"Integrity Check Value and Timestamp TLV
Definitions for Mobile Ad Hoc Networks (MANETs)",
work in progress draft-ietf-manet-rfc6622-bis-01,
March 2013.
[OLSRv2-integrity] Herberg, U., Dearlove, C., and T. Clausen, [OLSRv2-integrity] Herberg, U., Dearlove, C., and T. Clausen,
"Integrity Protection for Control Messages in "Integrity Protection for Control Messages in
NHDP and OLSRv2", Internet NHDP and OLSRv2", work in
Draft draft-herberg-manet-nhdp-olsrv2-sec-02, progress draft-ietf-manet-nhdp-olsrv2-sec-01,
March 2013. March 2013.
27.2. Informative References 27.2. Informative References
[RFC2501] Macker, J. and S. Corson, "Mobile Ad hoc [RFC2501] Macker, J. and S. Corson, "Mobile Ad hoc
Networking (MANET): Routing Protocol Performance Networking (MANET): Routing Protocol Performance
Issues and Evaluation Considerations", RFC 2501, Issues and Evaluation Considerations", RFC 2501,
January 1999. January 1999.
[RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link
State Routing Protocol", RFC 3626, October 2003. State Routing Protocol", RFC 3626, October 2003.
[RFC6622bis] Herberg, U., Clausen, T., and C. Dearlove,
"Integrity Check Value and Timestamp TLV
Definitions for Mobile Ad Hoc Networks (MANETs)",
Internet
Draft draft-herberg-manet-rfc6622-bis-02,
March 2013.
[HIPERLAN] ETSI, "ETSI STC-RES10 Committee. Radio equipment [HIPERLAN] ETSI, "ETSI STC-RES10 Committee. Radio equipment
and systems: HIPERLAN type 1, functional and systems: HIPERLAN type 1, functional
specifications ETS 300-652", June 1996. specifications ETS 300-652", June 1996.
[HIPERLAN2] Jacquet, P., Minet, P., Muhlethaler, P., and N. [HIPERLAN2] Jacquet, P., Minet, P., Muhlethaler, P., and N.
Rivierre, "Increasing reliability in cable free Rivierre, "Increasing reliability in cable free
radio LANs: Low level forwarding in HIPERLAN.", radio LANs: Low level forwarding in HIPERLAN.",
1996. 1996.
[MPR] Qayyum, A., Viennot, L., and A. Laouiti, [MPR] Qayyum, A., Viennot, L., and A. Laouiti,
skipping to change at page 113, line 15 skipping to change at page 113, line 15
Authors' Addresses Authors' Addresses
Thomas Heide Clausen Thomas Heide Clausen
LIX, Ecole Polytechnique LIX, Ecole Polytechnique
Phone: +33 6 6058 9349 Phone: +33 6 6058 9349
EMail: T.Clausen@computer.org EMail: T.Clausen@computer.org
URI: http://www.ThomasClausen.org/ URI: http://www.ThomasClausen.org/
Christopher Dearlove Christopher Dearlove
BAE Systems ATC BAE Systems Advanced Technology Centre
West Hanningfield Road
Great Baddow, Chelmsford
United Kingdom
Phone: +44 1245 242194 Phone: +44 1245 242194
EMail: chris.dearlove@baesystems.com EMail: chris.dearlove@baesystems.com
URI: http://www.baesystems.com/ URI: http://www.baesystems.com/
Philippe Jacquet Philippe Jacquet
Alcatel-Lucent Bell Labs Alcatel-Lucent Bell Labs
Phone: +33 6 7337 1880 Phone: +33 6 7337 1880
EMail: philippe.jacquet@alcatel-lucent.com EMail: philippe.jacquet@alcatel-lucent.com
Ulrich Herberg Ulrich Herberg
Fujitsu Laboratories of America Fujitsu Laboratories of America
1240 E. Arques Ave. 1240 E. Arques Ave.
Sunnyvale, CA, 94085 Sunnyvale, CA 94085
USA USA
EMail: ulrich@herberg.name EMail: ulrich@herberg.name
URI: http://www.herberg.name/ URI: http://www.herberg.name/
 End of changes. 31 change blocks. 
86 lines changed or deleted 90 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/