draft-ietf-manet-nhdp-olsrv2-sec-00.txt   draft-ietf-manet-nhdp-olsrv2-sec-01.txt 
Mobile Ad hoc Networking (MANET) U. Herberg Mobile Ad hoc Networking (MANET) U. Herberg
Internet-Draft Fujitsu Laboratories of America Internet-Draft Fujitsu Laboratories of America
Updates: RFC6130 (if approved) C. Dearlove Updates: RFC6130 (if approved) C. Dearlove
Intended status: Standards Track BAE Systems ATC Intended status: Standards Track BAE Systems ATC
Expires: September 23, 2013 T. Clausen Expires: September 24, 2013 T. Clausen
LIX, Ecole Polytechnique LIX, Ecole Polytechnique
March 22, 2013 March 23, 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-00 draft-ietf-manet-nhdp-olsrv2-sec-01
Abstract Abstract
This document specifies integrity and replay protection for required This document specifies integrity and replay protection for required
implementation in the MANET Neighborhood Discovery Protocol (NHDP) implementation in the MANET Neighborhood Discovery Protocol (NHDP)
and the Optimized Link State Routing Protocol version 2 (OLSRv2). and the Optimized Link State Routing Protocol version 2 (OLSRv2).
This document specifies how an included integrity check value (ICV) This document specifies how an included integrity check value (ICV)
and a timestamp TLV, defined in RFC6622bis, are used by NHDP and and a timestamp TLV, defined in RFC6622bis, are used by NHDP and
OLSRv2 for countering a number of security threats. The ICV TLV uses OLSRv2 for countering a number of security threats. The ICV TLV uses
a SHA-256 based HMAC and a single shared secret key. The timestamp a SHA-256 based HMAC and one or more shared secret keys. The
TLV is based on POSIX time, assuming router synchronization. The timestamp TLV is based on POSIX time, and assumes that the clocks in
mechanism in this specification can also be used for other MANET all routers in the network can be synchronized with sufficient
protocols using RFC5444. precision. The mechanism in this specification can also be used for
other MANET protocols using RFC5444.
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 September 23, 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 2, line 22 skipping to change at page 2, line 24
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 4 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 4
4. Protocol Overview and Functioning . . . . . . . . . . . . . . 6 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 6
5. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Message Generation and Processing . . . . . . . . . . . . . . 8 6. Message Generation and Processing . . . . . . . . . . . . . . 8
6.1. Message Content . . . . . . . . . . . . . . . . . . . . . 8 6.1. Message Content . . . . . . . . . . . . . . . . . . . . . 8
6.2. Message Generation . . . . . . . . . . . . . . . . . . . . 8 6.2. Message Generation . . . . . . . . . . . . . . . . . . . . 9
6.3. Message Processing . . . . . . . . . . . . . . . . . . . . 9 6.3. Message Processing . . . . . . . . . . . . . . . . . . . . 9
6.3.1. Invalidating a Message Based on Timestamp . . . . . . 10 6.3.1. Invalidating a Message Based on Timestamp . . . . . . 10
6.3.2. Invalidating a Message Based on Integrity Check . . . 10 6.3.2. Invalidating a Message Based on Integrity Check . . . 10
7. Provisioning of Routers . . . . . . . . . . . . . . . . . . . 11 7. Provisioning of Routers . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9.1. Alleviated Attacks . . . . . . . . . . . . . . . . . . . . 11 9.1. Alleviated Attacks . . . . . . . . . . . . . . . . . . . . 11
9.1.1. Identity Spoofing . . . . . . . . . . . . . . . . . . 11 9.1.1. Identity Spoofing . . . . . . . . . . . . . . . . . . 11
9.1.2. Link Spoofing . . . . . . . . . . . . . . . . . . . . 11 9.1.2. Link Spoofing . . . . . . . . . . . . . . . . . . . . 11
9.1.3. Replay Attack . . . . . . . . . . . . . . . . . . . . 11 9.1.3. Replay Attack . . . . . . . . . . . . . . . . . . . . 12
9.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 12 9.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 12
10. Normative References . . . . . . . . . . . . . . . . . . . . . 12 10. Normative References . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
This specification defines a framework of security mechanisms that This specification defines a framework of security mechanisms that
must be included in conforming implementations of the Neighborhood must be included in conforming implementations of the Neighborhood
Discovery Protocol (NHDP) [RFC6130] and the Optimized Link State Discovery Protocol (NHDP) [RFC6130] and the Optimized Link State
Routing Protocol version 2 (OLSRv2) [OLSRv2] for Mobile Ad hoc Routing Protocol version 2 (OLSRv2) [OLSRv2] for Mobile Ad hoc
NETworks (MANETs). A deployment of these protocols may choose to NETworks (MANETs). A deployment of these protocols may choose to
employ alternative(s) to these mechanisms, in particular it may employ alternative(s) to these mechanisms, in particular it may
choose to protect packets rather than messages, it may choose to use choose to protect packets rather than messages, it may choose to use
skipping to change at page 3, line 30 skipping to change at page 3, line 30
messages to prevent replay attacks. Both use the TLV mechanism messages to prevent replay attacks. Both use the TLV mechanism
specified in [RFC5444] to add this information to the messages. specified in [RFC5444] to add this information to the messages.
These ICV and timestamp TLVs are defined in [RFC6622bis]. Different These ICV and timestamp TLVs are defined in [RFC6622bis]. Different
ICV TLVs are used for HELLO messages in NHDP and TC messages in ICV TLVs are used for HELLO messages in NHDP and TC messages in
OLSRv2, the former also protecting the source address of the IP OLSRv2, the former also protecting the source address of the IP
datagram that contains the HELLO message, because the IP datagram datagram that contains the HELLO message, because the IP datagram
source address is used by NHDP to determine the address of a neighbor source address is used by NHDP to determine the address of a neighbor
interface, and is not necessarily otherwise contained in the HELLO interface, and is not necessarily otherwise contained in the HELLO
message. message.
The mechanism specified in this document must insert itself between The mechanism specified in this document exists between NHDP's and
NHDP's and OLSRv2's message processing/generation and the [RFC5444] OLSRv2's message processing/generation and the [RFC5444] packet
packet parsing/generation, as illustrated in Figure 1. parsing/generation, as illustrated in Figure 1.
| | | |
Incoming | /|\ Outgoing Incoming | /|\ Outgoing
packet \|/ | packet packet \|/ | packet
| | | |
+--------------------------------+ +--------------------------------+
| | | |
| RFC5444 packet | | RFC5444 packet |
| parsing / generation | | parsing / generation |
| | | |
skipping to change at page 5, line 36 skipping to change at page 5, line 36
including the IP datagram source address). Deployments of including the IP datagram source address). Deployments of
[RFC6130] and [OLSRv2] using this framework should use the HMAC/ [RFC6130] and [OLSRv2] using this framework should use the HMAC/
SHA-256 ICV TLV, but may use different algorithms if more SHA-256 ICV TLV, but may use different algorithms if more
appropriate in a deployment. An implementation may also use more appropriate in a deployment. An implementation may also use more
than one ICV TLV in a message as long as they each use a different than one ICV TLV in a message as long as they each use a different
algorithm to calculate the ICV. algorithm to calculate the ICV.
o Specifies the implementation of a TIMESTAMP TLV, defined in o Specifies the implementation of a TIMESTAMP TLV, defined in
[RFC6622bis], to provide message replay protection. Deployments [RFC6622bis], to provide message replay protection. Deployments
of [RFC6130] and [OLSRv2] using this framework SHOULD use a POSIX of [RFC6130] and [OLSRv2] using this framework SHOULD use a POSIX
time based timestamp, if all routers can be sufficiently time based timestamp, if the clocks in all routers in the network
synchronized. 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
the routers share more than one secret key. (Such keys wil be
differentiated using the <key-id> field defined in an ICV TLV in
[RFC6622bis].)
o Specify how to distribute cryptographic material (shared secret o Specify how to distribute cryptographic material (shared secret
key). key(s)).
o Specify how to detect compromised routers with valid keys. o Specify how to detect compromised routers with valid keys.
o Specify how to handle (revoke) compromised routers with valid o Specify how to handle (revoke) compromised routers with valid
keys. keys.
4. Protocol Overview and Functioning 4. Protocol Overview and Functioning
The framework specified in this document provides the following The framework specified in this document provides the following
functionalities for use with messages owned by [RFC6130] and functionalities for use with messages owned by [RFC6130] and
[OLSRv2]: [OLSRv2]:
o Generation of ICV TLVs (as defined in [RFC6622bis]) for inclusion o Generation of ICV TLVs (as defined in [RFC6622bis]) for inclusion
in an outgoing message. An implementation of [RFC6130] and in an outgoing message. An implementation of [RFC6130] and
[OLSRv2] may use more than one ICV TLV in a message, even with the [OLSRv2] may use more than one ICV TLV in a message, even with the
same type extension, but these ICV TLVs MUST each use a different same type extension, but these ICV TLVs MUST each use a different
algorithm to calculate the ICV, e.g., with different hash and/or algorithm to calculate the ICV, e.g., with different hash and/or
cryptographic functions when using type extension 1 or 2. An cryptographic functions when using type extension 1 or 2. An
implementation of [RFC6130] and [OLSRv2] must at least be able to implementation of [RFC6130] and [OLSRv2] must at least be able to
generate an ICV TLV using HMAC/SHA-256 and a single secret key generate an ICV TLV using HMAC/SHA-256 and one or more secret keys
shared by all routers. shared by all routers.
o Generation of TIMESTAMP TLVs (as defined in [RFC6622bis]) for o Generation of TIMESTAMP TLVs (as defined in [RFC6622bis]) for
inclusion in an outgoing message. An implementation of [RFC6130] inclusion in an outgoing message. An implementation of [RFC6130]
and [OLSRv2] that is able to synchronize routers, must at least be and [OLSRv2], that is able to synchronize the clocks in all
routers in the network with sufficient precision, must at least be
able to generate a TIMESTAMP TLV using POSIX time. able to generate a TIMESTAMP TLV using POSIX time.
o Verification of ICV TLVs contained in a message, in order to o Verification of ICV TLVs contained in a message, in order to
determine if this message MUST be rejected as "badly formed and determine if this message MUST be rejected as "badly formed and
therefore invalid for processing" [RFC6130] [OLSRv2]. An therefore invalid for processing" [RFC6130] [OLSRv2]. An
implementation of [RFC6130] and [OLSRv2] must at least be able to implementation of [RFC6130] and [OLSRv2] must at least be able to
verify an ICV TLV using HMAC/SHA-256 and a single secret key verify an ICV TLV using HMAC/SHA-256 and one or more secret keys
shared by all routers. shared by all routers.
o Verification of a TIMESTAMP TLV (as defined in [RFC6622bis]) o Verification of a TIMESTAMP TLV (as defined in [RFC6622bis])
contained in a message, in order to determine if this message MUST contained in a message, in order to determine if this message MUST
be rejected as "badly formed and therefore invalid for processing" be rejected as "badly formed and therefore invalid for processing"
[RFC6130] [OLSRv2]. An implementation of [RFC6130] and [OLSRv2] [RFC6130] [OLSRv2]. An implementation of [RFC6130] and [OLSRv2]
that is able to synchronize routers, must at least be able to that is able to synchronize the clocks in all routers in the
verify a TIMESTAMP TLV using POSIX time. network with sufficient precision, must at least be able to verify
a TIMESTAMP TLV using POSIX time.
ICV Packet TLVs (as defined in [RFC6622bis]) may be used by a ICV Packet TLVs (as defined in [RFC6622bis]) may be used by a
deployment of the multiplexing process defined in [RFC5444], either deployment of the multiplexing process defined in [RFC5444], either
as well as, or instead of, the protection of the NHDP and OLSRv2 as well as, or instead of, the protection of the NHDP and OLSRv2
messages. (Note that in the case of NHDP, the packet protection is messages. (Note that in the case of NHDP, the packet protection is
equally good, and also protects the packet header. In the case of equally good, and also protects the packet header. In the case of
OLSRv2, the packet protection has different properties than the OLSRv2, the packet protection has different properties than the
message protection, especially for some forms of ICV. When packets message protection, especially for some forms of ICV. When packets
contain more than one message, the packet protection has lower contain more than one message, the packet protection has lower
overheads in space and computation time.) overheads in space and computation time.)
skipping to change at page 7, line 42 skipping to change at page 8, line 4
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_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 o MAX_TC_TIMESTAMP_DIFF < T_HOLD_TIME
The second and fourth of those constraints assume ideal The second and fourth of those constraints assume ideal time
synchronization. These bounds MAY be relaxed to allow for expected synchronization of the clocks in all routers in the network. These
timing differences between routers (between neighboring routers for bounds MAY be relaxed to allow for expected timing differences
between routers (between neighboring routers for
MAX_HELLO_TIMESTAMP_DIFF). However it should also be noted that, in MAX_HELLO_TIMESTAMP_DIFF). However it should also be noted that, in
the ideal case, the parameters SHOULD be significantly less than the ideal case, the parameters SHOULD be significantly less than
those bounds. those bounds.
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
skipping to change at page 9, line 49 skipping to change at page 10, line 11
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 framework:
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. This algorithm specification includes the selected algorithm and key identifier. This algorithm
the type extension, and for type extensions 1 and 2, the hash specification includes the type extension, and for type
function and cryptographic function. (The Message TLV Block may extensions 1 and 2, the hash function and cryptographic function.
also contain ICV TLVs using other algorithms.) (The Message TLV Block may also contain ICV TLVs using other
algorithms and key identifiers.)
3. Validation of the identified (in step 1) TIMESTAMP TLV in the 3. Validation of the identified (in step 1) TIMESTAMP TLV in the
Message TLV block of the message fails, as according to Message TLV block of the message fails, as according to
Section 6.3.1. Section 6.3.1.
4. Validation of the identified (in step 2) ICV TLVs in the Message 4. Validation of the identified (in step 2) ICV TLVs in the Message
TLV block of the message fails, as according to Section 6.3.2. TLV block of the message fails, as according to Section 6.3.2.
An implementation MAY check the existence of, and verify, either An implementation MAY check the existence of, and verify, either
alternative TIMESTAMP and/or ICV TLVs, or more than one TIMESTAMP alternative TIMESTAMP and/or ICV TLVs, or more than one TIMESTAMP
skipping to change at page 11, line 8 skipping to change at page 11, line 22
data> in the ICV Message TLV, then the message validation fails. data> in the ICV Message TLV, then the message validation fails.
5. Otherwise, the message validation succeeds. The message's <msg- 5. Otherwise, the message validation succeeds. The message's <msg-
hop-count> and <msg-hop-limit> fields are restored to their hop-count> and <msg-hop-limit> fields are restored to their
previous value, and the ICV Message TLVs are returned to the previous value, and the ICV Message TLVs are returned to the
message, whose size is updated accordingly. message, whose size is updated accordingly.
7. Provisioning of Routers 7. Provisioning of Routers
Before a router is able to generate ICVs or validate messages, it Before a router is able to generate ICVs or validate messages, it
MUST acquire the single shared secret key that is to be used by all MUST acquire the shared secret key(s) to be used by all routers that
routers that are to participate in the network. This specification are to participate in the network. This specification does not
does not define how a router acquires this secret key. define how a router acquires secret keys.
8. IANA Considerations 8. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
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 shared secret key are able to add a As only routers possessing the selected shared secret key are able to
valid ICV TLV to a message, identity spoofing is countered. add a valid ICV TLV to a message, identity spoofing is countered.
9.1.2. Link Spoofing 9.1.2. Link Spoofing
Link spoofing is countered by the framework specified in this Link spoofing is countered by the framework specified in this
document, using the same argument as in Section 9.1.1. document, using the same argument as in Section 9.1.1.
9.1.3. Replay Attack 9.1.3. Replay Attack
Replay attacks are partly counteracted by the framework specified in Replay attacks are partly counteracted 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
skipping to change at page 12, line 19 skipping to change at page 12, line 32
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 framework 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 framework relies on an out-of-band protocol or mechanism for
distributing the shared secret key (and if an alternative integrity distributing the shared secret key(s) (and if an alternative
check value is used, any additional cryptographic parameters). integrity check value is used, any additional cryptographic
parameters).
This framework does not provide a key revocation mechanism. This framework does not provide a key revocation mechanism.
10. Normative References 10. 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",
draft-ietf-manet-olsrv2-17 (work in progress), work in progress draft-ietf-manet-olsrv2-19, March 2013.
October 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
"Generalized MANET Packet/Message Format", RFC 5444, "Generalized MANET Packet/Message Format", RFC 5444,
February 2009. February 2009.
[RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc [RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc
Network (MANET) Neighborhood Discovery Protocol (NHDP)", Network (MANET) Neighborhood Discovery Protocol (NHDP)",
RFC 6130, April 2011. RFC 6130, April 2011.
[RFC6622bis] [RFC6622bis]
Herberg, U., Clausen, T., and C. Dearlove, "Integrity Herberg, U., Clausen, T., and C. Dearlove, "Integrity
Check Value and Timestamp TLV Definitions for Mobile Ad Check Value and Timestamp TLV Definitions for Mobile Ad
Hoc Networks (MANETs)", Internet Hoc Networks (MANETs)", work in
Draft draft-herberg-manet-rfc6622-bis-00, February 2013. progress draft-ietf-manet-rfc6622-bis-01, March 2013.
Authors' Addresses Authors' Addresses
Ulrich Herberg Ulrich Herberg
Fujitsu Laboratories of America Fujitsu Laboratories of America
1240 E. Arques Ave. 1240 E. Arques Ave.
Sunnyvale, CA, 94085, Sunnyvale, CA, 94085,
USA USA
Email: ulrich@herberg.name Email: ulrich@herberg.name
URI: http://www.herberg.name/ URI: http://www.herberg.name/
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/
Thomas Heide Clausen Thomas Heide Clausen
LIX, Ecole Polytechnique LIX, Ecole Polytechnique
91128 Palaiseau Cedex, 91128 Palaiseau Cedex,
France France
 End of changes. 25 change blocks. 
42 lines changed or deleted 54 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/