draft-ietf-manet-rfc6622-bis-02.txt   draft-ietf-manet-rfc6622-bis-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
Obsoletes: 6622 (if approved) T. Clausen Obsoletes: 6622 (if approved) T. Clausen
Intended status: Standards Track LIX, Ecole Polytechnique Intended status: Standards Track LIX, Ecole Polytechnique
Expires: October 17, 2013 C. Dearlove Expires: January 3, 2014 C. Dearlove
BAE Systems ATC BAE Systems ATC
April 15, 2013 July 2, 2013
Integrity Check Value and Timestamp TLV Definitions Integrity Check Value and Timestamp TLV Definitions
for Mobile Ad Hoc Networks (MANETs) for Mobile Ad Hoc Networks (MANETs)
draft-ietf-manet-rfc6622-bis-02 draft-ietf-manet-rfc6622-bis-03
Abstract Abstract
This document revises, extends and replaces RFC 6622. It describes This document revises, extends and replaces RFC 6622. It describes
general and flexible TLVs for representing cryptographic Integrity general and flexible TLVs for representing cryptographic Integrity
Check Values (ICVs) and timestamps, using the generalized Mobile Ad Check Values (ICVs) and timestamps, using the generalized Mobile Ad
Hoc Network (MANET) packet/message format defined in RFC 5444. It Hoc Network (MANET) packet/message format defined in RFC 5444. It
defines two Packet TLVs, two Message TLVs, and two Address Block TLVs defines two Packet TLVs, two Message TLVs, and two Address Block TLVs
for affixing ICVs and timestamps to a packet, a message, and one or for affixing ICVs and timestamps to a packet, a message, and one or
more addresses, respectively. more addresses, respectively.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Differences from RFC6622 . . . . . . . . . . . . . . . . . 3 1.1. Differences from RFC6622 . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 4 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 5
4. Security Architecture . . . . . . . . . . . . . . . . . . . . 5 4. Security Architecture . . . . . . . . . . . . . . . . . . . . 6
5. Overview and Functioning . . . . . . . . . . . . . . . . . . . 6 5. Overview and Functioning . . . . . . . . . . . . . . . . . . . 7
6. General ICV TLV Structure . . . . . . . . . . . . . . . . . . 7 6. General ICV TLV Structure . . . . . . . . . . . . . . . . . . 8
7. General Timestamp TLV Structure . . . . . . . . . . . . . . . 7 7. General Timestamp TLV Structure . . . . . . . . . . . . . . . 8
8. Packet TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Packet TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. ICV Packet TLV . . . . . . . . . . . . . . . . . . . . . . 8 8.1. ICV Packet TLV . . . . . . . . . . . . . . . . . . . . . 9
8.2. TIMESTAMP Packet TLV . . . . . . . . . . . . . . . . . . . 9 8.2. TIMESTAMP Packet TLV . . . . . . . . . . . . . . . . . . 10
9. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. ICV Message TLV . . . . . . . . . . . . . . . . . . . . . 9 9.1. ICV Message TLV . . . . . . . . . . . . . . . . . . . . . 10
9.2. TIMESTAMP Message TLV . . . . . . . . . . . . . . . . . . 9 9.2. TIMESTAMP Message TLV . . . . . . . . . . . . . . . . . . 11
10. Address Block TLVs . . . . . . . . . . . . . . . . . . . . . . 10 10. Address Block TLVs . . . . . . . . . . . . . . . . . . . . . . 11
10.1. ICV Address Block TLV . . . . . . . . . . . . . . . . . . 10 10.1. ICV Address Block TLV . . . . . . . . . . . . . . . . . . 11
10.2. TIMESTAMP Address Block TLV . . . . . . . . . . . . . . . 10 10.2. TIMESTAMP Address Block TLV . . . . . . . . . . . . . . . 11
11. ICV: Basic . . . . . . . . . . . . . . . . . . . . . . . . . . 10 11. ICV: Basic . . . . . . . . . . . . . . . . . . . . . . . . . . 12
12. ICV: Hash Function and Cryptographic Function . . . . . . . . 11 12. ICV: Hash Function and Cryptographic Function . . . . . . . . 12
12.1. General ICV TLV Structure . . . . . . . . . . . . . . . . 11 12.1. General ICV TLV Structure . . . . . . . . . . . . . . . . 12
12.1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . 12 12.1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . 14
12.2. Considerations for Calculating the ICV . . . . . . . . . . 13 12.2. Considerations for Calculating the ICV . . . . . . . . . 14
12.2.1. Packet ICV TLV . . . . . . . . . . . . . . . . . . . 13 12.2.1. Packet ICV TLV . . . . . . . . . . . . . . . . . . . 14
12.2.2. Message ICV TLV . . . . . . . . . . . . . . . . . . . 13 12.2.2. Message ICV TLV . . . . . . . . . . . . . . . . . . . 15
12.2.3. Address Block ICV TLV . . . . . . . . . . . . . . . . 14 12.2.3. Address Block ICV TLV . . . . . . . . . . . . . . . . 15
12.3. Example of a Message Including an ICV . . . . . . . . . . 14 12.3. Example of a Message Including an ICV . . . . . . . . . . 16
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
13.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 16 13.1. Expert Review: Evaluation Guidelines . . . . . . . . . . 17
13.2. Packet TLV Type Registrations . . . . . . . . . . . . . . 16 13.2. Packet TLV Types . . . . . . . . . . . . . . . . . . . . 17
13.3. Message TLV Type Registrations . . . . . . . . . . . . . . 18 13.3. Message TLV Types . . . . . . . . . . . . . . . . . . . . 18
13.4. Address Block TLV Type Registrations . . . . . . . . . . . 19 13.4. Address Block TLV Types . . . . . . . . . . . . . . . . . 18
13.5. Hash Functions . . . . . . . . . . . . . . . . . . . . . . 20 13.5. ICV Packet TLV Type Extensions . . . . . . . . . . . . . 18
13.6. Cryptographic Functions . . . . . . . . . . . . . . . . . 20 13.6. TIMESTAMP Packet TLV Type Extensions . . . . . . . . . . 19
14. Security Considerations . . . . . . . . . . . . . . . . . . . 21 13.7. ICV Message TLV Type Extensions . . . . . . . . . . . . . 20
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 13.8. TIMESTAMP Message TLV Type Extensions . . . . . . . . . . 21
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 13.9. ICV Address Block TLV Type Extensions . . . . . . . . . . 21
16.1. Normative References . . . . . . . . . . . . . . . . . . . 22 13.10. TIMESTAMP Address Block TLV Type Extensions . . . . . . . 22
16.2. Informative References . . . . . . . . . . . . . . . . . . 23 13.11. Hash Functions . . . . . . . . . . . . . . . . . . . . . 23
13.12. Cryptographic Functions . . . . . . . . . . . . . . . . . 24
14. Security Considerations . . . . . . . . . . . . . . . . . . . 24
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
16.1. Normative References . . . . . . . . . . . . . . . . . . 25
16.2. Informative References . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
[RFC Editor note: Please replace "xxxx" throughout this document with
the RFC number assigned to this document, and remove this note.]
This document specifies a syntactical representation of security- This document specifies a syntactical representation of security-
related information for use with [RFC5444] addresses, messages, and related information for use with [RFC5444] addresses, messages, and
packets, and also reports and updates IANA registrations (from packets, and also reports and updates IANA registrations (from
[RFC6622]) of TLV types and type extension registries for these TLV [RFC6622]) of TLV types and type extension registries for these TLV
types. This specification does not represent a stand-alone protocol, types. This specification does not represent a stand-alone protocol,
but is intended for use by MANET routing protocols, or security but is intended for use by MANET routing protocols, or security
extensions thereof. extensions thereof.
Specifically, this document, which revises, extends and replaces Specifically, this document, which revises, extends, and replaces
[RFC6622], specifies: [RFC6622], specifies:
o Two kinds of TLV: one for carrying Integrity Check Values (ICVs) o Two kinds of TLV: one for carrying Integrity Check Values (ICVs)
and one for timestamps in packets, messages, and address blocks as and one for timestamps in packets, messages, and address blocks as
defined by [RFC5444]. defined by [RFC5444].
o A generic framework for use of these TLVs, accounting for specific o A generic framework for use of these TLVs, accounting for specific
features of Packet, Message and Address Block TLVs. features of Packet, Message and Address Block TLVs.
This document retains the IANA registries, defined in [RFC6622], for This document retains the IANA registries, defined in [RFC6622], for
recording code points for ICV calculations, and requests an recording code points for ICV calculations, and requests an
additional allocation from each these registries. This document additional allocation from each these registries. This document
retains the IANA registries, defined in [RFC6622], for recording code retains the IANA registries, defined in [RFC6622], for recording code
points for timestamps, hash-functions, and cryptographic functions, points for timestamps, hash-functions, and cryptographic functions,
but does not request any additional allocations from these but does not request any additional allocations from these
registries. registries. This document replaces [RFC6622] as the reference for
these registries.
Moreover, in Section 12, this document defines the following: Moreover, in Section 12, this document defines the following:
o A method for generating ICVs using a combination of a o A method for generating ICVs using a combination of a
cryptographic function and a hash function, and for including such cryptographic function and a hash function, and for including such
ICVs in the value field of a TLV. ICVs in the value field of a TLV.
1.1. Differences from RFC6622 1.1. Differences from RFC6622
This document obsoletes [RFC6622]. In addition to editorial updates, This document obsoletes [RFC6622], replacing that document as the
this document adds a new type extension 2 for the ICV TLV that is specification of two TLV types, TIMESTAMP and ICV, for packets,
specified in Section 12 of this document. It also makes it clear messages and address blocks. For the ICV TLV as well as repeating
that an ICV TLV may be used to carry a truncated ICV, and that a the specification of two type extensions, 0 and 1, it also specifies
single- or multi- value ICV or TIMESTAMP Address Block TLV may cover a new type extension, 2, in Section 12 of this document.
more than one address.
The TLV value of an ICV TLV with type extension 2 has the same The TLV value of an ICV TLV with type extension 2 has the same
internal structure as an ICV TLV with type extension 1, but is internal structure as an ICV TLV with type extension 1, but is
calculated also over the source address of the IP datagram carrying calculated also over the source address of the IP datagram carrying
the packet, message, or Address Block. The rationale for adding this the packet, message, or Address Block. The rationale for adding this
type extension is that some MANET protocols, such as [RFC6130], use type extension is that some MANET protocols, such as [RFC6130], use
the IP source address of the IP datagram carrying the packet, message the IP source address of the IP datagram carrying the packet, message
or Address Block, e.g., to identify links with neighbor routers. If or Address Block, e.g., to identify links with neighbor routers. If
this address is not otherwise contained in the packet, message, or this address is not otherwise contained in the packet, message, or
Address Block payload (which is permitted, e.g., in [RFC6130]), then Address Block payload (which is permitted, e.g., in [RFC6130]), then
the address is not protected against tampering. the address is not protected against tampering.
This document also incorporates a number of editorial improvements
over [RFC6622]. In particular, it makes it clear that an ICV TLV may
be used to carry a truncated ICV, and that a single- or multi-value
TIMESTAMP or ICV Address Block TLV may cover more than one address.
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].
This document uses the terminology and notation defined in [RFC5444]. This document uses the terminology and notation defined in [RFC5444].
In particular, the following TLV fields and notation from [RFC5444] In particular, the following TLV fields and notation from [RFC5444]
are used in this specification: are used in this specification:
skipping to change at page 4, line 34 skipping to change at page 5, line 42
<msg-hop-count> is the hop count of a message, as specified in <msg-hop-count> is the hop count of a message, as specified in
Section 5.2 of [RFC5444]. Section 5.2 of [RFC5444].
<length> is the length of the value field in a TLV in octets, as <length> is the length of the value field in a TLV in octets, as
specified in Section 5.4.1 of [RFC5444]. specified in Section 5.4.1 of [RFC5444].
single-length is the length of a single value in the value field in single-length is the length of a single value in the value field in
a TLV in octets, as specified in Section 5.4.1 of [RFC5444]. (It a TLV in octets, as specified in Section 5.4.1 of [RFC5444]. (It
is equal to <length> except in a multivalue Address Block TLV.) is equal to <length> except in a multivalue Address Block TLV.)
In addition to the regular expressions defined in Section 2.1.1 of
[RFC5444] this document defines:
+ - One or more occurrences of the preceding element or group.
3. Applicability Statement 3. Applicability Statement
MANET routing protocols using the format defined in [RFC5444] are MANET routing protocols using the format defined in [RFC5444] are
accorded the ability to carry additional information in control accorded the ability to carry additional information in control
messages and packets, through the inclusion of TLVs. Information so messages and packets, through the inclusion of TLVs. Information so
included MAY be used by a MANET routing protocol, or by an extension included MAY be used by a MANET routing protocol, or by an extension
of a MANET routing protocol, according to its specification. of a MANET routing protocol, according to its specification.
This document specifies how to include an ICV for a packet, a This document specifies how to include an ICV for a packet, a
message, and addresses in Address Blocks within a message, using such message, and addresses in Address Blocks within a message, using such
skipping to change at page 6, line 40 skipping to change at page 8, line 5
This document reports previously assigned TLV types (from [RFC6622]) This document reports previously assigned TLV types (from [RFC6622])
from the registries defined for Packet, Message, and Address Block from the registries defined for Packet, Message, and Address Block
TLVs in [RFC5444]. When a TLV type is assigned from one of these TLVs in [RFC5444]. When a TLV type is assigned from one of these
registries, a registry for type extensions for that TLV type is registries, a registry for type extensions for that TLV type is
created by IANA. This document reports and updates these type created by IANA. This document reports and updates these type
extension registries, in order to specify internal structure (and extension registries, in order to specify internal structure (and
accompanying processing) of the <value> field of a TLV. accompanying processing) of the <value> field of a TLV.
For example, and as reported in this document, an ICV TLV with type For example, and as reported in this document, an ICV TLV with type
extension = 0 specifies that the <value> field has no pre-defined extension = 0 specifies that the <value> field has no pre-defined
internal structure but is simply a sequence of octets. An ICV TLV internal structure, but is simply a sequence of octets. An ICV TLV
with type extension = 1 specifies that the <value> field has a pre- with type extension = 1 specifies that the <value> field has a pre-
defined internal structure and defines its interpretation. An ICV defined internal structure and defines its interpretation. An ICV
TLV with type extension = 2 specifies a modified version of this TLV with type extension = 2 (added in this document) is the same as
definition. an ICV TLV with type extension = 1, except that the integrity
protection also covers the source address of the IP datagram carrying
the packet, message, or Address Block.
Specifically, with type extension = 1 or type extension = 2 (added in Specifically, with type extension = 1 or type extension = 2, the
this document), the <value> field contains the result of combining a <value> field contains the result of combining a cryptographic
cryptographic function and a hash function, calculated over the function and a hash function, calculated over the contents of the
contents of the packet, message or Address Block. The <value> field packet, message, or Address Block. The <value> field contains sub-
contains multiple sub-fields indicating which hash function and fields indicating which hash function and cryptographic function have
cryptographic function have been used as specified in Section 12. been used, as specified in Section 12.
The difference between the two type extensions is that the ICV TLV
with type extension = 2 is calculated also over the source address of
the IP datagram carrying the packet, message, or address block.
Other documents can request assignments for other type extensions; if Other documents can request assignments for other type extensions; if
they do so, they MUST specify their internal structure (if any) and they do so, they MUST specify their internal structure (if any) and
interpretation. interpretation.
6. General ICV TLV Structure 6. General ICV TLV Structure
The value of the ICV TLV is: The value of the ICV TLV is:
<value> := <ICV-value>+ <value> := <ICV-value>+
skipping to change at page 8, line 5 skipping to change at page 9, line 18
Note that this does not specify how to calculate the <time-value> nor Note that this does not specify how to calculate the <time-value> nor
the internal structure thereof, if any; such information MUST be the internal structure thereof, if any; such information MUST be
specified by the type extension for the TIMESTAMP TLV type; see specified by the type extension for the TIMESTAMP TLV type; see
Section 13. Section 13.
A timestamp is essentially "freshness information". As such, its A timestamp is essentially "freshness information". As such, its
setting and interpretation are to be determined by the MANET routing setting and interpretation are to be determined by the MANET routing
protocol, or MANET routing protocol extension, that uses the protocol, or MANET routing protocol extension, that uses the
timestamp and can, for example, correspond to a POSIX timestamp, GPS timestamp and can, for example, correspond to a POSIX timestamp, GPS
timestamp, or a simple sequence number. Note that insuring time timestamp, or a simple sequence number. Note that ensuring time
synchronization in a MANET may be difficult because of the synchronization in a MANET may be difficult because of the
decentralized architecture as well as highly dynamic topology due to decentralized architecture as well as highly dynamic topology due to
mobility or other factors. It is out of scope for this document to mobility or other factors. It is out of scope for this document to
specify a time synchronization mechanism. specify a time synchronization mechanism.
8. Packet TLVs 8. Packet TLVs
Two Packet TLVs are defined: one for including the cryptographic ICV Two Packet TLVs are defined: one for including the cryptographic ICV
of a packet and one for including the timestamp indicating the time of a packet and one for including the timestamp indicating the time
at which the cryptographic ICV was calculated. at which the cryptographic ICV was calculated.
skipping to change at page 12, line 22 skipping to change at page 13, line 35
cryptographic ICV. cryptographic ICV.
The version of this TLV, specified in this section, assumes that, The version of this TLV, specified in this section, assumes that,
unless otherwise specified, calculating the ICV can be decomposed unless otherwise specified, calculating the ICV can be decomposed
into: into:
ICV-value = cryptographic-function(hash-function(content)) ICV-value = cryptographic-function(hash-function(content))
In some cases a different combination of cryptographic function and In some cases a different combination of cryptographic function and
hash function may be specified. This is the case for the HMAC hash function may be specified. This is the case for the HMAC
function, which is specified as defined in Section 13.6, using the function, which is specified as defined in Section 13.12, using the
hash function twice. hash function twice.
The difference between the two type extensions is that in addition to The difference between the two type extensions is that in addition to
the information covered by the ICV using type extension 1 (which is the information covered by the ICV using type extension 1 (which is
detailed in the following sections), the ICV using type extension 2 detailed in the following sections), the ICV using type extension 2
also MUST cover the source address of the IP datagram carrying the also MUST cover the source address of the IP datagram carrying the
corresponding packet, message, or Address Block. corresponding packet, message, or Address Block.
The <ICV-data> field MAY be truncated after being calculated, this is The <ICV-data> field MAY be truncated after being calculated, this is
indicated by its length, calculated as described above. The indicated by its length, calculated as described above. The
skipping to change at page 13, line 38 skipping to change at page 14, line 51
<cryptographic-function>, <key-id-length>, and -- if present -- <cryptographic-function>, <key-id-length>, and -- if present --
<key-id> (in that order), followed by the entire packet, including <key-id> (in that order), followed by the entire packet, including
the Packet Header, including all Packet TLVs (other than ICV the Packet Header, including all Packet TLVs (other than ICV
Packet TLVs), and all included messages. The considerations of Packet TLVs), and all included messages. The considerations of
Section 8.1 MUST be applied. Section 8.1 MUST be applied.
When determining the <ICV-data> for a packet, with type extension = When determining the <ICV-data> for a packet, with type extension =
2: 2:
o The same procedure as for type extension = 1 is used, except that o The same procedure as for type extension = 1 is used, except that
the source address of the IP datagram carrying the packet is also the data used consists of a representation of the source address
concatenated, in the first position, with the data used. of the IP datagram carrying the packet, followed by the remaining
data (as for type extension = 1). The representation of the
source address consists of a single octet containing the address
length, in octets, followed by that many octets containing the
address in network byte order.
12.2.2. Message ICV TLV 12.2.2. Message ICV TLV
When determining the <ICV-data> for a message, with type extension = When determining the <ICV-data> for a message, with type extension =
1: 1:
o The ICV is calculated over the fields <hash-function>, o The ICV is calculated over the fields <hash-function>,
<cryptographic-function>, <key-id-length>, and -- if present -- <cryptographic-function>, <key-id-length>, and -- if present --
<key-id> (in that order), followed by the entire message. The <key-id> (in that order), followed by the entire message. The
considerations in Section 9.1 MUST be applied. considerations in Section 9.1 MUST be applied.
When determining the <ICV-data> for a message, with type extension = When determining the <ICV-data> for a message, with type extension =
2: 2:
o The same procedure as for type extension = 1 is used, except that o The same procedure as for type extension = 1 is used, except that
the source address of the IP datagram carrying the message is also the data used consists of a representation of the source address
concatenated, in the first position, with the data used. of the IP datagram carrying the message, followed by the remaining
data (as for type extension = 1). The representation of the
source address consists of a single octet containing the address
length, in octets, followed by that many octets containing the
address in network byte order.
12.2.3. Address Block ICV TLV 12.2.3. Address Block ICV TLV
When determining the <ICV-data> for one or more addresses, with type When determining the <ICV-data> for one or more addresses, with type
extension = 1: extension = 1:
o The ICV is calculated over the fields <hash-function>, o The ICV is calculated over the fields <hash-function>,
<cryptographic-function>, <key-id-length>, and -- if present -- <cryptographic-function>, <key-id-length>, and -- if present --
<key-id> (in that order), followed by the addresses, and followed <key-id> (in that order), followed by the addresses, and followed
by any other values -- for example, other address block TLV by any other values -- for example, other address block TLV
skipping to change at page 14, line 30 skipping to change at page 15, line 50
routing protocol, or MANET routing protocol extension, using ICV routing protocol, or MANET routing protocol extension, using ICV
Address Block TLVs MUST specify how to include any such Address Block TLVs MUST specify how to include any such
concatenated attribute of the addresses in the verification concatenated attribute of the addresses in the verification
process of the ICV. The considerations in Section 10.1 MUST be process of the ICV. The considerations in Section 10.1 MUST be
applied. applied.
When determining the <ICV-data> for one or more addresses, with type When determining the <ICV-data> for one or more addresses, with type
extension = 2: extension = 2:
o The same procedure as for type extension = 1 is used, except that o The same procedure as for type extension = 1 is used, except that
the source address of the IP datagram carrying the Address Block the data used consists of a representation of the source address
is also concatenated, in the first position, with the data used. of the IP datagram carrying the Address Block, followed by the
remaining data (as for type extension = 1). The representation of
the source address consists of a single octet containing the
address length, in octets, followed by that many octets containing
the address in network byte order.
12.3. Example of a Message Including an ICV 12.3. Example of a Message Including an ICV
The sample message depicted in Figure 1 is derived from Appendix D of The sample message depicted in Figure 1 is derived from Appendix D of
[RFC5444]. The message contains an ICV Message TLV, with the value [RFC5444]. The message contains an ICV Message TLV, with the value
representing an ICV that is 16 octets long of the whole message, and representing an ICV that is 16 octets long of the whole message, and
a key identifier that is 4 octets long. The type extension of the a key identifier that is 4 octets long. The type extension of the
Message TLV is 1, for the specific decomposition of an ICV using a Message TLV is 1, for the specific decomposition of an ICV using a
cryptographic function and a hash function, as specified in cryptographic function and a hash function, as specified in
Section 12. Section 12.
skipping to change at page 16, line 19 skipping to change at page 17, line 33
"Registration", and "Designated Expert". "Registration", and "Designated Expert".
The following policy is used as defined in [BCP26]: "Expert Review". The following policy is used as defined in [BCP26]: "Expert Review".
13.1. Expert Review: Evaluation Guidelines 13.1. Expert Review: Evaluation Guidelines
For TLV type extensions registries where an Expert Review is For TLV type extensions registries where an Expert Review is
required, the Designated Expert SHOULD take the same general required, the Designated Expert SHOULD take the same general
recommendations into consideration as those specified by [RFC5444]. recommendations into consideration as those specified by [RFC5444].
For both Timestamp and ICV TLVs, functionally similar extensions for For both TIMESTAMP and ICV TLVs, functionally similar extensions for
Packet, Message, and Address Block TLVs SHOULD be numbered Packet, Message, and Address Block TLVs SHOULD be numbered
identically. identically.
13.2. Packet TLV Type Registrations 13.2. Packet TLV Types
IANA has, in accordance with [RFC6622], made allocations from the IANA has, in accordance with [RFC6622], made allocations from the
"Packet TLV Types" namespace of [RFC5444] for the Packet TLVs "Packet TLV Types" namespace of [RFC5444] for the Packet TLVs
specified in Table 1. IANA are requested to modify this allocation specified in Table 1. IANA is requested to modify this allocation as
(defining type extension = 2) as indicated. indicated.
+-----------+------+-----------+------------------------------------+ +------+-------------+-----------+
| Name | Type | Type | Description | | Type | Description | Reference |
| | | Extension | | +------+-------------+-----------+
+-----------+------+-----------+------------------------------------+ | 5 | ICV | RFC xxxx |
| ICV | 5 | 0 | ICV of a packet | | 6 | TIMESTAMP | RFC xxxx |
| | | 1 | ICV, using a cryptographic | +------+-------------+-----------+
| | | | function and a hash function, as |
| | | | specified in Section 12 of this |
| | | | document |
| | | 2 | ICV, using a cryptographic |
| | | | function and a hash function, and |
| | | | including the IP datagram source |
| | | | address, as specified in |
| | | | Section 12 of this document |
| | | 3-251 | Unassigned; Expert Review |
| | | 252-255 | Experimental Use |
| TIMESTAMP | 6 | 0 | Unsigned timestamp of arbitrary |
| | | | length, given by the TLV Length |
| | | | field. The MANET routing protocol |
| | | | has to define how to interpret |
| | | | this timestamp |
| | | 1 | Unsigned 32-bit timestamp, as |
| | | | specified in [IEEE 1003.1-2008 |
| | | | (POSIX)] |
| | | 2 | NTP timestamp format, as specified |
| | | | in [RFC5905] |
| | | 3 | Signed timestamp of arbitrary |
| | | | length with no constraints such as |
| | | | monotonicity. In particular, it |
| | | | may represent any random value |
| | | 4-251 | Unassigned; Expert Review |
| | | 252-255 | Experimental Use |
+-----------+------+-----------+------------------------------------+
Table 1: Packet TLV Types Table 1: Packet TLV Types
13.3. Message TLV Types
IANA has, in accordance with [RFC6622], made allocations from the
"Message TLV Types" namespace of [RFC5444] for the Message TLVs
specified in Table 2. IANA is requested to modify this allocation as
indicated.
+------+-------------+-----------+
| Type | Description | Reference |
+------+-------------+-----------+
| 5 | ICV | RFC xxxx |
| 6 | TIMESTAMP | RFC xxxx |
+------+-------------+-----------+
Table 2: Message TLV Types
13.4. Address Block TLV Types
IANA has, in accordance with [RFC6622], made allocations from the
"Address Block TLV Types" namespace of [RFC5444] for the Packet TLVs
specified in Table 3. IANA is requested to modify this allocation as
indicated.
+------+-------------+-----------+
| Type | Description | Reference |
+------+-------------+-----------+
| 5 | ICV | RFC xxxx |
| 6 | TIMESTAMP | RFC xxxx |
+------+-------------+-----------+
Table 3: Address Block TLV Types
13.5. ICV Packet TLV Type Extensions
IANA has, in accordance with [RFC6622], made allocations from the
"ICV Packet TLV Type Extensions" namespace of [RFC6622] for the
Packet TLVs specified in Table 4. IANA is requested to modify this
allocation (including defining type extension = 2) as indicated.
+-----------+-------------------------------------------+-----------+
| Type | Description | Reference |
| Extension | | |
+-----------+-------------------------------------------+-----------+
| 0 | ICV of a packet | RFC xxxx |
| 1 | ICV, using a cryptographic function and a | RFC xxxx |
| | hash function, as specified in Section 12 | |
| | of this document | |
| 2 | ICV, using a cryptographic function and a | RFC xxxx |
| | hash function, and including the IP | |
| | datagram source address, as specified in | |
| | Section 12 of this document | |
| 3-251 | Unassigned; Expert Review | |
| 252-255 | Experimental Use | RFC xxxx |
+-----------+-------------------------------------------+-----------+
Table 4: ICV Packet TLV Type Extensions
More than one ICV Packet TLV with the same type extension MAY be More than one ICV Packet TLV with the same type extension MAY be
included in a packet if these represent different ICV calculations included in a packet if these represent different ICV calculations
(e.g., with type extension 1 or 2 and different cryptographic (e.g., with type extension 1 or 2 and different cryptographic
function and/or hash function, or with a different key identifier). function and/or hash function, or with a different key identifier).
ICV Packet TLVs that carry what is declared to be the same ICV Packet TLVs that carry what is declared to be the same
information MUST NOT be included in the same packet. More than one information MUST NOT be included in the same packet.
TIMESTAMP Packet TLV with the same type extension MUST NOT be
included in a packet.
13.3. Message TLV Type Registrations 13.6. TIMESTAMP Packet TLV Type Extensions
IANA has, in accordance with [RFC6622], made allocations from the IANA has, in accordance with [RFC6622], made allocations from the
"Message TLV Types" namespace of [RFC5444] for the Message TLVs "TIMESTAMP Packet TLV Type Extensions" namespace of [RFC6622] for the
specified in Table 2. IANA are requested to modify this allocation Packet TLVs specified in Table 5. IANA is requested to modify this
(defining type extension = 2) as indicated. allocation as indicated.
+-----------+------+-----------+------------------------------------+ +-----------+-------------------------------------------+-----------+
| Name | Type | Type | Description | | Type | Description | Reference |
| | | Extension | | | Extension | | |
+-----------+------+-----------+------------------------------------+ +-----------+-------------------------------------------+-----------+
| ICV | 5 | 0 | ICV of a message | | 0 | Unsigned timestamp of arbitrary length, | RFC xxxx |
| | | 1 | ICV, using a cryptographic | | | given by the TLV Length field. The MANET | |
| | | | function and a hash function, as | | | routing protocol has to define how to | |
| | | | specified in Section 12 of this | | | interpret this timestamp | |
| | | | document | | 1 | Unsigned 32-bit timestamp, as specified | RFC xxxx |
| | | 2 | ICV, using a cryptographic | | | in [IEEE 1003.1-2008 (POSIX)] | |
| | | | function and a hash function, and | | 2 | NTP timestamp format, as specified in | RFC xxxx |
| | | | including the IP datagram source | | | [RFC5905] | |
| | | | address, as specified in | | 3 | Signed timestamp of arbitrary length with | RFC xxxx |
| | | | Section 12 of this document | | | no constraints such as monotonicity. In | |
| | | 3-251 | Unassigned; Expert Review | | | particular, it may represent any random | |
| | | 252-255 | Experimental Use | | | value | |
| TIMESTAMP | 6 | 0 | Unsigned timestamp of arbitrary | | 4-251 | Unassigned; Expert Review | |
| | | | length, given by the TLV Length | | 252-255 | Experimental Use | RFC xxxx |
| | | | field. | +-----------+-------------------------------------------+-----------+
| | | 1 | Unsigned 32-bit timestamp, as |
| | | | specified in [IEEE 1003.1-2008 |
| | | | (POSIX)] |
| | | 2 | NTP timestamp format, as specified |
| | | | in [RFC5905] |
| | | 3 | Signed timestamp of arbitrary |
| | | | length with no constraints such as |
| | | | monotonicity. In particular, it |
| | | | may represent any random value |
| | | 4-251 | Unassigned; Expert Review |
| | | 252-255 | Experimental Use |
+-----------+------+-----------+------------------------------------+
Table 2: Message TLV Types Table 5: TIMESTAMP Packet TLV Type Extensions
More than one TIMESTAMP Packet TLV with the same type extension MUST
NOT be included in a packet.
13.7. ICV Message TLV Type Extensions
IANA has, in accordance with [RFC6622], made allocations from the
"ICV Message TLV Type Extensions" namespace of [RFC6622] for the
Message TLVs specified in Table 6. IANA is requested to modify this
allocation (including defining type extension = 2) as indicated.
+-----------+-------------------------------------------+-----------+
| Type | Description | Reference |
| Extension | | |
+-----------+-------------------------------------------+-----------+
| 0 | ICV of a message | RFC xxxx |
| 1 | ICV, using a cryptographic function and a | RFC xxxx |
| | hash function, as specified in Section 12 | |
| | of this document | |
| 2 | ICV, using a cryptographic function and a | RFC xxxx |
| | hash function, and including the IP | |
| | datagram source address, as specified in | |
| | Section 12 of this document | |
| 3-251 | Unassigned; Expert Review | |
| 252-255 | Experimental Use | RFC xxxx |
+-----------+-------------------------------------------+-----------+
Table 6: ICV Message TLV Type Extensions
More than one ICV Message TLV with the same type extension MAY be More than one ICV Message TLV with the same type extension MAY be
included in a message if these represent different ICV calculations included in a message if these represent different ICV calculations
(e.g., with type extension 1 or 2 and different cryptographic (e.g., with type extension 1 or 2 and different cryptographic
function and/or hash function, or with a different key identifier). function and/or hash function, or with a different key identifier).
ICV Message TLVs that carry what is declared to be the same ICV Message TLVs that carry what is declared to be the same
information MUST NOT be included in the same message. More than one information MUST NOT be included in the same message.
TIMESTAMP Message TLV with the same type extension MUST NOT be
included in a message.
13.4. Address Block TLV Type Registrations 13.8. TIMESTAMP Message TLV Type Extensions
IANA has, in accordance with [RFC6622], made allocations from the IANA has, in accordance with [RFC6622], made allocations from the
"Address Block TLV Types" namespace of [RFC5444] for the Packet TLVs "TIMESTAMP Message TLV Type Extensions" namespace of [RFC6622] for
specified in Table 3. IANA are requested to modify this allocation the Message TLVs specified in Table 7. IANA is requested to modify
(defining type extension = 2) as indicated. this allocation as indicated.
+-----------+------+-----------+------------------------------------+ +-----------+-------------------------------------------+-----------+
| Name | Type | Type | Description | | Type | Description | Reference |
| | | Extension | | | Extension | | |
+-----------+------+-----------+------------------------------------+ +-----------+-------------------------------------------+-----------+
| ICV | 5 | 0 | ICV of an object (e.g., an | | 0 | Unsigned timestamp of arbitrary length, | RFC xxxx |
| | | | address) | | | given by the TLV Length field. The MANET | |
| | | 1 | ICV, using a cryptographic | | | routing protocol has to define how to | |
| | | | function and a hash function, as | | | interpret this timestamp | |
| | | | specified in Section 12 of this | | 1 | Unsigned 32-bit timestamp, as specified | RFC xxxx |
| | | | document | | | in [IEEE 1003.1-2008 (POSIX)] | |
| | | 2 | ICV, using a cryptographic | | 2 | NTP timestamp format, as specified in | RFC xxxx |
| | | | function and a hash function, and | | | [RFC5905] | |
| | | | including the IP datagram source | | 3 | Signed timestamp of arbitrary length with | RFC xxxx |
| | | | address, as specified in | | | no constraints such as monotonicity. In | |
| | | | Section 12 of this document | | | particular, it may represent any random | |
| | | 3-251 | Unassigned; Expert Review | | | value | |
| | | 252-255 | Experimental Use | | 4-251 | Unassigned; Expert Review | |
| TIMESTAMP | 6 | 0 | Unsigned timestamp of arbitrary | | 252-255 | Experimental Use | RFC xxxx |
| | | | length, given by the TLV Length | +-----------+-------------------------------------------+-----------+
| | | | field |
| | | 1 | Unsigned 32-bit timestamp, as |
| | | | specified in [IEEE 1003.1-2008 |
| | | | (POSIX)] |
| | | 2 | NTP timestamp format, as specified |
| | | | in [RFC5905] |
| | | 3 | Signed timestamp of arbitrary |
| | | | length with no constraints such as |
| | | | monotonicity. In particular, it |
| | | | may represent any random value |
| | | 4-251 | Unassigned; Expert Review |
| | | 252-255 | Experimental Use |
+-----------+------+-----------+------------------------------------+
Table 3: Address Block TLV Types Table 7: TIMESTAMP Message TLV Type Extensions
More than one TIMESTAMP Message TLV with the same type extension MUST
NOT be included in a message.
13.9. ICV Address Block TLV Type Extensions
IANA has, in accordance with [RFC6622], made allocations from the
"ICV Address Block TLV Type Extensions" namespace of [RFC6622] for
the Address Block TLVs specified in Table 8. IANA is requested to
modify this allocation (including defining type extension = 2) as
indicated.
+-----------+-------------------------------------------+-----------+
| Type | Description | Reference |
| Extension | | |
+-----------+-------------------------------------------+-----------+
| 0 | ICV of an object (e.g., an address) | RFC xxxx |
| 1 | ICV, using a cryptographic function and a | RFC xxxx |
| | hash function, as specified in Section 12 | |
| | of this document | |
| 2 | ICV, using a cryptographic function and a | RFC xxxx |
| | hash function, and including the IP | |
| | datagram source address, as specified in | |
| | Section 12 of this document | |
| 3-251 | Unassigned; Expert Review | |
| 252-255 | Experimental Use | RFC xxxx |
+-----------+-------------------------------------------+-----------+
Table 8: ICV Address Block TLV Type Extensions
More than one ICV Address Block TLV with the same type extension MAY More than one ICV Address Block TLV with the same type extension MAY
be associate with an address if these represent different ICV be associate with an address if these represent different ICV
calculations (e.g., with type extension 1 or 2 and different calculations (e.g., with type extension 1 or 2 and different
cryptographic function and/or hash function, or with a different key cryptographic function and/or hash function, or with a different key
identifier). ICV Address Block TLVs that carry what is declared to identifier). ICV Address Block TLVs that carry what is declared to
be the same information MUST NOT be associated with the same address. be the same information MUST NOT be associated with the same address.
13.10. TIMESTAMP Address Block TLV Type Extensions
IANA has, in accordance with [RFC6622], made allocations from the
"TIMESTAMP Address Block TLV Type Extensions" namespace of [RFC6622]
for the Address Block TLVs specified in Table 9. IANA is requested
to modify this allocation as indicated.
+-----------+-------------------------------------------+-----------+
| Type | Description | Reference |
| Extension | | |
+-----------+-------------------------------------------+-----------+
| 0 | Unsigned timestamp of arbitrary length, | RFC xxxx |
| | given by the TLV Length field. The MANET | |
| | routing protocol has to define how to | |
| | interpret this timestamp | |
| 1 | Unsigned 32-bit timestamp, as specified | RFC xxxx |
| | in [IEEE 1003.1-2008 (POSIX)] | |
| 2 | NTP timestamp format, as specified in | RFC xxxx |
| | [RFC5905] | |
| 3 | Signed timestamp of arbitrary length with | RFC xxxx |
| | no constraints such as monotonicity. In | |
| | particular, it may represent any random | |
| | value | |
| 4-251 | Unassigned; Expert Review | |
| 252-255 | Experimental Use | RFC xxxx |
+-----------+-------------------------------------------+-----------+
Table 9: TIMESTAMP Address Block TLV Type Extensions
More than one TIMESTAMP Address Block TLV with the same type More than one TIMESTAMP Address Block TLV with the same type
extension MUST NOT be associated with any address. extension MUST NOT be associated with any address.
13.5. Hash Functions 13.11. Hash Functions
IANA has, in accordance with [RFC6622], created a registry for hash IANA has, in accordance with [RFC6622], created a registry for hash
functions that can be used when creating an ICV, as specified in functions that can be used when creating an ICV, as specified in
Section 12 of this document. The initial assignments and allocation Section 12 of this document. The initial assignments and allocation
policies are specified in Table 4. This registry is unchanged by policies are specified in Table 10. IANA is requested to modify this
this specification. allocation as indicated.
+-------------+-----------+-----------------------------------------+ +---------+-----------+---------------------------------+-----------+
| Hash | Algorithm | Description | | Value | Algorithm | Description | Reference |
| Function | | | +---------+-----------+---------------------------------+-----------+
| Value | | | | 0 | none | The "identity function": The | RFC xxxx |
+-------------+-----------+-----------------------------------------+ | | | hash value of an object is the | |
| 0 | none | The "identity function": The hash value | | | | object itself | |
| | | of an object is the object itself | | 1 | SHA-1 | [NIST-FIPS-180-4] | RFC xxxx |
| 1 | SHA1 | [NIST-FIPS-180-4] | | 2 | SHA-224 | [NIST-FIPS-180-4] | RFC xxxx |
| 2 | SHA224 | [NIST-FIPS-180-4] | | 3 | SHA-256 | [NIST-FIPS-180-4] | RFC xxxx |
| 3 | SHA256 | [NIST-FIPS-180-4] | | 4 | SHA-384 | [NIST-FIPS-180-4] | RFC xxxx |
| 4 | SHA384 | [NIST-FIPS-180-4] | | 5 | SHA-512 | [NIST-FIPS-180-4] | RFC xxxx |
| 5 | SHA512 | [NIST-FIPS-180-4] | | 6-251 | | Unassigned; Expert Review | |
| 6-251 | | Unassigned; Expert Review | | 252-255 | | Experimental Use | RFC xxxx |
| 252-255 | | Experimental Use | +---------+-----------+---------------------------------+-----------+
+-------------+-----------+-----------------------------------------+
Table 4: Hash Function Registry Table 10: Hash Function Registry
13.6. Cryptographic Functions 13.12. Cryptographic Functions
IANA has, in accordance with [RFC6622], created a registry for the IANA has, in accordance with [RFC6622], created a registry for the
cryptographic functions, as specified in Section 12 of this document. cryptographic functions, as specified in Section 12 of this document.
Initial assignments and allocation policies are specified in Table 5. Initial assignments and allocation policies are specified in
This registry is unchanged by this specification. Table 11. IANA is requested to modify this allocation as indicated.
+----------------+-----------+--------------------------------------+ +---------+-----------+---------------------------------+-----------+
| Cryptographic | Algorithm | Description | | Value | Algorithm | Description | Reference |
| Function Value | | | +---------+-----------+---------------------------------+-----------+
+----------------+-----------+--------------------------------------+ | 0 | none | The "identity function": The | RFC xxxx |
| 0 | none | The "identity function": The value | | | | value of an encrypted hash is | |
| | | of an encrypted hash is the hash | | | | the hash itself | |
| | | itself | | 1 | RSA | [RFC3447] | RFC xxxx |
| 1 | RSA | [RFC3447] | | 2 | DSA | [NIST-FIPS-186-3] | RFC xxxx |
| 2 | DSA | [NIST-FIPS-186-3] | | 3 | HMAC | [RFC2104] | RFC xxxx |
| 3 | HMAC | [RFC2104] | | 4 | 3DES | [NIST-SP-800-67] | RFC xxxx |
| 4 | 3DES | [NIST-SP-800-67] | | 5 | AES-128 | [NIST-FIPS-197] | RFC xxxx |
| 5 | AES | [NIST-FIPS-197] | | 6 | ECDSA | [ANSI-X9-62-2005] | RFC xxxx |
| 6 | ECDSA | [ANSI-X9-62-2005] | | 7-251 | | Unassigned; Expert Review | |
| 7-251 | | Unassigned; Expert Review | | 252-255 | | Experimental Use | RFC xxxx |
| 252-255 | | Experimental Use | +---------+-----------+---------------------------------+-----------+
+----------------+-----------+--------------------------------------+
Table 5: Cryptographic Function Registry Table 11: Cryptographic Function Registry
14. Security Considerations 14. Security Considerations
This document does not specify a protocol. It provides a syntactical This document does not specify a protocol. It provides a syntactical
component for cryptographic ICVs of messages and packets, as defined component for cryptographic ICVs of messages and packets, as defined
in [RFC5444]. It can be used to address security issues of a MANET in [RFC5444]. It can be used to address security issues of a MANET
routing protocol or MANET routing protocol extension. As such, it routing protocol or MANET routing protocol extension. As such, it
has the same security considerations as [RFC5444]. has the same security considerations as [RFC5444].
In addition, a MANET routing protocol or MANET routing protocol In addition, a MANET routing protocol or MANET routing protocol
skipping to change at page 23, line 42 skipping to change at page 27, line 19
Neighborhood Discovery Protocol (NHDP)", Neighborhood Discovery Protocol (NHDP)",
RFC 6130, April 2011. RFC 6130, April 2011.
[RFC6622] Herberg, U. and T. Clausen, "Integrity [RFC6622] Herberg, U. and T. Clausen, "Integrity
Check Value and Timestamp TLV Definitions Check Value and Timestamp TLV Definitions
for Mobile Ad Hoc Networks (MANETs)", for Mobile Ad Hoc Networks (MANETs)",
RFC 6622, May 2012. RFC 6622, May 2012.
[OLSRv2] Clausen, T., Dearlove, C., Jacquet, P., [OLSRv2] Clausen, T., Dearlove, C., Jacquet, P.,
and U. Herberg, "The Optimized Link State and U. Herberg, "The Optimized Link State
Routing Protocol version 2", Work in Routing Protocol version 2", work in
Progress draft-ietf-manet-olsrv2-19, progress draft-ietf-manet-olsrv2-19,
March 2013. 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
 End of changes. 44 change blocks. 
227 lines changed or deleted 342 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/