draft-ietf-manet-rfc6622-bis-03.txt   draft-ietf-manet-rfc6622-bis-04.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: January 3, 2014 C. Dearlove Expires: January 31, 2014 C. Dearlove
BAE Systems ATC BAE Systems ATC
July 2, 2013 July 30, 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-03 draft-ietf-manet-rfc6622-bis-04
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 January 3, 2014. This Internet-Draft will expire on January 31, 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 3, line 10 skipping to change at page 3, line 10
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Differences from RFC6622 . . . . . . . . . . . . . . . . 4 1.1. Differences from RFC6622 . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 5 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 6
4. Security Architecture . . . . . . . . . . . . . . . . . . . . 6 4. Security Architecture . . . . . . . . . . . . . . . . . . . . 6
5. Overview and Functioning . . . . . . . . . . . . . . . . . . . 7 5. Overview and Functioning . . . . . . . . . . . . . . . . . . . 7
6. General ICV TLV Structure . . . . . . . . . . . . . . . . . . 8 6. General ICV TLV Structure . . . . . . . . . . . . . . . . . . 8
7. General Timestamp TLV Structure . . . . . . . . . . . . . . . 8 7. General Timestamp TLV Structure . . . . . . . . . . . . . . . 9
8. Packet TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Packet TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. ICV Packet TLV . . . . . . . . . . . . . . . . . . . . . 9 8.1. ICV Packet TLV . . . . . . . . . . . . . . . . . . . . . 9
8.2. TIMESTAMP Packet TLV . . . . . . . . . . . . . . . . . . 10 8.2. TIMESTAMP Packet TLV . . . . . . . . . . . . . . . . . . 10
9. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. ICV Message TLV . . . . . . . . . . . . . . . . . . . . . 10 9.1. ICV Message TLV . . . . . . . . . . . . . . . . . . . . . 11
9.2. TIMESTAMP Message TLV . . . . . . . . . . . . . . . . . . 11 9.2. TIMESTAMP Message TLV . . . . . . . . . . . . . . . . . . 11
10. Address Block TLVs . . . . . . . . . . . . . . . . . . . . . . 11 10. Address Block TLVs . . . . . . . . . . . . . . . . . . . . . . 11
10.1. ICV Address Block TLV . . . . . . . . . . . . . . . . . . 11 10.1. ICV Address Block TLV . . . . . . . . . . . . . . . . . . 11
10.2. TIMESTAMP Address Block TLV . . . . . . . . . . . . . . . 11 10.2. TIMESTAMP Address Block TLV . . . . . . . . . . . . . . . 12
11. ICV: Basic . . . . . . . . . . . . . . . . . . . . . . . . . . 12 11. ICV: Basic . . . . . . . . . . . . . . . . . . . . . . . . . . 12
12. ICV: Hash Function and Cryptographic Function . . . . . . . . 12 12. ICV: Hash Function and Cryptographic Function . . . . . . . . 12
12.1. General ICV TLV Structure . . . . . . . . . . . . . . . . 12 12.1. General ICV TLV Structure . . . . . . . . . . . . . . . . 13
12.1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . 14 12.1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . 14
12.2. Considerations for Calculating the ICV . . . . . . . . . 14 12.2. Considerations for Calculating the ICV . . . . . . . . . 14
12.2.1. Packet ICV TLV . . . . . . . . . . . . . . . . . . . 14 12.2.1. ICV Packet TLV . . . . . . . . . . . . . . . . . . . 15
12.2.2. Message ICV TLV . . . . . . . . . . . . . . . . . . . 15 12.2.2. ICV Message TLV . . . . . . . . . . . . . . . . . . . 15
12.2.3. Address Block ICV TLV . . . . . . . . . . . . . . . . 15 12.2.3. ICV Address Block TLV . . . . . . . . . . . . . . . . 16
12.3. Example of a Message Including an ICV . . . . . . . . . . 16 12.3. Example of a Message Including an ICV . . . . . . . . . . 16
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
13.1. Expert Review: Evaluation Guidelines . . . . . . . . . . 17 13.1. Expert Review: Evaluation Guidelines . . . . . . . . . . 18
13.2. Packet TLV Types . . . . . . . . . . . . . . . . . . . . 17 13.2. Packet TLV Types . . . . . . . . . . . . . . . . . . . . 18
13.3. Message TLV Types . . . . . . . . . . . . . . . . . . . . 18 13.3. Message TLV Types . . . . . . . . . . . . . . . . . . . . 18
13.4. Address Block TLV Types . . . . . . . . . . . . . . . . . 18 13.4. Address Block TLV Types . . . . . . . . . . . . . . . . . 19
13.5. ICV Packet TLV Type Extensions . . . . . . . . . . . . . 18 13.5. ICV Packet TLV Type Extensions . . . . . . . . . . . . . 19
13.6. TIMESTAMP Packet TLV Type Extensions . . . . . . . . . . 19 13.6. TIMESTAMP Packet TLV Type Extensions . . . . . . . . . . 20
13.7. ICV Message TLV Type Extensions . . . . . . . . . . . . . 20 13.7. ICV Message TLV Type Extensions . . . . . . . . . . . . . 21
13.8. TIMESTAMP Message TLV Type Extensions . . . . . . . . . . 21 13.8. TIMESTAMP Message TLV Type Extensions . . . . . . . . . . 22
13.9. ICV Address Block TLV Type Extensions . . . . . . . . . . 21 13.9. ICV Address Block TLV Type Extensions . . . . . . . . . . 22
13.10. TIMESTAMP Address Block TLV Type Extensions . . . . . . . 22 13.10. TIMESTAMP Address Block TLV Type Extensions . . . . . . . 23
13.11. Hash Functions . . . . . . . . . . . . . . . . . . . . . 23 13.11. Hash Functions . . . . . . . . . . . . . . . . . . . . . 24
13.12. Cryptographic Functions . . . . . . . . . . . . . . . . . 24 13.12. Cryptographic Functions . . . . . . . . . . . . . . . . . 25
14. Security Considerations . . . . . . . . . . . . . . . . . . . 24 14. Security Considerations . . . . . . . . . . . . . . . . . . . 25
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
16.1. Normative References . . . . . . . . . . . . . . . . . . 25 16.1. Normative References . . . . . . . . . . . . . . . . . . 26
16.2. Informative References . . . . . . . . . . . . . . . . . 27 16.2. Informative References . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
[RFC Editor note: Please replace "xxxx" throughout this document with [RFC Editor note: Please replace "xxxx" throughout this document with
the RFC number assigned to this document, and remove this note.] 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 sets up IANA registrations of TLV types and type
[RFC6622]) of TLV types and type extension registries for these TLV extension registries for these TLV types. This specification does
types. This specification does not represent a stand-alone protocol, not represent a stand-alone protocol, but is intended for use by
but is intended for use by MANET routing protocols, or security 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 o IANA registrations for TLVs, and registries for TLV Type
recording code points for ICV calculations, and requests an Extensions, replacing those from [RFC6622].
additional allocation from each these registries. This document
retains the IANA registries, defined in [RFC6622], for recording code This document sets up IANA registries for recording code points for
points for timestamps, hash-functions, and cryptographic functions, ICV TLVs and TIMESTAMP TLVs, as well as timestamps, hash-functions,
but does not request any additional allocations from these and cryptographic functions.
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], replacing that document as the This document obsoletes [RFC6622], replacing that document as the
skipping to change at page 5, line 17 skipping to change at page 5, line 14
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 This document also incorporates a number of editorial improvements
over [RFC6622]. In particular, it makes it clear that an ICV TLV may 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 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. TIMESTAMP or ICV Address Block TLV may cover more than one address.
Moreover, to be consistent with the terminology in [RFC5444], the
name of the TLVs specified in this document have changed from "Packet
ICV TLV" to "ICV Packet TLV" and from "Packet TIMESTAMP TLV" to
"TIMESTAMP Packet TLV" (and similar for Message and Address Block
TLVs).
A normative requirement in Section 9.2 has changed from SHOULD to
MUST in the following sentence: "If a message contains one or more
TIMESTAMP TLVs and one or more ICV TLVs, then the TIMESTAMP TLVs (as
well as any other Message TLVs) MUST be added to the message before
the ICV TLVs (...)".
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]
skipping to change at page 6, line 20 skipping to change at page 6, line 28
Block, and "mutable" fields, specifically the <msg-hop-count> and Block, and "mutable" fields, specifically the <msg-hop-count> and
<msg-hop-limit> fields, if present in the Message Header when <msg-hop-limit> fields, if present in the Message Header when
calculating ICVs, such that the resulting ICV can be correctly calculating ICVs, such that the resulting ICV can be correctly
verified by any recipient. verified by any recipient.
This document describes a generic framework for creating ICVs, and This document describes a generic framework for creating ICVs, and
how to include these ICVs in TLVs. In Section 12, an example method how to include these ICVs in TLVs. In Section 12, an example method
for calculating such ICVs is given, using a cryptographic function for calculating such ICVs is given, using a cryptographic function
and a hash function, for which two TLV type extensions are allocated. and a hash function, for which two TLV type extensions are allocated.
This document does not specify a protocol. Protocol specifications
that make use of the framework, specified in this document, will
reference this document in a normative way, and may require the
implementation of some or all of the algorithms described in this
document. As this document does not specify a protocol itself, key
management and key exchange mechanisms are out of scope, and may be
specified in the protocol or protocol extension using this
specification.
4. Security Architecture 4. Security Architecture
MANET routing protocol specifications may have a clause allowing a MANET routing protocol specifications may have a clause allowing a
control message to be rejected as "badly formed" or "insecure" prior control message to be rejected as "badly formed" or "insecure" prior
to the message being processed or forwarded. In particular, MANET to the message being processed or forwarded. In particular, MANET
routing protocols such as the Neighborhood Discovery Protocol (NHDP) routing protocols such as the Neighborhood Discovery Protocol (NHDP)
[RFC6130] and the Optimized Link State Routing Protocol version 2 [RFC6130] and the Optimized Link State Routing Protocol version 2
[OLSRv2] recognize external reasons (such as failure to verify an [OLSRv2] recognize external reasons (such as failure to verify an
ICV) for rejecting a message that would be considered "invalid for ICV) for rejecting a message that would be considered "invalid for
processing". processing".
skipping to change at page 7, line 16 skipping to change at page 7, line 30
specification of such MANET routing protocol security extensions. specification of such MANET routing protocol security extensions.
This document addresses the last of the points above, by specifying a This document addresses the last of the points above, by specifying a
common exchange format for cryptographic ICVs and timestamps, making common exchange format for cryptographic ICVs and timestamps, making
reservations from within the Packet TLV, Message TLV, and Address reservations from within the Packet TLV, Message TLV, and Address
Block TLV registries of [RFC5444], to be used by (and shared among) Block TLV registries of [RFC5444], to be used by (and shared among)
MANET routing protocol security extensions. MANET routing protocol security extensions.
For the specific decomposition of an ICV using a cryptographic For the specific decomposition of an ICV using a cryptographic
function and a hash function (specified in Section 12), this document function and a hash function (specified in Section 12), this document
reports the two IANA registries from [RFC6622] for code points for sets up two IANA registries (see Section 13) for code points for hash
hash functions and cryptographic functions. functions and cryptographic functions.
With respect to [RFC5444], this document is: With respect to [RFC5444], this document is:
o Intended to be used in the non-normative, but intended, mode of o Intended to be used in the non-normative, but intended, mode of
use described in Appendix B of [RFC5444]. use described in Appendix B of [RFC5444].
o A specific example of the Security Considerations section of o A specific example of the Security Considerations section of
[RFC5444] (the authentication part). [RFC5444] (the authentication part).
5. Overview and Functioning 5. Overview and Functioning
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 sets up IANA registrations (see Section 13) of TLV
[RFC6622]) of TLV types and type extension registries for these TLV types and type extension registries for these TLV types.
types.
Moreover, this document provides guidelines for how MANET routing Moreover, this document provides guidelines for how MANET routing
protocols, and MANET routing protocol extensions using this protocols, and MANET routing protocol extensions using this
specification, should treat ICV and Timestamp TLVs, and mutable specification, should treat ICV and Timestamp TLVs, and mutable
fields in messages. This specification does not represent a stand- fields in messages. This specification does not represent a stand-
alone protocol. MANET routing protocols, and MANET routing protocol alone protocol. MANET routing protocols, and MANET routing protocol
extensions using this specification, MUST provide instructions as to extensions using this specification, MUST provide instructions as to
how to handle packets, messages, and addresses with security how to handle packets, messages, and addresses with security
information, associated as specified in this document. information, associated as specified in this document.
This document reports previously assigned TLV types (from [RFC6622]) This document sets up TLV type assignments (see Section 13) from the
from the registries defined for Packet, Message, and Address Block registries defined for Packet, Message, and Address Block TLVs in
TLVs in [RFC5444]. When a TLV type is assigned from one of these [RFC5444]. When a TLV type is assigned from one of these registries,
registries, a registry for type extensions for that TLV type is a registry for type extensions for that TLV type is created by IANA.
created by IANA. This document reports and updates these type This document sets up these type extension registries, in order to
extension registries, in order to specify internal structure (and specify internal structure (and accompanying processing) of the
accompanying processing) of the <value> field of a TLV. <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 (added in this document) is the same as TLV with type extension = 2 (added in this document) is the same as
an ICV TLV with type extension = 1, except that the integrity an ICV TLV with type extension = 1, except that the integrity
protection also covers the source address of the IP datagram carrying protection also covers the source address of the IP datagram carrying
the packet, message, or Address Block. the packet, message, or Address Block.
skipping to change at page 9, line 42 skipping to change at page 10, line 10
An ICV Packet TLV is an example of an ICV TLV as described in An ICV Packet TLV is an example of an ICV TLV as described in
Section 6. When determining the <ICV-value> for a packet, and adding Section 6. When determining the <ICV-value> for a packet, and adding
an ICV Packet TLV to a packet, the following considerations MUST be an ICV Packet TLV to a packet, the following considerations MUST be
applied: applied:
o Because packets as defined in [RFC5444] are never forwarded by o Because packets as defined in [RFC5444] are never forwarded by
routers, no special considerations are required regarding mutable routers, no special considerations are required regarding mutable
fields (i.e., <msg-hop-count> and <msg-hop-limit>), if present fields (i.e., <msg-hop-count> and <msg-hop-limit>), if present
within any messages in the packet, when calculating the ICV. within any messages in the packet, when calculating the ICV.
o Any Packet ICV TLVs already present in the Packet TLV Block MUST o Any ICV Packet TLVs already present in the Packet TLV Block MUST
be removed before calculating the ICV, and the Packet TLV Block be removed before calculating the ICV, and the Packet TLV Block
size MUST be recalculated accordingly. size MUST be recalculated accordingly.
o If the Packet TLV Block now contains no Packet TLVs, the Packet o If the Packet TLV Block now contains no Packet TLVs, the Packet
TLV Block MUST be removed, and the phastlv bit in the <pkt-flags> TLV Block MUST be removed, and the phastlv bit in the <pkt-flags>
field in the Packet Header MUST be cleared ('0'). field in the Packet Header MUST be cleared ('0').
o Any removed ICV Packet TLVs MUST be restored after having o Any removed ICV Packet TLVs MUST be restored after having
calculated the ICV, and the Packet TLV Block size MUST be calculated the ICV, and the Packet TLV Block size MUST be
recalculated accordingly. recalculated accordingly.
o When any removed ICV Packet TLVs, and the newly calculated ICV o When any removed ICV Packet TLVs, and the newly calculated ICV
Packet TLV, are added to the packet, if there is no Packet TLV Packet TLV, are added to the packet, if there is no Packet TLV
Block then one MUST be added, including setting ('1') the phastlv Block then one MUST be added, including setting ('1') the phastlv
bit in the <pkt-flags> field in the Packet Header. bit in the <pkt-flags> field in the Packet Header.
The rationale for removing any Packet ICV TLVs already present prior The rationale for removing any ICV Packet TLVs already present prior
to calculating the ICV is that several ICV TLVs may be added to the to calculating the ICV is that several ICV TLVs may be added to the
same packet, e.g., using different ICV cryptographic and/or hash same packet, e.g., using different ICV cryptographic and/or hash
functions. The rationale for removing an empty Packet TLV Block is functions. The rationale for removing an empty Packet TLV Block is
because the receiver of the packet cannot tell the difference between because the receiver of the packet cannot tell the difference between
what was an absent Packet TLV Block, and what was an empty Packet TLV what was an absent Packet TLV Block, and what was an empty Packet TLV
Block when removing and verifying the ICV Packet TLV if no other Block when removing and verifying the ICV Packet TLV if no other
Packet TLVs are present. Packet TLVs are present.
8.2. TIMESTAMP Packet TLV 8.2. TIMESTAMP Packet TLV
skipping to change at page 10, line 44 skipping to change at page 11, line 15
9.1. ICV Message TLV 9.1. ICV Message TLV
An ICV Message TLV is an example of an ICV TLV as described in An ICV Message TLV is an example of an ICV TLV as described in
Section 6. When determining the <ICV-value> for a message, the Section 6. When determining the <ICV-value> for a message, the
following considerations MUST be applied: following considerations MUST be applied:
o The fields <msg-hop-limit> and <msg-hop-count>, if present in the o The fields <msg-hop-limit> and <msg-hop-count>, if present in the
Message Header, MUST both be assumed to have the value 0 (zero) Message Header, MUST both be assumed to have the value 0 (zero)
when calculating the ICV. when calculating the ICV.
o Any Message ICV TLVs already present in the Message TLV Block MUST o Any ICV Message TLVs already present in the Message TLV Block MUST
be removed before calculating the ICV, and the message size as be removed before calculating the ICV, and the message size as
well as the Message TLV Block size MUST be recalculated well as the Message TLV Block size MUST be recalculated
accordingly. Also, all relevant TLVs other than ICV TLVs MUST be accordingly. Also, all relevant TLVs other than ICV TLVs MUST be
added prior to TCV value calculation. added prior to TCV value calculation.
o Any removed ICV Message TLVs MUST be restored after having o Any removed ICV Message TLVs MUST be restored after having
calculated the ICV, and the message size as well as the Message calculated the ICV, and the message size as well as the Message
TLV Block size MUST be recalculated accordingly. TLV Block size MUST be recalculated accordingly.
The rationale for removing any ICV Message TLVs already present prior The rationale for removing any ICV Message TLVs already present prior
skipping to change at page 11, line 32 skipping to change at page 11, line 52
cryptographic ICV to one or more addresses and their associated cryptographic ICV to one or more addresses and their associated
information, and one for including the timestamp indicating the time information, and one for including the timestamp indicating the time
at which the cryptographic ICV was calculated. at which the cryptographic ICV was calculated.
10.1. ICV Address Block TLV 10.1. ICV Address Block TLV
An ICV Address Block TLV is an example of an ICV TLV as described in An ICV Address Block TLV is an example of an ICV TLV as described in
Section 6. The ICV is calculated over one or more addresses, Section 6. The ICV is calculated over one or more addresses,
concatenated with any other values -- for example, other Address concatenated with any other values -- for example, other Address
Block TLV <value> fields -- associated with those addresses. A MANET Block TLV <value> fields -- associated with those addresses. A MANET
routing protocol, or MANET routing protocol extension, using Address routing protocol, or MANET routing protocol extension, using ICV
Block ICV TLVs MUST specify how to include any such concatenated Address Block TLVs MUST specify how to include any such concatenated
attributes of the addresses in the calculation and verification attributes of the addresses in the calculation and verification
processes for the ICV. When determining an <ICV-value> for one or processes for the ICV. When determining an <ICV-value> for one or
more addresses, the following consideration MUST be applied: more addresses, the following consideration MUST be applied:
o If other TLV values are concatenated with the addresses for o If other TLV values are concatenated with the addresses for
calculating the ICV, the corresponding TLVs MUST NOT be ICV calculating the ICV, the corresponding TLVs MUST NOT be ICV
Address Block TLVs already associated with any of the addresses. Address Block TLVs already associated with any of the addresses.
The rationale for not concatenating the addresses with any ICV TLV The rationale for not concatenating the addresses with any ICV TLV
values already associated with the addresses when calculating the ICV values already associated with the addresses when calculating the ICV
skipping to change at page 13, line 50 skipping to change at page 14, line 18
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
truncation SHOULD be as specified for the relevant cryptographic truncation SHOULD be as specified for the relevant cryptographic
function (and, if appropriate, hash function). function (and, if appropriate, hash function).
The hash function and the cryptographic function correspond to the The hash function and the cryptographic function correspond to the
entries in two IANA registries, which are reported by this entries in two IANA registries, which are described in Section 13.
specification and are described in Section 13.
12.1.1. Rationale 12.1.1. Rationale
The rationale for separating the hash function and the cryptographic The rationale for separating the hash function and the cryptographic
function into two octets instead of having all combinations in a function into two octets instead of having all combinations in a
single octet -- possibly as a TLV type extension -- is that adding single octet -- possibly as a TLV type extension -- is that adding
further hash functions or cryptographic functions in the future may further hash functions or cryptographic functions in the future may
lead to a non-contiguous number space, as well as providing a smaller lead to a non-contiguous number space, as well as providing a smaller
overall space. overall space.
skipping to change at page 14, line 35 skipping to change at page 15, line 5
only ever travel one hop) and messages (and their Address Blocks) only ever travel one hop) and messages (and their Address Blocks)
that only travel one hop. It is not applicable to messages that may that only travel one hop. It is not applicable to messages that may
be forwarded more than one hop, such as TC messages in [OLSRv2]. be forwarded more than one hop, such as TC messages in [OLSRv2].
12.2. Considerations for Calculating the ICV 12.2. Considerations for Calculating the ICV
The considerations listed in the following subsections MUST be The considerations listed in the following subsections MUST be
applied when calculating the ICV for Packet, Message, and Address applied when calculating the ICV for Packet, Message, and Address
Block TLVs, respectively. Block TLVs, respectively.
12.2.1. Packet ICV TLV 12.2.1. ICV Packet TLV
When determining the <ICV-data> for a packet, with type extension = When determining the <ICV-data> for a packet, 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 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.
skipping to change at page 15, line 9 skipping to change at page 15, line 28
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 data used consists of a representation of the source address the data used consists of a representation of the source address
of the IP datagram carrying the packet, followed by the remaining of the IP datagram carrying the packet, followed by the remaining
data (as for type extension = 1). The representation of the data (as for type extension = 1). The representation of the
source address consists of a single octet containing the address source address consists of a single octet containing the address
length, in octets, followed by that many octets containing the length, in octets, followed by that many octets containing the
address in network byte order. address in network byte order.
12.2.2. Message ICV TLV 12.2.2. ICV Message 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 data used consists of a representation of the source address the data used consists of a representation of the source address
of the IP datagram carrying the message, followed by the remaining of the IP datagram carrying the message, followed by the remaining
data (as for type extension = 1). The representation of the data (as for type extension = 1). The representation of the
source address consists of a single octet containing the address source address consists of a single octet containing the address
length, in octets, followed by that many octets containing the length, in octets, followed by that many octets containing the
address in network byte order. address in network byte order.
12.2.3. Address Block ICV TLV 12.2.3. ICV Address Block 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
<value>s that are associated with those addresses. A MANET <value>s that are associated with those addresses. A MANET
routing protocol, or MANET routing protocol extension, using ICV routing protocol, or MANET routing protocol extension, using ICV
skipping to change at page 16, line 49 skipping to change at page 17, line 35
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICV Value (cont) | | ICV Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICV Value (cont) | | ICV Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Example Message with ICV Figure 1: Example Message with ICV
13. IANA Considerations 13. IANA Considerations
This specification reports the following, originally specified in The IANA registrations for TLV Types and the TLV Type Extension
[RFC6622]: registries given in this specification replace the identical
registrations and registries from [RFC6622].
This specification defines the following TLV Types, replacing the
original specifications in [RFC6622]:
o Two Packet TLV Types, which have been allocated from the 0-223 o Two Packet TLV Types, which have been allocated from the 0-223
range of the "Packet TLV Types" repository of [RFC5444], as range of the "Packet TLV Types" repository of [RFC5444], as
specified in Table 1. specified in Table 1.
o Two Message TLV Types, which have been allocated from the 0-127 o Two Message TLV Types, which have been allocated from the 0-127
range of the "Message TLV Types" repository of [RFC5444], as range of the "Message TLV Types" repository of [RFC5444], as
specified in Table 2. specified in Table 2.
o Two Address Block TLV Types, which have been allocated from the o Two Address Block TLV Types, which have been allocated from the
0-127 range of the "Address Block TLV Types" repository of 0-127 range of the "Address Block TLV Types" repository of
[RFC5444], as specified in Table 3. [RFC5444], as specified in Table 3.
This specification updates the following, created in [RFC6622]: This specification updates the following registries that were created
in [RFC6622]:
o A type extension registry for each of these TLV types with values o A type extension registry for each of these TLV types with values
as listed in Tables 1, 2, and 3. as listed in Tables 1, 2, and 3.
The following terms are used as defined in [BCP26]: "Namespace", The following terms are used as defined in [BCP26]: "Namespace",
"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
 End of changes. 29 change blocks. 
67 lines changed or deleted 87 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/