draft-ietf-manet-nhdp-olsrv2-sec-02.txt   draft-ietf-manet-nhdp-olsrv2-sec-03.txt 
Mobile Ad hoc Networking (MANET) U. Herberg Mobile Ad hoc Networking (MANET) U. Herberg
Internet-Draft Fujitsu Laboratories of America Internet-Draft Fujitsu Laboratories of America
Updates: RFC6130 C. Dearlove Updates: 6130, xxxx (if approved) C. Dearlove
(if approved) BAE Systems ATC Intended status: Standards Track BAE Systems ATC
Intended status: Standards Track T. Clausen Expires: January 3, 2014 T. Clausen
Expires: October 17, 2013 LIX, Ecole Polytechnique LIX, Ecole Polytechnique
April 15, 2013 July 2, 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-02 draft-ietf-manet-nhdp-olsrv2-sec-03
Abstract Abstract
This document specifies integrity and replay protection for required This document specifies integrity and replay protection for the MANET
implementation in the MANET Neighborhood Discovery Protocol (NHDP) Neighborhood Discovery Protocol (NHDP) and the Optimized Link State
and the Optimized Link State Routing Protocol version 2 (OLSRv2). Routing Protocol version 2 (OLSRv2). This protection is achieved by
This document specifies how an included integrity check value (ICV) using an HMAC-SHA-256 Integrity Check Value (ICV) TLV and a timestamp
and a timestamp TLV, defined in RFC6622bis, are used by NHDP and TLV based on POSIX time.
OLSRv2 for countering a number of security threats. The ICV TLV uses
a SHA-256 based HMAC and one or more shared secret keys. The The mechanism in this specification can also be used for other
timestamp TLV is based on POSIX time, and assumes that the clocks in protocols that use the generalized packet/message format described in
all routers in the network can be synchronized with sufficient RFC 5444.
precision. The mechanism in this specification can also be used for
other MANET protocols using RFC5444. This document updates RFC 6130 and RFC xxxx by mandating the
implementation of this integrity and replay protection in NHDP and
OLSRv2.
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.
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 October 17, 2013. This Internet-Draft will expire on January 3, 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 26 skipping to change at page 2, line 27
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 4 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 4
4. Protocol Overview and Functioning . . . . . . . . . . . . . . 6 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 6
5. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Message Generation and Processing . . . . . . . . . . . . . . 8 6. Message Generation and Processing . . . . . . . . . . . . . . 8
6.1. Message Content . . . . . . . . . . . . . . . . . . . . . 8 6.1. Message Content . . . . . . . . . . . . . . . . . . . . . 8
6.2. Message Generation . . . . . . . . . . . . . . . . . . . . 9 6.2. Message Generation . . . . . . . . . . . . . . . . . . . . 9
6.3. Message Processing . . . . . . . . . . . . . . . . . . . . 10 6.3. Message Processing . . . . . . . . . . . . . . . . . . . . 10
6.3.1. Validating a Message Based on Timestamp . . . . . . . 10 6.3.1. Validating a Message Based on Timestamp . . . . . . . 11
6.3.2. Validating a Message Based on Integrity Check . . . . 11 6.3.2. Validating a Message Based on Integrity Check . . . . 11
7. Provisioning of Routers . . . . . . . . . . . . . . . . . . . 11 7. Provisioning of Routers . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9.1. Alleviated Attacks . . . . . . . . . . . . . . . . . . . . 12 9.1. Alleviated Attacks . . . . . . . . . . . . . . . . . . . . 12
9.1.1. Identity Spoofing . . . . . . . . . . . . . . . . . . 12 9.1.1. Identity Spoofing . . . . . . . . . . . . . . . . . . 12
9.1.2. Link Spoofing . . . . . . . . . . . . . . . . . . . . 12 9.1.2. Link Spoofing . . . . . . . . . . . . . . . . . . . . 12
9.1.3. Replay Attack . . . . . . . . . . . . . . . . . . . . 12 9.1.3. Replay Attack . . . . . . . . . . . . . . . . . . . . 12
9.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 12 9.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
11. Normative References . . . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
This specification defines a framework of security mechanisms that [RFC Editor note: Please replace "xxxx" throughout this document with
must be included in conforming implementations of the Neighborhood the RFC number assigned to [OLSRv2], and remove this note.]
Discovery Protocol (NHDP) [RFC6130] and the Optimized Link State
Routing Protocol version 2 (OLSRv2) [OLSRv2] for Mobile Ad hoc This specification updates [RFC6130] and [OLSRv2] by defining a
NETworks (MANETs). A deployment of these protocols may choose to framework of security mechanisms (for integrity and replay
employ alternative(s) to these mechanisms, in particular it may protection) that must be included in conforming implementations of
choose to protect packets rather than messages, it may choose to use those protocols (the Neighborhood Discovery Protocol, NHDP, and the
an alternative integrity check value (ICV) with preferred properties, Optimized Link State Routing Protocol version 2, OLSRv2). A
and/or it may use an alternative timestamp. A deployment may choose deployment of these protocols may choose to employ alternative(s) to
to use no such security mechanisms, but this is not recommended. 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 The mechanisms specified are the use of an ICV for protection of the
protocols' control messages, and the use of timestamps in those protocols' control messages, and the use of timestamps in those
messages to prevent replay attacks. Both use the TLV mechanism messages to prevent replay attacks. Both use the TLV mechanism
specified in [RFC5444] to add this information to the messages. specified in [RFC5444] to add this information to the messages.
These ICV and timestamp TLVs are defined in [RFC6622bis]. Different These ICV and TIMESTAMP TLVs are defined in [RFC6622bis]. Different
ICV TLVs are used for HELLO messages in NHDP and TC messages in ICV TLVs are used for HELLO messages in NHDP and TC messages in
OLSRv2, the former also protecting the source address of the IP OLSRv2, the former also protecting the source address of the IP
datagram that contains the HELLO message. This is because 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 datagram source address is used by NHDP to determine the address of a
neighbor interface, and is not necessarily otherwise contained in the neighbor interface, and is not necessarily otherwise contained in the
HELLO message, while OLSRv2's TC message is forwarded in a new HELLO message, while OLSRv2's TC message is forwarded in a new
packet, and thus has no single IP datagram source address. packet, and thus has no single IP datagram source address.
The mechanism specified in this document exists between NHDP's and The mechanism specified in this document is placed in the packet/
OLSRv2's message processing/generation and the [RFC5444] packet message processing flow as indicated in Figure 1. It exists between
parsing/generation, as illustrated in Figure 1. the packet parsing/generation function of [RFC5444], and the message
processing/generation function of NHDP and OLSRv2.
| | | |
Incoming | /|\ Outgoing Incoming | /|\ Outgoing
packet \|/ | packet packet \|/ | packet
| | | |
+--------------------------------+ +--------------------------------+
| | | |
| RFC5444 packet | | RFC5444 packet |
| parsing / generation | | parsing / generation |
| | | |
skipping to change at page 4, line 44 skipping to change at page 4, line 44
Figure 1: Relationship with RFC5444 and NHDP/OLSRv2 Figure 1: Relationship with RFC5444 and NHDP/OLSRv2
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
Additionally, this document uses the terminology of [RFC5444], Additionally, this document uses the terminology and notation of
[RFC6130], [OLSRv2], and [RFC6622bis]. [RFC5444], [RFC6130], [OLSRv2], and [RFC6622bis].
3. Applicability Statement 3. Applicability Statement
[RFC6130] and [OLSRv2] enable extensions to recognize additional [RFC6130] and [OLSRv2] enable extensions to recognize additional
reasons for rejecting a message as "badly formed and therefore reasons for rejecting a message as "badly formed and therefore
invalid for processing", and mention security (integrity protection) invalid for processing", and mention security (integrity protection)
as an explicit example. This document specifies a framework that as an explicit example. This document specifies a framework that
provides this functionality. provides this functionality.
Implementations of [RFC6130] and [OLSRv2] MUST include this Implementations of [RFC6130] and [OLSRv2] MUST include this
framework, and deployments of [RFC6130] and [OLSRv2] SHOULD use this framework, and deployments of [RFC6130] and [OLSRv2] SHOULD use this
framework, except for when a different security mechanism is more framework, except for when a different security mechanism is more
appropriate. appropriate.
The applicability of this framework is determined by its The applicability of this framework is determined by its
characteristics, which are that it: characteristics, which are that it:
o Specifies a security framework that is required to be included in o Specifies a security framework that is required to be included in
conforming implementations of [RFC6130] and [OLSRv2]. conforming implementations of [RFC6130] and [OLSRv2].
o Specifies an association of ICVs with messages, and for using o Specifies an association of ICVs with protocol messages, and
missing or invalid ICVs as such an additional reason for rejecting specifies how to use a missing or invalid ICV as an reason to
a message as "badly formed and therefore invalid for processing". reject a message as "badly formed and therefore invalid for
processing".
o Specifies the implementation of an ICV Message TLV, defined in o Specifies the implementation of an ICV Message TLV, defined in
[RFC6622bis], using a SHA-256 based HMAC applied to the [RFC6622bis], using a SHA-256 based HMAC applied to the
appropriate message contents (and for HELLO messages also appropriate message contents (and for HELLO messages also
including the IP datagram source address). Deployments of including the IP datagram source address). Deployments of
[RFC6130] and [OLSRv2] using this framework should use an HMAC/ [RFC6130] and [OLSRv2] using this framework SHOULD use an HMAC/
SHA-256 ICV TLV, but may use different algorithms if more SHA-256 ICV TLV, but MAY use different algorithms if more
appropriate in a deployment. An implementation may also use more appropriate in a deployment. An implementation MAY also use more
than one ICV TLV in a message, as long as they each use a than one ICV TLV in a message, as long as they each use a
different algorithm to calculate the ICV. different algorithm to calculate the ICV.
o Specifies the implementation of a TIMESTAMP TLV, defined in o Specifies the implementation of a TIMESTAMP Message TLV, defined
[RFC6622bis], to provide message replay protection. Deployments in [RFC6622bis], to provide message replay protection.
of [RFC6130] and [OLSRv2] using this framework SHOULD use a POSIX Deployments of [RFC6130] and [OLSRv2] using this framework SHOULD
time based timestamp, if the clocks in all routers in the network use a POSIX time based timestamp, if the clocks in all routers in
can be synchronized with sufficient precision. the network can be synchronized with sufficient precision.
o Assumes that a router that is able to generate correct integrity o Assumes that a router that is able to generate correct integrity
check values is considered trusted. check values is considered trusted.
This framework does not: This framework does not:
o Specify which key identifiers are to be used in a MANET in which o Specify which key identifiers are to be used in a MANET in which
the routers share more than one secret key. (Such keys 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].)
skipping to change at page 7, line 21 skipping to change at page 7, line 21
When a router generates a message on a MANET interface, this When a router generates a message on a MANET interface, this
framework: framework:
o Specifies how to calculate an integrity check value for the o Specifies how to calculate an integrity check value for the
message. message.
o Specifies how to include that integrity check value using an ICV o Specifies how to include that integrity check value using an ICV
Message TLV. Message TLV.
[RFC6130] and [OLSRv2] allow for rejecting incoming messages prior to [RFC6130] and [OLSRv2] allow for rejecting incoming messages prior to
processing by NHDP or OLSRv2. This framework specifies that a processing by NHDP or OLSRv2. This framework, when used, specifies
message MUST be rejected if the ICV Message TLV is absent, or its that a message MUST be rejected if the ICV Message TLV is absent, or
value cannot be verified. 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 framework, 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 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:
o MAX_HELLO_TIMESTAMP_DIFF - The maximum age that a HELLO message to o MAX_HELLO_TIMESTAMP_DIFF - The maximum age that a HELLO message to
be validated may have. If the current POSIX time of the router be validated may have. If the current POSIX time of the router
validating the HELLO message, minus the timestamp indicated in the validating the HELLO message, minus the timestamp indicated in the
skipping to change at page 7, line 48 skipping to change at page 8, line 7
o MAX_TC_TIMESTAMP_DIFF - The maximum age that a TC message to be 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 validated may have. If the current POSIX time of the router
validating the TC message, minus the timestamp indicated in the validating the TC message, minus the timestamp indicated in the
TIMESTAMP TLV of the TC message, is greater than TIMESTAMP TLV of the TC message, is greater than
MAX_TC_TIMESTAMP_DIFF, the TC message MUST be silently discarded. MAX_TC_TIMESTAMP_DIFF, the TC message MUST be silently discarded.
The following constraints apply to these parameters: The following constraints apply to these parameters:
o MAX_HELLO_TIMESTAMP_DIFF > 0 o MAX_HELLO_TIMESTAMP_DIFF > 0
o MAX_HELLO_TIMESTAMP_DIFF < REFRESH_INTERVAL
o MAX_TC_TIMESTAMP_DIFF > 0 o MAX_TC_TIMESTAMP_DIFF > 0
o MAX_TC_TIMESTAMP_DIFF < T_HOLD_TIME These bounds are however 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 [OLSRv2] 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 second and fourth of those constraints assume ideal time The above constraints assume ideal time synchronization of the clock
synchronization of the clocks in all routers in the network. These in all routers in the network. The parameters
bounds MAY be relaxed to allow for expected timing differences MAX_HELLO_TIMESTAMP_DIFF and MAX_TC_TIMESTAMP_DIFF (and any
between routers (between neighboring routers for constraints on them) MAY be increased to allow for expected timing
MAX_HELLO_TIMESTAMP_DIFF). However it should also be noted that, in differences between routers (between neighboring routers for
the ideal case, the parameters SHOULD be significantly less than MAX_HELLO_TIMESTAMP_DIFF, allowing for greater separation, but
those bounds. 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.
6. Message Generation and Processing 6. Message Generation and Processing
This section specifies how messages are generated and processed by This section specifies how messages are generated and processed by
[RFC6130] and [OLSRv2] when using this framework. [RFC6130] and [OLSRv2] when using this framework.
6.1. Message Content 6.1. Message Content
Messages MUST have the content specified in [RFC6130] and [OLSRv2] Messages MUST have the content specified in [RFC6130] and [OLSRv2]
respectively. In addition, in order to conform to this framework, respectively. In addition, in order to conform to this framework,
skipping to change at page 11, line 39 skipping to change at page 12, line 9
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 is able to generate ICVs or validate messages, it Before a router using this framework is able to generate ICVs or
MUST acquire the shared secret key(s) to be used by all routers that validate messages, it MUST acquire the shared secret key(s) to be
are to participate in the network. This specification does not used by all routers that are to participate in the network. This
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
use, or not use, this framework.
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.]
9. Security Considerations 9. Security Considerations
This document specifies a security framework for use with NHDP and This document specifies a security framework for use with NHDP and
OLSRv2 that allows for alleviating several security threats. OLSRv2 that allows for alleviating several security threats.
9.1. Alleviated Attacks 9.1. Alleviated Attacks
This section briefly summarizes security threats that are alleviated This section briefly summarizes security threats that are alleviated
by the framework presented in this document. by the framework 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 is countered. add a valid ICV TLV to a message, identity spoofing, where an
attacker falsely claims an identity of a valid router, is countered.
9.1.2. Link Spoofing 9.1.2. Link Spoofing
Link spoofing is countered by the framework specified in this Link spoofing, where an attacker falsely represents the existence of
document, using the same argument as in Section 9.1.1. a non-existent link, or otherwise misrepresents a link's state, is
countered by the framework specified in this document, using the same
argument as in Section 9.1.1.
9.1.3. Replay Attack 9.1.3. Replay Attack
Replay attacks are partly countered by the framework specified in Replay attacks are partly countered by the framework specified in
this document, but this depends on synchronized clocks of all routers this document, but this depends on synchronized clocks of all routers
in the MANET. An attacker that records messages to replay them later in the MANET. An attacker that records messages to replay them later
can only do so in the selected time interval after the timestamp that can only do so in the selected time interval after the timestamp that
is contained in message. As an attacker cannot modify the content of is contained in message. As an attacker cannot modify the content of
this timestamp (as it is protected by the identity check value), an this timestamp (as it is protected by the identity check value), an
attacker cannot replay messages after this time. Within this time attacker cannot replay messages after this time. Within this time
skipping to change at page 13, line 14 skipping to change at page 13, line 38
integrity check value is used, any additional cryptographic integrity check value is used, any additional cryptographic
parameters). parameters).
This framework does not provide a key revocation mechanism. This framework does not provide a key revocation mechanism.
10. 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: Henning Rogge (Frauenhofer FKIE).
11. Normative References 11. 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
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
"Generalized MANET Packet/Message Format", RFC 5444, "Generalized MANET Packet/Message Format", RFC 5444,
skipping to change at page 13, line 37 skipping to change at page 14, line 17
[RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc [RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc
Network (MANET) Neighborhood Discovery Protocol (NHDP)", Network (MANET) Neighborhood Discovery Protocol (NHDP)",
RFC 6130, April 2011. RFC 6130, April 2011.
[RFC6622bis] [RFC6622bis]
Herberg, U., Clausen, T., and C. Dearlove, "Integrity Herberg, U., Clausen, T., and C. Dearlove, "Integrity
Check Value and Timestamp TLV Definitions for Mobile Ad Check Value and Timestamp TLV Definitions for Mobile Ad
Hoc Networks (MANETs)", work in Hoc Networks (MANETs)", work in
progress draft-ietf-manet-rfc6622-bis-02, April 2013. progress draft-ietf-manet-rfc6622-bis-02, April 2013.
11.2. Informative References
[RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter
Considerations in Mobile Ad Hoc Networks (MANETs)",
RFC 5148, February 2008.
Authors' Addresses Authors' Addresses
Ulrich Herberg Ulrich Herberg
Fujitsu Laboratories of America Fujitsu Laboratories of America
1240 E. Arques Ave. 1240 E. Arques Ave.
Sunnyvale, CA, 94085, Sunnyvale, CA, 94085,
USA USA
Email: ulrich@herberg.name Email: ulrich@herberg.name
URI: http://www.herberg.name/ URI: http://www.herberg.name/
 End of changes. 25 change blocks. 
71 lines changed or deleted 121 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/