draft-ietf-manet-rfc6622-bis-06.txt   rfc7182.txt 
Mobile Ad hoc Networking (MANET) U. Herberg Internet Engineering Task Force (IETF) U. Herberg
Internet-Draft Fujitsu Laboratories of America Request for Comments: 7182 Fujitsu Laboratories of America
Obsoletes: 6622 (if approved) T. Clausen Obsoletes: 6622 T. Clausen
Intended status: Standards Track LIX, Ecole Polytechnique Category: Standards Track LIX, Ecole Polytechnique
Expires: May 19, 2014 C. Dearlove ISSN: 2070-1721 C. Dearlove
BAE Systems ATC BAE Systems ATC
November 15, 2013 April 2014
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-06
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.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on May 19, 2014. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7182.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................3
1.1. Differences from RFC6622 . . . . . . . . . . . . . . . . 4 1.1. Differences from RFC 6622 ..................................4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology .....................................................4
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 6 3. Applicability Statement .........................................5
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 . . . . . . . . . . . . . . . 9 7. General Timestamp TLV Structure .................................8
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 . . . . . . . . . . . . . . . . . . . . . 11 9.1. ICV Message TLV ...........................................10
9.2. TIMESTAMP Message TLV . . . . . . . . . . . . . . . . . . 11 9.2. TIMESTAMP Message TLV .....................................10
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 . . . . . . . . . . . . . . . 12 10.2. TIMESTAMP Address Block TLV ..............................11
11. ICV: Basic . . . . . . . . . . . . . . . . . . . . . . . . . . 12 11. ICV: Basic ....................................................11
12. ICV: Hash Function and Cryptographic Function . . . . . . . . 13 12. ICV: Hash Function and Cryptographic Function .................12
12.1. General ICV TLV Structure . . . . . . . . . . . . . . . . 13 12.1. General ICV TLV Structure ................................12
12.1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . 15 12.1.1. Rationale .........................................14
12.1.2. Parameters . . . . . . . . . . . . . . . . . . . . . 15 12.1.2. Parameters ........................................15
12.2. Considerations for Calculating the ICV . . . . . . . . . 16 12.2. Considerations for Calculating the ICV ...................15
12.2.1. ICV Packet TLV . . . . . . . . . . . . . . . . . . . 16 12.2.1. ICV Packet TLV ....................................15
12.2.2. ICV Message TLV . . . . . . . . . . . . . . . . . . . 17 12.2.2. ICV Message TLV ...................................16
12.2.3. ICV Address Block TLV . . . . . . . . . . . . . . . . 17 12.2.3. ICV Address Block TLV .............................16
12.3. Example of a Message Including an ICV . . . . . . . . . . 18 12.3. Example of a Message Including an ICV ....................17
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 13. IANA Considerations ...........................................19
13.1. Expert Review: Evaluation Guidelines . . . . . . . . . . 19 13.1. Expert Review: Evaluation Guidelines .....................19
13.2. Packet TLV Types . . . . . . . . . . . . . . . . . . . . 19 13.2. Packet TLV Types .........................................20
13.3. Message TLV Types . . . . . . . . . . . . . . . . . . . . 20 13.3. Message TLV Types ........................................20
13.4. Address Block TLV Types . . . . . . . . . . . . . . . . . 20 13.4. Address Block TLV Types ..................................20
13.5. ICV Packet TLV Type Extensions . . . . . . . . . . . . . 20 13.5. ICV Packet TLV Type Extensions ...........................21
13.6. TIMESTAMP Packet TLV Type Extensions . . . . . . . . . . 21 13.6. TIMESTAMP Packet TLV Type Extensions .....................21
13.7. ICV Message TLV Type Extensions . . . . . . . . . . . . . 22 13.7. ICV Message TLV Type Extensions ..........................22
13.8. TIMESTAMP Message TLV Type Extensions . . . . . . . . . . 23 13.8. TIMESTAMP Message TLV Type Extensions ....................23
13.9. ICV Address Block TLV Type Extensions . . . . . . . . . . 23 13.9. ICV Address Block TLV Type Extensions ....................24
13.10. TIMESTAMP Address Block TLV Type Extensions . . . . . . . 24 13.10. TIMESTAMP Address Block TLV Type Extensions .............25
13.11. Hash Functions . . . . . . . . . . . . . . . . . . . . . 25 13.11. Hash Functions ..........................................26
13.12. Cryptographic Functions . . . . . . . . . . . . . . . . . 26 13.12. Cryptographic Functions .................................27
14. Security Considerations . . . . . . . . . . . . . . . . . . . 26 14. Security Considerations .......................................28
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 15. Acknowledgements ..............................................28
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 16. References ....................................................29
16.1. Normative References . . . . . . . . . . . . . . . . . . 27 16.1. Normative References .....................................29
16.2. Informative References . . . . . . . . . . . . . . . . . 29 16.2. Informative References ...................................30
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 specifies IANA registrations of TLV types and type packets. It also specifies IANA registrations of TLV types and type
extension registries for these TLV types. This specification does extension registries for these TLV types. This specification does
not represent a stand-alone protocol, but is intended for use by not represent a stand-alone protocol, but it is intended for use by
MANET routing protocols, or security extensions thereof. MANET routing protocols or security 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.
o IANA registrations for TLVs, and registries for TLV Type o IANA registrations for TLVs, and registries for TLV type
Extensions, replacing those from [RFC6622]. extensions, replacing those from [RFC6622].
This document specifies IANA registries for recording code points for This document specifies IANA registries for recording code points for
ICV TLVs and TIMESTAMP TLVs, as well as timestamps, hash-functions, ICV TLVs and TIMESTAMP TLVs, as well as timestamps, hash functions,
and cryptographic functions. and cryptographic functions.
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 RFC 6622
This document obsoletes [RFC6622], replacing that document as the This document obsoletes [RFC6622], replacing that document as the
specification of two TLV types, TIMESTAMP and ICV, for packets, specification of two TLV types, TIMESTAMP and ICV, for packets,
messages and address blocks. For the ICV type, this document messages and Address Blocks. For the ICV type, this document
specifies a new type extension, 2 (see Section 12), in addition to specifies a new type extension, 2 (see Section 12), in addition to
including the original type extensions (0 and 1) from [RFC6622]. including the original type extensions (0 and 1) from [RFC6622].
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,
or Address Block, e.g., to identify links with neighbor routers. If message, or Address Block, e.g., to identify links with neighbor
this address is not otherwise contained in the packet, message, or routers. If this address is not otherwise contained in the packet,
Address Block payload (which is permitted, e.g., in [RFC6130]), then message, or Address Block payload (which is permitted, e.g., in
the address is not protected against tampering. [RFC6130]), then 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 multivalue
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 Moreover, to be consistent with the terminology in [RFC5444], the
name of the TLVs specified in this document have changed from "Packet name of the TLVs specified in this document have changed from "Packet
ICV TLV" to "ICV Packet TLV" and from "Packet TIMESTAMP TLV" to ICV TLV" to "ICV Packet TLV" and from "Packet TIMESTAMP TLV" to
"TIMESTAMP Packet TLV" (and similar for Message and Address Block "TIMESTAMP Packet TLV" (and similar for Message and Address Block
TLVs). TLVs).
A normative requirement in Section 9.2 has changed from SHOULD to A normative requirement in Section 9.2 has changed from SHOULD to
MUST in the following sentence: "If a message contains one or more MUST in the following sentence:
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 If a message contains one or more TIMESTAMP TLVs and one or more
the ICV TLVs (...)". 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 5, line 50 skipping to change at page 5, line 22
<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 In addition to using the regular expressions defined in Section 2.1.1
[RFC5444] this document defines: of [RFC5444], this document defines the following:
+ - One or more occurrences of the preceding element or group. + - 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 an Address Block within a message, using
TLVs. This document also specifies how to treat an empty Packet TLV such TLVs. This document also specifies how to treat an empty Packet
Block, and "mutable" fields, specifically the <msg-hop-count> and TLV 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 This document does not specify a protocol. Protocol specifications
that make use of the framework, specified in this document, will that make use of the framework, specified in this document, will
reference this document in a normative way, and may require the reference this document in a normative way, and they may require the
implementation of some or all of the algorithms described in this implementation of some or all of the algorithms described in this
document. As this document does not specify a protocol itself, key document. As this document does not specify a protocol itself, key
management and key exchange mechanisms are out of scope, and may be management and key exchange mechanisms are out of scope and may be
specified in the protocol or protocol extension using this specified in the protocol or protocol extension using this
specification. 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 [RFC7181] 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".
This architecture is a result of the observation that with respect to This architecture is a result of the observation that with respect to
security in MANETs, "one size rarely fits all" and that MANET routing security in MANETs, "one size rarely fits all" and that MANET routing
protocol deployment domains have varying security requirements protocol deployment domains have varying security requirements
ranging from "unbreakable" to "virtually none". The virtue of this ranging from "unbreakable" to "virtually none". The virtue of this
approach is that MANET routing protocol specifications (and approach is that MANET routing protocol specifications (and
implementations) can remain "generic", with extensions providing implementations) can remain "generic", with extensions providing
proper security mechanisms specific to a deployment domain. proper security mechanisms specific to a deployment domain.
skipping to change at page 8, line 17 skipping to change at page 7, line 37
information, associated as specified in this document. information, associated as specified in this document.
This document specifies TLV type assignments (see Section 13) from This document specifies TLV type assignments (see Section 13) from
the registries defined for Packet, Message, and Address Block TLVs in the registries defined for Packet, Message, and Address Block TLVs in
[RFC5444]. When a TLV type is assigned from one of these registries, [RFC5444]. When a TLV type is assigned from one of these registries,
a registry for type extensions for that TLV type is created by IANA. a registry for type extensions for that TLV type is created by IANA.
This document specifies these type extension registries, in order to This document specifies these type extension registries, in order to
specify internal structure (and accompanying processing) of the specify internal structure (and 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 specified 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 predefined
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
defined internal structure and defines its interpretation. An ICV predefined 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.
Specifically, with type extension = 1 or type extension = 2, the Specifically, with type extension = 1 or type extension = 2, the
<value> field contains the result of combining a cryptographic <value> field contains the result of combining a cryptographic
function and a hash function, calculated over the contents of the function and a hash function, calculated over the contents of the
packet, message, or Address Block. The <value> field contains sub- packet, message, or Address Block. The <value> field contains sub-
fields indicating which hash function and cryptographic function have fields indicating which hash function and cryptographic function have
skipping to change at page 8, line 46 skipping to change at page 8, line 17
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>+
where: where:
<ICV-value> is a field, of length <length> octets (except in a <ICV-value> is a field, of length <length> octets (except in a
multivalue Address Block TLV, where each <ICV-value> is of length multivalue Address Block TLV, where each <ICV-value> is of length
single-length octets) that contains the information to be single-length octets) that contains the information to be
interpreted by the ICV verification process, as specified by the interpreted by the ICV verification process, as specified by the
type extension. type extension.
Note that this does not specify how to calculate the <ICV-value> nor Note that this does not specify how to calculate the <ICV-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 ICV TLV type; see Section 13. specified by the type extension for the ICV TLV type; see Section 13.
This document specifies three such type extensions -- one for ICVs This document specifies three such type extensions: one for ICVs
without pre-defined structures, and two for ICVs constructed without predefined structures and two for ICVs constructed combining
combining a cryptographic function and a hash function. a cryptographic function and a hash function.
7. General Timestamp TLV Structure 7. General Timestamp TLV Structure
The value of the Timestamp TLV is: The value of the Timestamp TLV is:
<value> := <time-value>+ <value> := <time-value>+
where: where:
<time-value> is a field, of length <length> octets (except in a <time-value> is a field, of length <length> octets (except in a
multivalue Address Block TLV, where each <time-value> is of length multivalue Address Block TLV, where each <time-value> is of length
single-length octets) that contains the timestamp. single-length octets) that contains the timestamp.
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
skipping to change at page 10, line 24 skipping to change at page 9, line 40
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 ICV Packet 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.
skipping to change at page 11, line 19 skipping to change at page 10, line 34
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 ICV Message 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 ICV 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
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 message, e.g., using different ICV cryptographic and/or hash same message, e.g., using different ICV cryptographic and/or hash
functions. functions.
skipping to change at page 11, line 43 skipping to change at page 11, line 9
in Section 7. If a message contains one or more TIMESTAMP TLVs and in Section 7. If a message contains one or more TIMESTAMP TLVs and
one or more ICV TLVs, then the TIMESTAMP TLVs (as well as any other 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, in Message TLVs) MUST be added to the message before the ICV TLVs, in
order to include the timestamps and other Message TLVs in the order to include the timestamps and other Message TLVs in the
calculation of the ICV. calculation of the ICV.
10. Address Block TLVs 10. Address Block TLVs
Two Address Block TLVs are defined: one for associating a Two Address Block TLVs are defined: one for associating a
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 ICV routing protocol, or MANET routing protocol extension, using ICV
Address Block TLVs MUST specify how to include any such concatenated Address Block TLVs MUST specify how to include any such concatenated
skipping to change at page 12, line 31 skipping to change at page 11, line 46
A TIMESTAMP Address Block TLV is an example of a Timestamp TLV as A TIMESTAMP Address Block TLV is an example of a Timestamp TLV as
described in Section 7. If one or more TIMESTAMP TLVs and one or described in Section 7. If one or more TIMESTAMP TLVs and one or
more ICV TLVs are associated with an address, the relevant TIMESTAMP more ICV TLVs are associated with an address, the relevant TIMESTAMP
TLV <time-value>(s) MUST be included before calculating the value of TLV <time-value>(s) MUST be included before calculating the value of
the ICV to be contained in the ICV TLV value (i.e., concatenated with the ICV to be contained in the ICV TLV value (i.e., concatenated with
the associated addresses and any other values as described in the associated addresses and any other values as described in
Section 10.1). Section 10.1).
11. ICV: Basic 11. ICV: Basic
The basic ICV, represented by way of an ICV TLV with type extension = The basic ICV, represented by way of an ICV TLV with type
0, has as TLV value a simple bit-field without specified structure extension = 0, has as TLV value a simple bit-field without specified
(i.e, without explicitly included hash function, crypto function, key structure (i.e, without explicitly included hash function, crypto
ID or other parameters). Moreover, it is not specified how to function, key ID or other parameters). Moreover, it is not specified
calculate the <ICV-value>. It is assumed that the mechanism how to calculate the <ICV-value>. It is assumed that the mechanism
specifying how ICVs are calculated and verified, as well as which specifying how ICVs are calculated and verified, as well as which
parameters (if any) need to be exchanged prior to using the TLV with parameters (if any) need to be exchanged prior to using the TLV with
type extension 0, is established outside of this specification, e.g., type extension = 0, is established outside of this specification,
by administrative configuration or external out-of-band signaling. e.g., by administrative configuration or external out-of-band
signaling.
The <ICV-value>, when using type extension = 0, is: The <ICV-value>, when using type extension = 0, is:
<ICV-value> := <ICV-data> <ICV-value> := <ICV-data>
where: where:
<ICV-data> is a field, of length <length> octets (or single-length <ICV-data> is a field, of length <length> octets (or single-length
octets in a multivalue Address Block TLV) that contains the octets in a multivalue Address Block TLV) that contains the
cryptographic ICV. cryptographic ICV.
12. ICV: Hash Function and Cryptographic Function 12. ICV: Hash Function and Cryptographic Function
One common way of calculating an ICV is combining a cryptographic One common way of calculating an ICV is combining a cryptographic
function and a hash function applied to the content. This function and a hash function applied to the content. This
decomposition is specified in this section, using either type decomposition is specified in this section, using either type
extension = 1 or type extension = 2, in the ICV TLVs. extension = 1 or type extension = 2, in the ICV TLVs.
skipping to change at page 13, line 26 skipping to change at page 12, line 39
cryptographic function used for calculating the ICV: cryptographic function used for calculating the ICV:
<ICV-value> := <hash-function> <ICV-value> := <hash-function>
<cryptographic-function> <cryptographic-function>
<key-id-length> <key-id-length>
<key-id>? <key-id>?
<ICV-data> <ICV-data>
where: where:
<hash-function> is a one octet unsigned integer field specifying the <hash-function> is a one-octet unsigned integer field specifying
hash function. the hash function.
<cryptographic-function> is a one octet unsigned integer field <cryptographic-function> is a one-octet unsigned integer field
specifying the cryptographic function. specifying the cryptographic function.
<key-id-length> is a one octet unsigned integer field specifying the <key-id-length> is a one-octet unsigned integer field specifying
length of the <key-id> field as a number of octets. The value the length of the <key-id> field as a number of octets. The value
zero (0x00) is reserved for using a single pre-installed, shared zero (0x00) is reserved for using a single pre-installed, shared
key. key.
<key-id> is a field specifying the key identifier of the key that <key-id> is a field specifying the key identifier of the key that
was used to calculate the ICV of the message, which allows unique was used to calculate the ICV of the message, which allows unique
identification of different keys with the same originator. It is identification of different keys with the same originator. It is
the responsibility of each key originator to make sure that the responsibility of each key originator to make sure that
actively used keys that it issues have distinct key identifiers. actively used keys that it issues have distinct key identifiers.
If <key-id-length> equals zero (0x00), the <key-id> field is not If <key-id-length> equals zero (0x00), the <key-id> field is not
contained in the TLV, and a single pre-installed, shared key is contained in the TLV, and a single pre-installed, shared key is
used. used.
<ICV-data> is a field with length <length> - 3 - <key-id-length> <ICV-data> is a field with length <length> - 3 - <key-id-length>
octets (except in a multivalue Address Block TLV, in which it is octets (except in a multivalue Address Block TLV, in which it is
single-length - 3 - <key-id-length> octets) and which contains the single-length - 3 - <key-id-length> octets) and that contains the
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 Hashed
function, which is specified as defined in Section 13.12, using the Message Authentication Code (HMAC) function, which is specified as
hash function twice. Using cryptographic-function "none" is provided defined in Section 13.12, using the hash function twice. Using
for symmetry and possible future use, but it SHOULD NOT be used with cryptographic-function "none" is provided for symmetry and possible
any currently specified hash-function. future use, but it SHOULD NOT be used with any currently specified
hash function.
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
truncation MUST be as specified for the relevant cryptographic truncation MUST be as specified for the relevant cryptographic
function (and, if appropriate, hash function). function (and, if appropriate, hash function).
o When using truncation, the guidelines for minimal ICV length set o When using truncation, the guidelines for minimal ICV length set
out in [NIST-SP-800-107] MUST be followed. In particular the out in [NIST-SP-800-107] MUST be followed. In particular the
skipping to change at page 14, line 42 skipping to change at page 14, line 11
success of a dictionary attack is acceptably small. Such a success of a dictionary attack is acceptably small. Such a
success will arise if the ICV of a spoofed packet or message is success will arise if the ICV of a spoofed packet or message is
verified. The probability of success is a function of (a) how verified. The probability of success is a function of (a) how
many routers can be attacked, (b) how fast a router can receive many routers can be attacked, (b) how fast a router can receive
packets or messages and attempt to verify their ICV, (c) the packets or messages and attempt to verify their ICV, (c) the
truncated ICV length, and (d) the lifetime of the network. If the truncated ICV length, and (d) the lifetime of the network. If the
truncated ICV length in bits is L, then 2^L packets or messages truncated ICV length in bits is L, then 2^L packets or messages
are required to attack with certainty of success. With a are required to attack with certainty of success. With a
verification rate of R packets/messages per second, applied to N verification rate of R packets/messages per second, applied to N
routers over an available time of T, the probability of success is routers over an available time of T, the probability of success is
given by NRT/2^L. If this is to not exceed a probability of P, given by NRT/2^L. If this is not to exceed a probability of P,
then L > log2(NRT/P). For example if N is 32, R is 1000, T is then L > log2(NRT/P). For example, if N is 32, R is 1000, T is
86400 (I day) and P is 10^-6, then L must be at least 52 bits. 86400 (I day) and P is 10^-6, then L must be at least 52 bits.
Some of the cryptographic and hash functions listed in Section 13 Some of the cryptographic and hash functions listed in Section 13
require the length of the content to be digitally signed to be a require the length of the content to be digitally signed to be a
multiple of a certain number of octets. As a consequence, they multiple of a certain number of octets. As a consequence, they
specify padding mechanisms, e.g., AES-CMAC [RFC4493] specifies a specify padding mechanisms, e.g., AES-CMAC [RFC4493] specifies a
padding mechanism for message lengths that are not equal to a padding mechanism for message lengths that are not equal to a
multiple of 16 octets. Implementations of the framework in this multiple of 16 octets. Implementations of the framework in this
document MUST support appropriate padding mechanisms, as specified in document MUST support appropriate padding mechanisms, as specified in
the cryptographic or hash function specifications. the cryptographic or hash function specifications.
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 described in Section 13. entries in two IANA registries, which 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 a smaller overall
overall space. space.
The rationale for not including a field that lists parameters of the The rationale for not including a field that lists parameters of the
cryptographic ICV in the TLV is that, before being able to validate a cryptographic ICV in the TLV is that, before being able to validate a
cryptographic ICV, routers have to exchange or acquire keys. Any cryptographic ICV, routers have to exchange or acquire keys. Any
additional parameters can be provided together with the keys in that additional parameters can be provided together with the keys in that
bootstrap process. It is therefore not necessary, and would even bootstrap process. Therefore, it is not necessary, and would even
entail an extra overhead, to transmit the parameters within every entail an extra overhead, to transmit the parameters within every
message. message.
The rationale for the addition of type extension 2 is that the source The rationale for the addition of type extension = 2 is that the
code address is used in some cases, such as when processing HELLO source address is used in some cases, such as when processing HELLO
messages in [RFC6130]. This is applicable only to packets (which messages in [RFC6130]. This is applicable only to packets (which
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 Topology Control (TC)
messages in [RFC7181].
12.1.2. Parameters 12.1.2. Parameters
As described in Section 12.1.1, parameters such as RSA signature As described in Section 12.1.1, parameters are selected
scheme, RSA common exponent etc. are selected administratively on administratively on each router before using this framework in a
each router before using this framework in a MANET, in addition to MANET, in addition to exchanging the keys between MANET routers.
exchanging the keys between MANET routers. This was a design This was a design decision in [RFC6622] and is kept in this
decision in [RFC6622] and is kept in this specification for reasons specification for reasons of backwards compatibility.
of backwards-compatibility.
The following parameters are RECOMMENDED and SHOULD be those chosen The following parameters are RECOMMENDED and SHOULD be those chosen
administratively, unless there are good reasons otherwise: administratively, unless there are good reasons otherwise:
o For crypto function RSA: o For crypto function RSA:
* Signature scheme: RSASSA-PSS with the default parameters: * Signature scheme: RSASSA-PSS with the default parameters:
rSASSA-PSS-Default-Identifier (as defined in [RFC3447]) rSASSA-PSS-Default-Identifier (as defined in [RFC3447])
* Common exponent: 65537 * Common exponent: 65537
o For crypto function ECDSA: o For crypto function ECDSA:
* Curve name: exchanged as part of key distribution * Curve name: exchanged as part of key distribution
* Hash function: The hash function MUST be pinned to the curve, * Hash function: The hash function MUST be pinned to the curve,
i.e., use SHA-256 for the p-256 curve, SHA-384 for p-384 etc. i.e., use SHA-256 for the p-256 curve, SHA-384 for p-384, etc.
o For crypto function AES: o For crypto function AES:
* Authentication algorithm: CMAC (as defined in [RFC4493] * Authentication algorithm: Cipher-Based Message Authentication
Code (CMAC) (as defined in [RFC4493])
* Hash function: None * Hash function: None
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. ICV Packet 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
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 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
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 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. ICV Message 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
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 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
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 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. ICV Address Block 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
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 consideration 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 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 Address Block, followed by the of the IP datagram carrying the Address Block, followed by the
remaining data (as for type extension = 1). The representation of remaining data (as for type extension = 1). The representation of
the source address consists of a single octet containing the the source address consists of a single octet containing the
address length, in octets, followed by that many octets containing address length, in octets, followed by that many octets containing
the address in network byte order. 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 E 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 and a key identifier that
a key identifier that is 4 octets long. The type extension of the is 4 octets long. The type extension of the Message TLV is 1, for
Message TLV is 1, for the specific decomposition of an ICV using a the specific decomposition of an ICV using a cryptographic function
cryptographic function and a hash function, as specified in and a hash function, as specified in Section 12.
Section 12.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PV=0 | PF=8 | Packet Sequence Number | Message Type | | Message Type | MF=15 | MAL=3 | Message Length = 82 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MF=15 | MAL=3 | Message Length = 44 | Msg Orig Addr | | Message Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Originator Address (cont) | Hop Limit | | Hop Limit | Hop Count | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | Message Sequence Number | Msg TLV Block | | Message TLV Block Length = 36 | TLV Type | MTLVF = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length = 27 | ICV | MTLVF = 144 | MTLVExt = 1 | | Value Len = 6 | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Value Len = 23 | Hash Func | Crypto Func |Key ID length=4| | Value (cont) |TLV Type = ICV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Identifier | | MTLVF = 144 | MTLVExt = 1 |Value Len = 23 | Hash Func |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICV Value | | Crypto Func | KeyID Len = 4 | Key Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICV Value (cont) | | Key Identifier (cont) | ICV Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICV Value (cont) | | ICV Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICV Value (cont) | | ICV Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICV Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICV Value (cont) | Num Addr = 2 | ABF = 48 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tail Len = 2 | Mid 0 | Mid 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid 1 (cont) | Prefix Length | ABTLV Block Length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num Addr = 3 | ABF = 128 | Head Len = 2 | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Mid 0 | Mid 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid 1 (cont) | Mid 2 |ABTLV Block ...|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|... Length = 9 | TLV Type | ABTLVF = 16 | Value Len = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | TLV Type | ABTLVF = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index Start | Index Stop |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Example Message with ICV Figure 1: Example Message with ICV
MF: Message Flags, see Section 5.2 of [RFC5444].
MAL: Message Address Length, see Section 5.2 of [RFC5444].
MTLVF: Message TLV Flags, see Section 5.4.1 of [RFC5444].
MTLVExt: Message TLV Type Extension, see Section 5.4.1 of [RFC5444].
AF: Address Block Flags, see Section 5.3 of [RFC5444].
ABTLV: Address Block TLV, see Section 5.4 of [RFC5444].
ABTLVF: Address Block TLV Flags, see Section 5.4.1 of [RFC5444].
Example Message with ICV - Legend
13. IANA Considerations 13. IANA Considerations
The IANA registrations for TLV Types and the TLV Type Extension The IANA registrations for TLV Types and the TLV type extension
registries given in this specification replace the identical registries given in this specification replace the identical
registrations and registries from [RFC6622]. registrations and registries from [RFC6622].
This specification defines the following TLV Types, replacing the This specification defines the following TLV Types, replacing the
original specifications in [RFC6622]: 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.
skipping to change at page 19, line 42 skipping to change at page 20, line 13
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 Types 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 is requested to modify this allocation as specified in Table 1. IANA has modified this allocation as
indicated. indicated.
+------+-------------+-----------+ +------+-------------+-----------+
| Type | Description | Reference | | Type | Description | Reference |
+------+-------------+-----------+ +------+-------------+-----------+
| 5 | ICV | RFC xxxx | | 5 | ICV | RFC 7182 |
| 6 | TIMESTAMP | RFC xxxx | | 6 | TIMESTAMP | RFC 7182 |
+------+-------------+-----------+ +------+-------------+-----------+
Table 1: Packet TLV Types Table 1: Packet TLV Types
13.3. Message TLV Types 13.3. Message TLV Types
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 "Message TLV Types" namespace of [RFC5444] for the Message TLVs
specified in Table 2. IANA is requested to modify this allocation as specified in Table 2. IANA has modified this allocation as
indicated. indicated.
+------+-------------+-----------+ +------+-------------+-----------+
| Type | Description | Reference | | Type | Description | Reference |
+------+-------------+-----------+ +------+-------------+-----------+
| 5 | ICV | RFC xxxx | | 5 | ICV | RFC 7182 |
| 6 | TIMESTAMP | RFC xxxx | | 6 | TIMESTAMP | RFC 7182 |
+------+-------------+-----------+ +------+-------------+-----------+
Table 2: Message TLV Types Table 2: Message TLV Types
13.4. Address Block TLV Types 13.4. Address Block TLV Types
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 "Address Block TLV Types" namespace of [RFC5444] for the Packet TLVs
specified in Table 3. IANA is requested to modify this allocation as specified in Table 3. IANA has modified this allocation as
indicated. indicated.
+------+-------------+-----------+ +------+-------------+-----------+
| Type | Description | Reference | | Type | Description | Reference |
+------+-------------+-----------+ +------+-------------+-----------+
| 5 | ICV | RFC xxxx | | 5 | ICV | RFC 7182 |
| 6 | TIMESTAMP | RFC xxxx | | 6 | TIMESTAMP | RFC 7182 |
+------+-------------+-----------+ +------+-------------+-----------+
Table 3: Address Block TLV Types Table 3: Address Block TLV Types
13.5. ICV Packet TLV Type Extensions 13.5. ICV Packet TLV Type Extensions
IANA has, in accordance with [RFC6622], made allocations from the IANA has, in accordance with [RFC6622], made allocations from the
"ICV Packet TLV Type Extensions" namespace of [RFC6622] for the "ICV Packet TLV Type Extensions" namespace of [RFC6622] for the
Packet TLVs specified in Table 4. IANA is requested to modify this Packet TLVs specified in Table 4. IANA has modified this allocation
allocation (including defining type extension = 2) as indicated. (including defining type extension = 2) as indicated.
+-----------+-------------------------------------------+-----------+ +-----------+-------------------------------------------+-----------+
| Type | Description | Reference | | Type | Description | Reference |
| Extension | | | | Extension | | |
+-----------+-------------------------------------------+-----------+ +-----------+-------------------------------------------+-----------+
| 0 | ICV of a packet | RFC xxxx | | 0 | ICV of a packet | RFC 7182 |
| 1 | ICV, using a cryptographic function and a | RFC xxxx | | 1 | ICV, using a cryptographic function and a | RFC 7182 |
| | hash function, as specified in Section 12 | | | | hash function, as specified in Section 12 | |
| | of this document | | | | of this document | |
| 2 | ICV, using a cryptographic function and a | RFC xxxx | | 2 | ICV, using a cryptographic function and a | RFC 7182 |
| | hash function, and including the IP | | | | hash function, and including the IP | |
| | datagram source address, as specified in | | | | datagram source address, as specified in | |
| | Section 12 of this document | | | | Section 12 of this document | |
| 3-251 | Unassigned; Expert Review | | | 3-251 | Unassigned; Expert Review | |
| 252-255 | Experimental Use | RFC xxxx | | 252-255 | Reserved for Experimental Use | RFC 7182 |
+-----------+-------------------------------------------+-----------+ +-----------+-------------------------------------------+-----------+
Table 4: ICV Packet TLV Type Extensions 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. information MUST NOT be included in the same packet.
13.6. TIMESTAMP Packet TLV Type Extensions 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
"TIMESTAMP Packet TLV Type Extensions" namespace of [RFC6622] for the "TIMESTAMP Packet TLV Type Extensions" namespace of [RFC6622] for the
Packet TLVs specified in Table 5. IANA is requested to modify this Packet TLVs specified in Table 5. IANA has modified this allocation
allocation as indicated. as indicated.
+-----------+-------------------------------------------+-----------+ +-----------+-------------------------------------------+-----------+
| Type | Description | Reference | | Type | Description | Reference |
| Extension | | | | Extension | | |
+-----------+-------------------------------------------+-----------+ +-----------+-------------------------------------------+-----------+
| 0 | Unsigned timestamp of arbitrary length, | RFC xxxx | | 0 | Unsigned timestamp of arbitrary length, | RFC 7182 |
| | given by the TLV Length field. The MANET | | | | given by the TLV Length field. The MANET | |
| | routing protocol has to define how to | | | | routing protocol has to define how to | |
| | interpret this timestamp | | | | interpret this timestamp | |
| 1 | Unsigned 32-bit timestamp, as specified | RFC xxxx | | 1 | Unsigned 32-bit timestamp, as specified | RFC 7182 |
| | in [IEEE 1003.1-2008 (POSIX)] | | | | in [IEEE1003.1-2008] | |
| 2 | NTP timestamp format, as specified in | RFC xxxx | | 2 | NTP timestamp format, as specified in | RFC 7182 |
| | [RFC5905] | | | | [RFC5905] | |
| 3 | Signed timestamp of arbitrary length with | RFC xxxx | | 3 | Signed timestamp of arbitrary length with | RFC 7182 |
| | no constraints such as monotonicity. In | | | | no constraints such as monotonicity. In | |
| | particular, it may represent any random | | | | particular, it may represent any random | |
| | value | | | | value | |
| 4-251 | Unassigned; Expert Review | | | 4-251 | Unassigned; Expert Review | |
| 252-255 | Experimental Use | RFC xxxx | | 252-255 | Reserved for Experimental Use | RFC 7182 |
+-----------+-------------------------------------------+-----------+ +-----------+-------------------------------------------+-----------+
Table 5: TIMESTAMP Packet TLV Type Extensions Table 5: TIMESTAMP Packet TLV Type Extensions
More than one TIMESTAMP Packet TLV with the same type extension MUST More than one TIMESTAMP Packet TLV with the same type extension MUST
NOT be included in a packet. NOT be included in a packet.
13.7. ICV Message TLV Type Extensions 13.7. ICV Message TLV Type Extensions
IANA has, in accordance with [RFC6622], made allocations from the IANA has, in accordance with [RFC6622], made allocations from the
"ICV Message TLV Type Extensions" namespace of [RFC6622] for the "ICV Message TLV Type Extensions" namespace of [RFC6622] for the
Message TLVs specified in Table 6. IANA is requested to modify this Message TLVs specified in Table 6. IANA has modified this allocation
allocation (including defining type extension = 2) as indicated. (including defining type extension = 2) as indicated.
+-----------+-------------------------------------------+-----------+ +-----------+-------------------------------------------+-----------+
| Type | Description | Reference | | Type | Description | Reference |
| Extension | | | | Extension | | |
+-----------+-------------------------------------------+-----------+ +-----------+-------------------------------------------+-----------+
| 0 | ICV of a message | RFC xxxx | | 0 | ICV of a message | RFC 7182 |
| 1 | ICV, using a cryptographic function and a | RFC xxxx | | 1 | ICV, using a cryptographic function and a | RFC 7182 |
| | hash function, as specified in Section 12 | | | | hash function, as specified in Section 12 | |
| | of this document | | | | of this document | |
| 2 | ICV, using a cryptographic function and a | RFC xxxx | | 2 | ICV, using a cryptographic function and a | RFC 7182 |
| | hash function, and including the IP | | | | hash function, and including the IP | |
| | datagram source address, as specified in | | | | datagram source address, as specified in | |
| | Section 12 of this document | | | | Section 12 of this document | |
| 3-251 | Unassigned; Expert Review | | | 3-251 | Unassigned; Expert Review | |
| 252-255 | Experimental Use | RFC xxxx | | 252-255 | Reserved for Experimental Use | RFC 7182 |
+-----------+-------------------------------------------+-----------+ +-----------+-------------------------------------------+-----------+
Table 6: ICV Message TLV Type Extensions 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. information MUST NOT be included in the same message.
13.8. TIMESTAMP Message TLV Type Extensions 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
"TIMESTAMP Message TLV Type Extensions" namespace of [RFC6622] for "TIMESTAMP Message TLV Type Extensions" namespace of [RFC6622] for
the Message TLVs specified in Table 7. IANA is requested to modify the Message TLVs specified in Table 7. IANA has modified this
this allocation as indicated. allocation as indicated.
+-----------+-------------------------------------------+-----------+ +-----------+-------------------------------------------+-----------+
| Type | Description | Reference | | Type | Description | Reference |
| Extension | | | | Extension | | |
+-----------+-------------------------------------------+-----------+ +-----------+-------------------------------------------+-----------+
| 0 | Unsigned timestamp of arbitrary length, | RFC xxxx | | 0 | Unsigned timestamp of arbitrary length, | RFC 7182 |
| | given by the TLV Length field. The MANET | | | | given by the TLV Length field. The MANET | |
| | routing protocol has to define how to | | | | routing protocol has to define how to | |
| | interpret this timestamp | | | | interpret this timestamp | |
| 1 | Unsigned 32-bit timestamp, as specified | RFC xxxx | | 1 | Unsigned 32-bit timestamp, as specified | RFC 7182 |
| | in [IEEE 1003.1-2008 (POSIX)] | | | | in POSIX [IEEE1003.1-2008] | |
| 2 | NTP timestamp format, as specified in | RFC xxxx | | 2 | NTP timestamp format, as specified in | RFC 7182 |
| | [RFC5905] | | | | [RFC5905] | |
| 3 | Signed timestamp of arbitrary length with | RFC xxxx | | 3 | Signed timestamp of arbitrary length with | RFC 7182 |
| | no constraints such as monotonicity. In | | | | no constraints such as monotonicity. In | |
| | particular, it may represent any random | | | | particular, it may represent any random | |
| | value | | | | value | |
| 4-251 | Unassigned; Expert Review | | | 4-251 | Unassigned; Expert Review | |
| 252-255 | Experimental Use | RFC xxxx | | 252-255 | Reserved for Experimental Use | RFC 7182 |
+-----------+-------------------------------------------+-----------+ +-----------+-------------------------------------------+-----------+
Table 7: TIMESTAMP Message TLV Type Extensions Table 7: TIMESTAMP Message TLV Type Extensions
More than one TIMESTAMP Message TLV with the same type extension MUST More than one TIMESTAMP Message TLV with the same type extension MUST
NOT be included in a message. NOT be included in a message.
13.9. ICV Address Block TLV Type Extensions 13.9. ICV Address Block TLV Type Extensions
IANA has, in accordance with [RFC6622], made allocations from the IANA has, in accordance with [RFC6622], made allocations from the
"ICV Address Block TLV Type Extensions" namespace of [RFC6622] for "ICV Address Block TLV Type Extensions" namespace of [RFC6622] for
the Address Block TLVs specified in Table 8. IANA is requested to the Address Block TLVs specified in Table 8. IANA has modified this
modify this allocation (including defining type extension = 2) as allocation (including defining type extension = 2) as indicated.
indicated.
+-----------+-------------------------------------------+-----------+ +-----------+-------------------------------------------+-----------+
| Type | Description | Reference | | Type | Description | Reference |
| Extension | | | | Extension | | |
+-----------+-------------------------------------------+-----------+ +-----------+-------------------------------------------+-----------+
| 0 | ICV of an object (e.g., an address) | RFC xxxx | | 0 | ICV of an object (e.g., an address) | RFC 7182 |
| 1 | ICV, using a cryptographic function and a | RFC xxxx | | 1 | ICV, using a cryptographic function and a | RFC 7182 |
| | hash function, as specified in Section 12 | | | | hash function, as specified in Section 12 | |
| | of this document | | | | of this document | |
| 2 | ICV, using a cryptographic function and a | RFC xxxx | | 2 | ICV, using a cryptographic function and a | RFC 7182 |
| | hash function, and including the IP | | | | hash function, and including the IP | |
| | datagram source address, as specified in | | | | datagram source address, as specified in | |
| | Section 12 of this document | | | | Section 12 of this document | |
| 3-251 | Unassigned; Expert Review | | | 3-251 | Unassigned; Expert Review | |
| 252-255 | Experimental Use | RFC xxxx | | 252-255 | Reserved for Experimental Use | RFC 7182 |
+-----------+-------------------------------------------+-----------+ +-----------+-------------------------------------------+-----------+
Table 8: ICV Address Block TLV Type Extensions 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 associated 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 type extension = 2 and
cryptographic function and/or hash function, or with a different key different cryptographic function and/or hash function or with a
identifier). ICV Address Block TLVs that carry what is declared to different key identifier). ICV Address Block TLVs that carry what is
be the same information MUST NOT be associated with the same address. declared to be the same information MUST NOT be associated with the
same address.
13.10. TIMESTAMP Address Block TLV Type Extensions 13.10. TIMESTAMP Address Block TLV Type Extensions
IANA has, in accordance with [RFC6622], made allocations from the IANA has, in accordance with [RFC6622], made allocations from the
"TIMESTAMP Address Block TLV Type Extensions" namespace of [RFC6622] "TIMESTAMP Address Block TLV Type Extensions" namespace of [RFC6622]
for the Address Block TLVs specified in Table 9. IANA is requested for the Address Block TLVs specified in Table 9. IANA has modified
to modify this allocation as indicated. this allocation as indicated.
+-----------+-------------------------------------------+-----------+ +-----------+-------------------------------------------+-----------+
| Type | Description | Reference | | Type | Description | Reference |
| Extension | | | | Extension | | |
+-----------+-------------------------------------------+-----------+ +-----------+-------------------------------------------+-----------+
| 0 | Unsigned timestamp of arbitrary length, | RFC xxxx | | 0 | Unsigned timestamp of arbitrary length, | RFC 7182 |
| | given by the TLV Length field. The MANET | | | | given by the TLV Length field. The MANET | |
| | routing protocol has to define how to | | | | routing protocol has to define how to | |
| | interpret this timestamp | | | | interpret this timestamp | |
| 1 | Unsigned 32-bit timestamp, as specified | RFC xxxx | | 1 | Unsigned 32-bit timestamp, as specified | RFC 7182 |
| | in [IEEE 1003.1-2008 (POSIX)] | | | | in POSIX [IEEE1003.1-2008] | |
| 2 | NTP timestamp format, as specified in | RFC xxxx | | 2 | NTP timestamp format, as specified in | RFC 7182 |
| | [RFC5905] | | | | [RFC5905] | |
| 3 | Signed timestamp of arbitrary length with | RFC xxxx | | 3 | Signed timestamp of arbitrary length with | RFC 7182 |
| | no constraints such as monotonicity. In | | | | no constraints such as monotonicity. In | |
| | particular, it may represent any random | | | | particular, it may represent any random | |
| | value | | | | value | |
| 4-251 | Unassigned; Expert Review | | | 4-251 | Unassigned; Expert Review | |
| 252-255 | Experimental Use | RFC xxxx | | 252-255 | Reserved for Experimental Use | RFC 7182 |
+-----------+-------------------------------------------+-----------+ +-----------+-------------------------------------------+-----------+
Table 9: TIMESTAMP Address Block TLV Type Extensions 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.11. 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 10. IANA is requested to modify this policies are specified in Table 10. IANA has modified this
allocation as indicated. allocation as indicated.
+---------+-----------+---------------------------------+-----------+ +---------+-----------+---------------------------------+-----------+
| Value | Algorithm | Description | Reference | | Value | Algorithm | Description | Reference |
+---------+-----------+---------------------------------+-----------+ +---------+-----------+---------------------------------+-----------+
| 0 | none | The "identity function": The | RFC xxxx | | 0 | none | The "identity function": The | RFC 7182 |
| | | hash value of an object is the | | | | | hash value of an object is the | |
| | | object itself | | | | | object itself | |
| 1 | SHA-1 | [NIST-FIPS-180-4] | RFC xxxx | | 1 | SHA-1 | [NIST-FIPS-180-4] | RFC 7182 |
| 2 | SHA-224 | [NIST-FIPS-180-4] | RFC xxxx | | 2 | SHA-224 | [NIST-FIPS-180-4] | RFC 7182 |
| 3 | SHA-256 | [NIST-FIPS-180-4] | RFC xxxx | | 3 | SHA-256 | [NIST-FIPS-180-4] | RFC 7182 |
| 4 | SHA-384 | [NIST-FIPS-180-4] | RFC xxxx | | 4 | SHA-384 | [NIST-FIPS-180-4] | RFC 7182 |
| 5 | SHA-512 | [NIST-FIPS-180-4] | RFC xxxx | | 5 | SHA-512 | [NIST-FIPS-180-4] | RFC 7182 |
| 6-251 | | Unassigned; Expert Review | | | 6-251 | | Unassigned; Expert Review | |
| 252-255 | | Experimental Use | RFC xxxx | | 252-255 | | Reserved for Experimental Use | RFC 7182 |
+---------+-----------+---------------------------------+-----------+ +---------+-----------+---------------------------------+-----------+
Table 10: Hash Function Registry Table 10: Hash Function Registry
13.12. 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 Initial assignments and allocation policies are specified in
Table 11. IANA is requested to modify this allocation as indicated. Table 11. IANA has modified this allocation as indicated.
+---------+-----------+---------------------------------+-----------+ +---------+-----------+---------------------------------+-----------+
| Value | Algorithm | Description | Reference | | Value | Algorithm | Description | Reference |
+---------+-----------+---------------------------------+-----------+ +---------+-----------+---------------------------------+-----------+
| 0 | none | The "identity function": The | RFC xxxx | | 0 | none | The "identity function": The | RFC 7182 |
| | | value of an encrypted hash is | | | | | value of an encrypted hash is | |
| | | the hash itself | | | | | the hash itself | |
| 1 | RSA | [RFC3447] | RFC xxxx | | 1 | RSA | [RFC3447] | RFC 7182 |
| 2 | DSA | [NIST-FIPS-186-4] | RFC xxxx | | 2 | DSA | [NIST-FIPS-186-4] | RFC 7182 |
| 3 | HMAC | [RFC2104] | RFC xxxx | | 3 | HMAC | [RFC2104] | RFC 7182 |
| 4 | 3DES | [NIST-SP-800-67] | RFC xxxx | | 4 | 3DES | [NIST-SP-800-67] | RFC 7182 |
| 5 | AES | [NIST-FIPS-197] | RFC xxxx | | 5 | AES | [NIST-FIPS-197] | RFC 7182 |
| 6 | ECDSA | [RFC6090] | RFC xxxx | | 6 | ECDSA | [RFC6090] | RFC 7182 |
| 7-251 | | Unassigned; Expert Review | | | 7-251 | | Unassigned; Expert Review | |
| 252-255 | | Experimental Use | RFC xxxx | | 252-255 | | Reserved for Experimental Use | RFC 7182 |
+---------+-----------+---------------------------------+-----------+ +---------+-----------+---------------------------------+-----------+
Table 11: 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
extension that uses this specification MUST specify how to use the extension that uses this specification MUST specify how to use the
framework, and the TLVs presented in this document. In addition, the framework and the TLVs presented in this document. In addition, the
protection that the MANET routing protocol or MANET routing protocol protection that the MANET routing protocol or MANET routing protocol
extensions attain by using this framework MUST be described. extensions attain by using this framework MUST be described.
As an example, a MANET routing protocol that uses this component to As an example, a MANET routing protocol that uses this component to
reject "badly formed" or "insecure" messages if a control message reject "badly formed" or "insecure" messages if a control message
does not contain a valid ICV SHOULD indicate the security assumption does not contain a valid ICV SHOULD indicate the security assumption
that if the ICV is valid, the message is considered valid. It also that if the ICV is valid, the message is considered valid. It also
SHOULD indicate the security issues that are counteracted by this SHOULD indicate the security issues that are counteracted by this
measure (e.g., link or identity spoofing) as well as the issues that measure (e.g., link or identity spoofing) as well as the issues that
are not counteracted (e.g., compromised keys). are not counteracted (e.g., compromised keys).
skipping to change at page 27, line 39 skipping to change at page 29, line 9
Farrell (Trinity College Dublin), and Robert Sparks (Tekelec), as Farrell (Trinity College Dublin), and Robert Sparks (Tekelec), as
well as Donald Eastlake (Huawei) from the Security Directorate. well as Donald Eastlake (Huawei) from the Security Directorate.
The authors would like to thank Justin Dean (NRL) and Henning Rogge The authors would like to thank Justin Dean (NRL) and Henning Rogge
(FGAN) for their constructive comments on this specification. (FGAN) for their constructive comments on this specification.
16. References 16. References
16.1. Normative References 16.1. Normative References
[BCP26] Narten, T. and H. Alvestrand, "Guidelines [BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an
for Writing an IANA Considerations IANA Considerations Section in RFCs", BCP 26, RFC 5226,
Section in RFCs", BCP 26, RFC 5226, May 2008.
May 2008.
[NIST-FIPS-186-4] National Institute of Standards and [IEEE1003.1-2008]
Technology, "Digital Signature Standard IEEE, "Portable Operating System Interface (POSIX)", IEEE
(DSS)", FIPS 186-4, July 2013. 1003.1-2008, Base Specifications, Issue 7, December 2008.
[NIST-FIPS-197] National Institute of Standards and [NIST-FIPS-180-4]
Technology, "Specification for the National Institute of Standards and Technology, "Secure
Advanced Encryption Standard (AES)", Hash Standard (SHS)", FIPS 180-4, March 2012.
FIPS 197, November 2001.
[NIST-SP-800-107] National Institute of Standards and [NIST-FIPS-186-4]
Technology, "Recommendation for National Institute of Standards and Technology, "Digital
Applications Using Approved Hash Signature Standard (DSS)", FIPS 186-4, July 2013.
Algorithms", SP 800-107, Revision 1,
August 2012.
[RFC2104] Krawczyk, H., Bellare, M., and R. [NIST-FIPS-197]
Canetti, "HMAC: Keyed-Hashing for Message National Institute of Standards and Technology,
Authentication", RFC 2104, February 1997. "Specification for the Advanced Encryption Standard
(AES)", FIPS 197, November 2001.
[RFC2119] Bradner, S., "Key words for use in RFCs [NIST-SP-800-107]
to Indicate Requirement Levels", BCP 14, National Institute of Standards and Technology,
RFC 2119, March 1997. "Recommendation for Applications Using Approved Hash
Algorithms", SP 800-107, Revision 1, August 2012.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key [NIST-SP-800-67]
Cryptography Standards (PKCS) #1: RSA National Institute of Standards and Technology,
Cryptography Specifications Version 2.1", "Recommendation for the Triple Data Encryption Algorithm
RFC 3447, February 2003. (TDEA) Block Cipher", Special Publication 800-67, Revision
1, January 2012.
[RFC4493] Song, JH., Poovendran, R., Lee, J., and [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
T. Iwata, "The AES-CMAC Algorithm", Hashing for Message Authentication", RFC 2104, February
RFC 4493, June 2006. 1997.
[RFC5444] Clausen, T., Dearlove, C., Dean, J., and [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
C. Adjih, "Generalized Mobile Ad Hoc Requirement Levels", BCP 14, RFC 2119, March 1997.
Network (MANET) Packet/Message Format",
RFC 5444, February 2009.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
and W. Kasch, "Network Time Protocol Standards (PKCS) #1: RSA Cryptography Specifications
Version 4: Protocol and Algorithms Version 2.1", RFC 3447, February 2003.
Specification", RFC 5905, June 2010.
[RFC6090] McGrew, D., Igoe, K., and M. Salter, [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The
"Fundamental Elliptic Curve Cryptography AES-CMAC Algorithm", RFC 4493, June 2006.
Algorithms", RFC 6090, February 2011.
[NIST-SP-800-67] National Institute of Standards and [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
Technology, "Recommendation for the "Generalized Mobile Ad Hoc Network (MANET) Packet/Message
Triple Data Encryption Algorithm (TDEA) Format", RFC 5444, February 2009.
Block Cipher", Special
Publication 800-67, Revision 1,
January 2012.
[NIST-FIPS-180-4] National Institute of Standards and [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
Technology, "Secure Hash Standard (SHS)", Time Protocol Version 4: Protocol and Algorithms
FIPS 180-4, March 2012. Specification", RFC 5905, June 2010.
[IEEE 1003.1-2008 (POSIX)] IEEE Computer Society, "1003.1-2008 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
Standard for Information Technology - Curve Cryptography Algorithms", RFC 6090, February 2011.
Portable Operating System Interface
(POSIX) Base Specifications, Issue 7",
December 2008.
16.2. Informative References 16.2. Informative References
[RFC6130] Clausen, T., Dearlove, C., and J. Dean, [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
"Mobile Ad Hoc Network (MANET) Network (MANET) 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
Check Value and Timestamp TLV Definitions Timestamp TLV Definitions for Mobile Ad Hoc Networks
for Mobile Ad Hoc Networks (MANETs)", (MANETs)", RFC 6622, May 2012.
RFC 6622, May 2012.
[OLSRv2] Clausen, T., Dearlove, C., Jacquet, P., [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
and U. Herberg, "The Optimized Link State "The Optimized Link State Routing Protocol Version 2", RFC
Routing Protocol version 2", work in 7181, April 2014.
progress draft-ietf-manet-olsrv2-19,
March 2013.
Authors' Addresses Authors' Addresses
Ulrich Herberg Ulrich Herberg
Fujitsu Laboratories of America Fujitsu Laboratories of America
1240 E. Arques Ave. 1240 E. Arques Ave.
Sunnyvale, CA 94085 Sunnyvale, CA 94085
USA USA
EMail: ulrich@herberg.name EMail: ulrich@herberg.name
 End of changes. 141 change blocks. 
325 lines changed or deleted 337 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/