RFC 7182
Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)
RFC 7182: Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs) 💖
- RFC number: 7182 🎀
- Obsoletes: RFC 6622 (this one replaces it 💅)
- Category: Standards Track ✨
- Date: April 2014 🌸
- ISSN: 2070-1721
- Authors:
- U. Herberg, Fujitsu Laboratories of America 🦋
- T. Clausen, LIX, Ecole Polytechnique 🧚
- C. Dearlove, BAE Systems ATC 🌈
Abstract
okay so this doc is giving glow-up energy 💅 It revises, extends, and replaces RFC 6622. It describes general and flexible TLVs (little tagged chunks of data) for carrying cryptographic Integrity Check Values (ICVs) and timestamps. They're built on the generalized MANET packet/message format from RFC 5444 🫶 It defines two Packet TLVs, two Message TLVs, and two Address Block TLVs, which attach ICVs and timestamps to a packet, a message, and one or more addresses, respectively ✨
Status of This Memo
this one is an Internet Standards Track document 🔥
it's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). more info on Internet Standards is in Section 2 of RFC 5741 📚
for the current status, any errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc7182 💜
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. 🎀
this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication. please actually read those, bestie, because they describe your rights and restrictions for this doc 🙈 Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License ⚠️
Table of Contents
1. Introduction ....................................................3
1.1. Differences from RFC 6622 ..................................4
2. Terminology .....................................................4
3. Applicability Statement .........................................5
4. Security Architecture ...........................................6
5. Overview and Functioning ........................................7
6. General ICV TLV Structure .......................................8
7. General Timestamp TLV Structure .................................8
8. Packet TLVs .....................................................9
8.1. ICV Packet TLV .............................................9
8.2. TIMESTAMP Packet TLV ......................................10
9. Message TLVs ...................................................10
9.1. ICV Message TLV ...........................................10
9.2. TIMESTAMP Message TLV .....................................10
10. Address Block TLVs ............................................11
10.1. ICV Address Block TLV ....................................11
10.2. TIMESTAMP Address Block TLV ..............................11
11. ICV: Basic ....................................................11
12. ICV: Hash Function and Cryptographic Function .................12
12.1. General ICV TLV Structure ................................12
12.1.1. Rationale .........................................14
12.1.2. Parameters ........................................15
12.2. Considerations for Calculating the ICV ...................15
12.2.1. ICV Packet TLV ....................................15
12.2.2. ICV Message TLV ...................................16
12.2.3. ICV Address Block TLV .............................16
12.3. Example of a Message Including an ICV ....................17
13. IANA Considerations ...........................................19
13.1. Expert Review: Evaluation Guidelines .....................19
13.2. Packet TLV Types .........................................20
13.3. Message TLV Types ........................................20
13.4. Address Block TLV Types ..................................20
13.5. ICV Packet TLV Type Extensions ...........................21
13.6. TIMESTAMP Packet TLV Type Extensions .....................21
13.7. ICV Message TLV Type Extensions ..........................22
13.8. TIMESTAMP Message TLV Type Extensions ....................23
13.9. ICV Address Block TLV Type Extensions ....................24
13.10. TIMESTAMP Address Block TLV Type Extensions .............25
13.11. Hash Functions ..........................................26
13.12. Cryptographic Functions .................................27
14. Security Considerations .......................................28
15. Acknowledgements ..............................................28
16. References ....................................................29
16.1. Normative References .....................................29
16.2. Informative References ...................................301. Introduction ✨
this spec defines a syntactical representation of security-related info for use with [RFC5444] addresses, messages, and packets. it also defines IANA registrations of TLV types and type extension registries for those TLV types 📋 this isn't a standalone protocol. it's meant for MANET routing protocols or security extensions of them 🧚
specifically, this document, which revises, extends, and replaces [RFC6622], specifies:
- Two kinds of TLV: one for carrying Integrity Check Values (ICVs), and one for timestamps, in packets, messages, and Address Blocks as defined by [RFC5444] 🔐
- A generic framework for using these TLVs, which accounts for the specific features of Packet, Message, and Address Block TLVs 🌸
- IANA registrations for TLVs, and registries for TLV type extensions, replacing those from [RFC6622] 💅
this document sets up IANA registries for recording code points for ICV TLVs and TIMESTAMP TLVs, plus timestamps, hash functions, and cryptographic functions 🦋
also, in Section 12, this document defines the following:
- A method for generating ICVs using a combination of a cryptographic function and a hash function, and for including those ICVs in the value field of a TLV 🍓
1.1. Differences from RFC 6622 💜
okay so this doc obsoletes [RFC6622] and takes over as the spec for two TLV types, TIMESTAMP and ICV, for packets, messages, and Address Blocks. for the ICV type, it adds a new type extension, 2 (see Section 12), on top of the original type extensions 0 and 1 from [RFC6622] 👑
the TLV value of an ICV TLV with type extension = 2 has the same internal structure as one with type extension = 1. the difference is that it's also calculated over the source address of the IP datagram carrying the packet, message, or Address Block 🫶 why add this? some MANET protocols, like [RFC6130], use the IP source address of the datagram to identify links with neighbor routers. if that address isn't otherwise in the packet, message, or Address Block payload (which [RFC6130] permits), then nothing protects it from tampering 🙈 that's the tea ☕
this document also has a bunch of editorial glow-ups over [RFC6622] ✨ most importantly, it makes clear that an ICV TLV may carry a truncated ICV, and that a single or multivalue TIMESTAMP or ICV Address Block TLV may cover more than one address 🌈 also, to match the terminology in [RFC5444], the TLVs have been renamed from "Packet ICV TLV" to "ICV Packet TLV" and from "Packet TIMESTAMP TLV" to "TIMESTAMP Packet TLV" (and the same goes for Message and Address Block TLVs) 🎀
one normative requirement in Section 9.2 changed from SHOULD to MUST, in this sentence:
If a message contains one or more TIMESTAMP TLVs and one or more
ICV TLVs, then the TIMESTAMP TLVs (as well as any other Message
TLVs) MUST be added to the message before the ICV TLVs....this is a big deal! the upgrade from SHOULD to MUST means the ordering is now mandatory, not just recommended, so implementers need to take note 🚨
2. Terminology 📚
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🔥
this doc uses the terminology and notation defined in [RFC5444]. specifically, these TLV fields and notations from [RFC5444] are used here:
<msg-hop-limit>is the hop limit of a message, as specified in Section 5.2 of [RFC5444] 🧚<msg-hop-count>is the hop count of a message, as specified in Section 5.2 of [RFC5444] 🧚<length>is the length of the value field in a TLV in octets, as specified in Section 5.4.1 of [RFC5444] 💜single-lengthis the length of a single value in the value field of a TLV in octets, as specified in Section 5.4.1 of [RFC5444]. (it equals<length>except in a multivalue Address Block TLV 🌸)
on top of using the regular expressions defined in Section 2.1.1 of [RFC5444], this document defines the following:
+- One or more occurrences of the preceding element or group. 🍓
3. Applicability Statement 🦋
MANET routing protocols that use the format defined in [RFC5444] get to carry extra info in control messages and packets by including TLVs 🫶 info included this way MAY be used by a MANET routing protocol, or by an extension of one, according to its spec ✨
this document specifies how to include an ICV for a packet, a message, and addresses in an Address Block within a message, using these TLVs 🔐 it also specifies how to handle an empty Packet TLV Block, and "mutable" fields, specifically the <msg-hop-count> and <msg-hop-limit> fields, if they're present in the Message Header when calculating ICVs. the goal is that the resulting ICV can be correctly verified by any recipient 👑
this doc describes a generic framework for creating ICVs and for including them in TLVs. in Section 12, it gives an example method for calculating ICVs, using a cryptographic function and a hash function, for which two TLV type extensions are allocated 🌈
this document does not specify a protocol. protocol specs that use the framework in this document will reference it in a normative way, and they MAY require implementing some or all of the algorithms described here 💅 since this doc isn't a protocol itself, key management and key exchange mechanisms are out of scope, and they MAY be specified in the protocol or protocol extension that uses this spec 🎀
4. Security Architecture 🔐
okay so MANET routing protocol specs can have a clause that lets a control message get rejected as "badly formed" or "insecure" before it's processed or forwarded 🙈. NHDP [RFC6130] and OLSRv2 [RFC7181] literally recognize outside reasons (like failing to verify an ICV) for rejecting a message that would otherwise count as "invalid for processing". iconic 💅
The whole architecture comes from the fact that with security in MANETs, "one size rarely fits all" 😭. Deployment domains want everything from "unbreakable" to "virtually none" 💀. The slay is that routing specs (and their implementations) can stay "generic", while extensions bring in the proper security mechanisms for each specific deployment domain ✨.
The MANET routing protocol "security architecture" this spec sits inside can be summarized like this:
- MANET routing protocol specifications, each with a clause allowing an extension to reject a message (prior to processing/forwarding) as "badly formed" or "insecure".
- MANET routing protocol security extensions, each rejecting messages as "badly formed" or "insecure", as appropriate for a given security requirement specific to a deployment domain.
- Code points and an exchange format for information, necessary for specification of such MANET routing protocol security extensions.
This document handles the last point on that list 🎀. It specifies a common exchange format for cryptographic ICVs and timestamps, with reservations made from within the Packet TLV, Message TLV, and Address Block TLV registries of [RFC5444], so they can be used by (and shared among) MANET routing protocol security extensions.
For the specific decomposition of an ICV using a cryptographic function and a hash function (specified in Section 12), this document specifies two IANA registries (see Section 13) for code points for hash functions and cryptographic functions 🧚.
With respect to [RFC5444], this document is:
- Intended to be used in the non-normative, but intended, mode of use described in Appendix B of [RFC5444].
- A specific example of the Security Considerations section of [RFC5444] (the authentication part).
5. Overview and Functioning 🦋
this doc gives us a syntactical representation of security-related info for use with [RFC5444] addresses, messages, and packets 🫶. It also specifies IANA registrations (see Section 13) of TLV types and type extension registries for those TLV types.
It also gives guidelines on how MANET routing protocols, and MANET routing protocol extensions using this spec, should treat ICV and Timestamp TLVs, plus mutable fields in messages 👑. Real talk, this spec is not a stand-alone protocol 😌. MANET routing protocols, and MANET routing protocol extensions using this spec, MUST provide instructions on how to handle packets, messages, and addresses with security information, associated as specified in this document.
This document specifies TLV type assignments (see Section 13) from the registries defined for Packet, Message, and Address Block TLVs in [RFC5444]. When a TLV type gets assigned from one of these registries, IANA creates a registry for type extensions for that TLV type. This doc specifies these type extension registries so it can pin down the internal structure (and the processing that goes with it) of the <value> field of a TLV 🍓.
Here's an example, as specified in this document 💖. An ICV TLV with type extension = 0 says the <value> field has no predefined internal structure and is simply a sequence of octets. An ICV TLV with type extension = 1 says the <value> field has a predefined internal structure and defines how to interpret it. An ICV TLV with type extension = 2 (added in this document) is the same as an ICV TLV with type extension = 1, except the integrity protection also covers the source address of the IP datagram carrying the packet, message, or Address Block 🌈.
So, with type extension = 1 or type extension = 2, the <value> field holds the result of combining a cryptographic function and a hash function, calculated over the contents of the packet, message, or Address Block. The <value> field has sub-fields that say which hash function and cryptographic function were used, as specified in Section 12 ✨.
Other documents can request assignments for other type extensions. If they do, they MUST specify their internal structure (if any) and interpretation 🙈.
6. General ICV TLV Structure 🎀
The value of the ICV TLV is:
<value> := <ICV-value>+where:
<ICV-value> is a field, of length <length> octets (except in a
multivalue Address Block TLV, where each <ICV-value> is of length
single-length octets) that contains the information to be
interpreted by the ICV verification process, as specified by the
type extension.Not gonna lie, this part doesn't say how to calculate the <ICV-value> or what its internal structure looks like, if there is one 🤷♀️. That info MUST be specified by the type extension for the ICV TLV type, see Section 13. This document specifies three such type extensions: one for ICVs without predefined structures, and two for ICVs built by combining a cryptographic function and a hash function 💅.
7. General Timestamp TLV Structure ⏰
The value of the Timestamp TLV is:
<value> := <time-value>+where:
<time-value> is a field, of length <length> octets (except in a
multivalue Address Block TLV, where each <time-value> is of length
single-length octets) that contains the timestamp.Same energy as the ICV one: this doesn't say how to calculate the <time-value> or what's inside it, if anything 🫠. That info MUST be specified by the type extension for the TIMESTAMP TLV type, see Section 13.
A timestamp is basically "freshness information" 🌸. Its setting and interpretation are up to the MANET routing protocol (or MANET routing protocol extension) that uses it. It can, for example, be a POSIX timestamp, a GPS timestamp, or just a simple sequence number. Ensuring time synchronization in a MANET can be genuinely hard, since the architecture is decentralized and the topology is highly dynamic because of mobility or other factors 😩. Specifying a time synchronization mechanism is out of scope for this document, so it's not gonna do that 🙅♀️.
8. Packet TLVs 📦
Two Packet TLVs are defined. One includes the cryptographic ICV of a packet. The other includes the timestamp for when that cryptographic ICV was calculated 🍭.
8.1. ICV Packet TLV
An ICV Packet TLV is an example of an ICV TLV as described in Section 6 💖. When figuring out the <ICV-value> for a packet, and adding an ICV Packet TLV to that packet, the following considerations MUST be applied:
- Because packets as defined in [RFC5444] are never forwarded by routers, no special considerations are required regarding mutable fields (i.e.,
<msg-hop-count>and<msg-hop-limit>), if present within any messages in the packet, when calculating the ICV. - Any ICV Packet TLVs already present in the Packet TLV Block MUST be removed before calculating the ICV, and the Packet TLV Block size MUST be recalculated accordingly.
- 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>field in the Packet Header MUST be cleared ('0'). - Any removed ICV Packet TLVs MUST be restored after having calculated the ICV, and the Packet TLV Block size MUST be recalculated accordingly.
- When any removed ICV Packet TLVs, and the newly calculated ICV Packet TLV, are added to the packet, if there is no Packet TLV Block, then one MUST be added, including setting (
'1') the phastlv bit in the<pkt-flags>field in the Packet Header.
Why do we remove existing ICV Packet TLVs before calculating? Because several ICV TLVs can get added to the same packet, e.g., using different ICV cryptographic and/or hash functions 🧩.
And why do we remove an empty Packet TLV Block? Because when the receiver is removing and verifying the ICV Packet TLV, if no other Packet TLVs are present, it can't tell the difference between an absent Packet TLV Block and an empty one 🤯. It's giving mystery, but the rule clears it up 💀.
8.2. TIMESTAMP Packet TLV
A TIMESTAMP Packet TLV is an example of a Timestamp TLV as described in Section 7 ⏰. If a packet contains one or more TIMESTAMP TLVs and one or more ICV TLVs, then the TIMESTAMP TLVs (as well as any other Packet TLVs) MUST be added to the packet before the ICV TLVs, so the timestamps and other TLVs get included in the calculation of the ICVs 🫶.
9. Message TLVs 💌
Two Message TLVs are defined. One includes the cryptographic ICV of a message. The other includes the timestamp for when that cryptographic ICV was calculated 🌷.
9.1. ICV Message TLV
An ICV Message TLV is an example of an ICV TLV as described in Section 6 🦋. When figuring out the <ICV-value> for a message, the following considerations MUST be applied:
- 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) when calculating the ICV. - Any ICV Message TLVs already present in the Message TLV Block MUST be removed before calculating the ICV, and the message size as well as the Message TLV Block size MUST be recalculated accordingly. Also, all relevant TLVs other than ICV TLVs MUST be added prior to ICV value calculation.
- Any removed ICV Message TLVs MUST be restored after having calculated the ICV, and the message size as well as the Message TLV Block size MUST be recalculated accordingly.
The reason we remove any ICV Message TLVs already present before calculating is the same as for packets: several ICV TLVs can get added to the same message, e.g., using different ICV cryptographic and/or hash functions 🧁.
9.2. TIMESTAMP Message TLV
A TIMESTAMP Message TLV is an example of a Timestamp TLV as described 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 Message TLVs) MUST be added to the message before the ICV TLVs, so the timestamps and other Message TLVs get included in the calculation of the ICV 💜.
10. Address Block TLVs 📍
Two Address Block TLVs are defined. One associates a cryptographic ICV with one or more addresses and their associated information. The other includes the timestamp for when that cryptographic ICV was calculated ✨.
10.1. ICV Address Block TLV 🦋
okay so an ICV Address Block TLV is just a specific flavour of the ICV TLV from Section 6 🫶 The ICV gets calculated over one or more addresses, plus any other values stuck to them, like other Address Block TLV <value> fields 💅 A MANET routing protocol (or a MANET routing protocol extension) using ICV Address Block TLVs MUST specify how those extra concatenated attributes get included in both the calculation and the verification of the ICV ✨ When you're figuring out an <ICV-value> for one or more addresses, this one rule MUST be applied:
- If other TLV values get concatenated with the addresses for the ICV calculation, those TLVs MUST NOT be ICV Address Block TLVs that are already attached to any of the addresses. 🚫
the reason for this is kinda genius 🧠 several ICVs can be stacked onto the same address (say, using different ICV crypto and/or hash functions), and the receiver doesn't know what order they were added in. so you can't let an ICV get baked into another ICV's calculation 🙈 that's the whole vibe 💜
10.2. TIMESTAMP Address Block TLV 🎀
a TIMESTAMP Address Block TLV is an example of a Timestamp TLV from Section 7 🕰️ now here's the tea: if an address has one or more TIMESTAMP TLVs AND one or more ICV TLVs, the relevant TIMESTAMP TLV <time-value>(s) MUST be included before the ICV value is calculated for the ICV TLV value. basically you glue them together with the address and any other values, just like Section 10.1 says ⏰✨
11. ICV: Basic ✨
the basic ICV is represented by an ICV TLV with type extension = 0 🌈 its TLV value is a plain bit-field with no specified structure, so there's no built-in hash function, crypto function, key ID, or other parameters hiding in there 🤷♀️ it also doesn't say how to calculate the <ICV-value>. instead it's assumed that whatever mechanism sets out how ICVs get calculated and verified (plus which parameters, if any, need to be swapped before using type extension = 0) is established outside this spec, like through admin configuration or some out-of-band signalling 📬
so for type extension = 0, the <ICV-value> is just:
<ICV-value> := <ICV-data>where <ICV-data> is a field of <length> octets (or single-length octets in a multivalue Address Block TLV) that holds the cryptographic ICV 🔐
12. ICV: Hash Function and Cryptographic Function 💅
one popular way to make an ICV is to combine a cryptographic function with a hash function applied to the content 👑 this section breaks that decomposition down, using either type extension = 1 or type extension = 2 in the ICV TLVs ✨
12.1. General ICV TLV Structure 🌸
this data structure lets you represent a cryptographic ICV, including which hash function and cryptographic function got used to calculate it 🧁
<ICV-value> := <hash-function>
<cryptographic-function>
<key-id-length>
<key-id>?
<ICV-data>where:
<hash-function> is a one-octet unsigned integer field that specifies the hash function 🔢
<cryptographic-function> is a one-octet unsigned integer field that specifies the cryptographic function 🔢
<key-id-length> is a one-octet unsigned integer field that specifies the length of the <key-id> field, counted in octets. the value zero (0x00) is reserved for using a single pre-installed, shared key 🔑
<key-id> is a field that specifies the key identifier of the key used to calculate the ICV of the message. it lets you uniquely tell apart different keys that came from the same originator. each key originator is responsible for making sure that the actively used keys it issues have distinct key identifiers 🫡 if <key-id-length> equals zero (0x00), the <key-id> field isn't in the TLV at all, and a single pre-installed, shared key is used 🗝️
<ICV-data> is a field with length <length> - 3 - <key-id-length> octets (except in a multivalue Address Block TLV, where it's single-length - 3 - <key-id-length> octets), and it holds the cryptographic ICV 💖
the version of this TLV in this section assumes that, unless said otherwise, calculating the ICV can be broken down into:
ICV-value = cryptographic-function(hash-function(content))some cases use a different combo of cryptographic function and hash function 🧩 the big one is the Hashed Message Authentication Code (HMAC) function, which is defined as in Section 13.12, using the hash function twice 🌀 using cryptographic-function "none" is provided for symmetry and possible future use, but it SHOULD NOT be used with any currently specified hash function 🙅♀️
the difference between the two type extensions: on top of everything the ICV covers with type extension = 1 (detailed in the following sections), the ICV with type extension = 2 MUST also cover the source address of the IP datagram carrying the corresponding packet, message, or Address Block 🌍
the <ICV-data> field MAY be truncated after it's calculated, and the length tells you that happened 📏 the truncation MUST be done as specified for the relevant cryptographic function (and the hash function, if that's relevant) ✂️
- When using truncation, the guidelines for minimal ICV length set out in [NIST-SP-800-107] MUST be followed. In particular, the
<ICV-data>field, when using HMAC, MUST NOT be truncated below 4 octets. 🚨 - The truncated ICV length MUST be so large that the probability of a successful dictionary attack is acceptably small. Such a success happens if the ICV of a spoofed packet or message gets verified 👀 The probability depends on (a) how many routers can be attacked, (b) how fast a router can receive packets or messages and try to verify their ICV, (c) the truncated ICV length, and (d) the lifetime of the network. If the truncated ICV length in bits is L, then
2^Lpackets or messages are needed to attack with certainty of success. With a verification rate of R packets/messages per second, applied to N routers over an available time of T, the probability of success is given byNRT/2^L. If this isn't allowed to exceed a probability of P, thenL > 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. 🧮💥
some of the cryptographic and hash functions listed in Section 13 need the length of the content being digitally signed to be a multiple of a certain number of octets 📐 so they define padding mechanisms. for example, AES-CMAC [RFC4493] has a padding mechanism for message lengths that aren't a multiple of 16 octets 🧷 implementations of the framework in this document MUST support the appropriate padding mechanisms, as specified in the cryptographic or hash function specifications 🫶
the hash function and the cryptographic function line up with the entries in two IANA registries, which are described in Section 13 📚
12.1.1. Rationale 🧠
the reason the hash function and the cryptographic function are split into two octets, instead of having every combination squished into a single octet (maybe as a TLV type extension), is that adding more hash or crypto functions later could lead to a non-contiguous number space, plus a smaller overall space 🌱
the reason there's no field listing the parameters of the cryptographic ICV in the TLV is that routers have to exchange or acquire keys before they can validate a cryptographic ICV anyway 🔑 any extra parameters can come along with the keys during that bootstrap process. so it isn't necessary, and it would even add overhead, to send the parameters in every message 🙅♀️
the reason for adding type extension = 2 is that the source address is used in some cases, like when processing HELLO messages in [RFC6130] 👋 this only applies to packets (which only ever travel one hop) and to messages (and their Address Blocks) that only travel one hop. it doesn't apply to messages that might get forwarded more than one hop, like Topology Control (TC) messages in [RFC7181] 🚫
12.1.2. Parameters 🎀
as described in Section 12.1.1, parameters are selected administratively on each router before using this framework in a MANET, on top of exchanging the keys between MANET routers 🗂️ this was a design decision in [RFC6622], and it's kept in this spec for backwards compatibility 🤝
the following parameters are RECOMMENDED, and they SHOULD be the ones chosen administratively, unless there are good reasons otherwise 🌟
- For crypto function RSA:
- Signature scheme: RSASSA-PSS with the default parameters:
rSASSA-PSS-Default-Identifier(as defined in [RFC3447]) - Common exponent: 65537
- Signature scheme: RSASSA-PSS with the default parameters:
- For crypto function ECDSA:
- Curve name: exchanged as part of key distribution
- 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. 📌
- For crypto function AES:
- Authentication algorithm: Cipher-Based Message Authentication Code (CMAC) (as defined in [RFC4493])
- Hash function: None
12.2. Considerations for Calculating the ICV 🦋
the considerations listed in the following subsections MUST be applied when calculating the ICV for Packet, Message, and Address Block TLVs, respectively 💜
12.2.1. ICV Packet TLV 💖
when determining the <ICV-data> for a packet, with type extension = 1:
- The ICV is calculated over the fields
<hash-function>,<cryptographic-function>,<key-id-length>, and, if present,<key-id>(in that order), followed by the entire packet. That includes the Packet Header, all Packet TLVs (other than ICV Packet TLVs), and all included messages. The considerations of Section 8.1 MUST be applied. 🧩
when determining the <ICV-data> for a packet, with type extension = 2:
- It's the same procedure as for type extension = 1, except the data used starts with a representation of the source address of the IP datagram carrying the packet, followed by the remaining data (as for type extension = 1). The representation of the source address is a single octet holding the address length (in octets), followed by that many octets holding the address in network byte order 🌍✨
12.2.2. ICV Message TLV ✨
Okay, so when you're figuring out the <ICV-data> for a message with type extension = 1, here's the recipe 🍓:
- The ICV gets calculated over <hash-function>, <cryptographic-function>, <key-id-length>, and (if it's there) <key-id>, in that exact order, and then over the entire message. The considerations in Section 9.1 MUST be applied.
When it's type extension = 2, it's basically the same recipe 💅, with one extra ingredient. The data now starts with the source address of the IP datagram carrying the message, then the rest of the stuff from type extension = 1. The source address is written as one octet holding the address length in octets, followed by that many octets of the address in network byte order 🧚.
12.2.3. ICV Address Block TLV
Same vibe for addresses! With type extension = 1, you calculate the ICV over <hash-function>, <cryptographic-function>, <key-id-length>, and (if present) <key-id> in that order, then over the addresses, and then over any other values that go with those addresses, like other Address Block TLV <value>s 🦋. Here's the catch 👀: a MANET routing protocol, or a MANET routing protocol extension, that uses ICV Address Block TLVs MUST spell out how any of that concatenated address-related attribute data gets included in the ICV verification process. The consideration in Section 10.1 MUST be applied too.
For type extension = 2, it's the same procedure again, except the data starts with the source address of the IP datagram carrying the Address Block 🌸. Same encoding as before: one octet for the address length, then the address bytes in network byte order. Then you add the remaining data, just like type extension = 1.
12.3. Example of a Message Including an ICV
Here's a sample message to make it click 🎀. It's derived from Appendix E of [RFC5444]. It has an ICV Message TLV whose value is an ICV that's 16 octets long, with a 4-octet key identifier. The Message TLV's type extension is 1, which means it's the specific ICV breakdown using a cryptographic function and a hash function, as covered in Section 12.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | MF=15 | MAL=3 | Message Length = 82 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Hop Count | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message TLV Block Length = 36 | TLV Type | MTLVF = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Len = 6 | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (cont) |TLV Type = ICV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTLVF = 144 | MTLVExt = 1 |Value Len = 23 | Hash Func |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Crypto Func | KeyID Len = 4 | Key Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Identifier (cont) | ICV Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 ICVAnd here's the legend so you can decode every abbreviation 🧠:
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 - Legend13. IANA Considerations 🌈
The IANA registrations for TLV Types and the TLV type extension registries in this specification replace the identical registrations and registries from [RFC6622]. Gone are the old ones, hello new ones 💜.
This specification defines the following TLV Types, replacing the original specifications in [RFC6622]:
- Two Packet TLV Types, allocated from the 0-223 range of the "Packet TLV Types" repository of [RFC5444], as listed in Table 1.
- Two Message TLV Types, allocated from the 0-127 range of the "Message TLV Types" repository of [RFC5444], as listed in Table 2.
- Two Address Block TLV Types, allocated from the 0-127 range of the "Address Block TLV Types" repository of [RFC5444], as listed in Table 3.
This specification updates the following registries that were created in [RFC6622]:
- A type extension registry for each of these TLV types, with values as listed in Tables 1, 2, and 3.
The following terms are used as defined in [BCP26]: "Namespace", "Registration", and "Designated Expert".
The following policy is used as defined in [BCP26]: "Expert Review".
13.1. Expert Review: Evaluation Guidelines
For TLV type extension registries where an Expert Review is required, the Designated Expert SHOULD take the same general recommendations into consideration as those specified by [RFC5444].
For both TIMESTAMP and ICV TLVs, functionally similar extensions for Packet, Message, and Address Block TLVs SHOULD be numbered identically.
13.2. Packet TLV Types
IANA has, in accordance with [RFC6622], made allocations from the "Packet TLV Types" namespace of [RFC5444] for the Packet TLVs listed in Table 1. IANA has modified this allocation as indicated.
+------+-------------+-----------+
| Type | Description | Reference |
+------+-------------+-----------+
| 5 | ICV | RFC 7182 |
| 6 | TIMESTAMP | RFC 7182 |
+------+-------------+-----------+
Table 1: Packet TLV Types13.3. Message TLV Types
IANA has, in accordance with [RFC6622], made allocations from the "Message TLV Types" namespace of [RFC5444] for the Message TLVs listed in Table 2. IANA has modified this allocation as indicated.
+------+-------------+-----------+
| Type | Description | Reference |
+------+-------------+-----------+
| 5 | ICV | RFC 7182 |
| 6 | TIMESTAMP | RFC 7182 |
+------+-------------+-----------+
Table 2: Message TLV Types13.4. Address Block TLV Types
IANA has, in accordance with [RFC6622], made allocations from the "Address Block TLV Types" namespace of [RFC5444] for the Packet TLVs listed in Table 3. IANA has modified this allocation as indicated.
+------+-------------+-----------+
| Type | Description | Reference |
+------+-------------+-----------+
| 5 | ICV | RFC 7182 |
| 6 | TIMESTAMP | RFC 7182 |
+------+-------------+-----------+
Table 3: Address Block TLV Types13.5. ICV Packet TLV Type Extensions
IANA has, in accordance with [RFC6622], made allocations from the "ICV Packet TLV Type Extensions" namespace of [RFC6622] for the Packet TLVs listed in Table 4. IANA has modified this allocation (including defining type extension = 2) as indicated.
+-----------+-------------------------------------------+-----------+
| Type | Description | Reference |
| Extension | | |
+-----------+-------------------------------------------+-----------+
| 0 | ICV of a packet | RFC 7182 |
| 1 | ICV, using a cryptographic function and a | RFC 7182 |
| | hash function, as specified in Section 12 | |
| | of this document | |
| 2 | ICV, using a cryptographic function and a | RFC 7182 |
| | hash function, and including the IP | |
| | datagram source address, as specified in | |
| | Section 12 of this document | |
| 3-251 | Unassigned; Expert Review | |
| 252-255 | Reserved for Experimental Use | RFC 7182 |
+-----------+-------------------------------------------+-----------+
Table 4: ICV Packet TLV Type ExtensionsYou can include more than one ICV Packet TLV with the same type extension in a packet, MAY do so, if they represent different ICV calculations (for example, with type extension 1 or 2 and a different cryptographic function and/or hash function, or with a different key identifier). But ICV Packet TLVs that carry what is declared to be the same information MUST NOT be included in the same packet. 🙅♀️
13.6. TIMESTAMP Packet TLV Type Extensions
okay so IANA 💅 went through [RFC6622] and made allocations from the "TIMESTAMP Packet TLV Type Extensions" namespace for the Packet TLVs in Table 5. They also modified that allocation, as noted. Here's the table 🎀
+-----------+-------------------------------------------+-----------+
| Type | Description | Reference |
| Extension | | |
+-----------+-------------------------------------------+-----------+
| 0 | Unsigned timestamp of arbitrary length, | RFC 7182 |
| | given by the TLV Length field. The MANET | |
| | routing protocol has to define how to | |
| | interpret this timestamp | |
| 1 | Unsigned 32-bit timestamp, as specified | RFC 7182 |
| | in [IEEE1003.1-2008] | |
| 2 | NTP timestamp format, as specified in | RFC 7182 |
| | [RFC5905] | |
| 3 | Signed timestamp of arbitrary length with | RFC 7182 |
| | no constraints such as monotonicity. In | |
| | particular, it may represent any random | |
| | value | |
| 4-251 | Unassigned; Expert Review | |
| 252-255 | Reserved for Experimental Use | RFC 7182 |
+-----------+-------------------------------------------+-----------+
Table 5: TIMESTAMP Packet TLV Type ExtensionsSo here's the rule: you can't have two TIMESTAMP Packet TLVs with the same type extension in one packet. That's a hard MUST NOT 🙅♀️
13.7. ICV Message TLV Type Extensions
IANA did the same thing here 🦋 going through [RFC6622], but this time for the "ICV Message TLV Type Extensions" namespace, covering the Message TLVs in Table 6. They modified the allocation too, and this one also defines type extension = 2 ✨
+-----------+-------------------------------------------+-----------+
| Type | Description | Reference |
| Extension | | |
+-----------+-------------------------------------------+-----------+
| 0 | ICV of a message | RFC 7182 |
| 1 | ICV, using a cryptographic function and a | RFC 7182 |
| | hash function, as specified in Section 12 | |
| | of this document | |
| 2 | ICV, using a cryptographic function and a | RFC 7182 |
| | hash function, and including the IP | |
| | datagram source address, as specified in | |
| | Section 12 of this document | |
| 3-251 | Unassigned; Expert Review | |
| 252-255 | Reserved for Experimental Use | RFC 7182 |
+-----------+-------------------------------------------+-----------+
Table 6: ICV Message TLV Type ExtensionsMultiple ICV Message TLVs with the same type extension MAY show up in one message, as long as they're different ICV calculations. Think type extension 1 or 2 with a different cryptographic function, hash function, or key identifier 🔑 But ICV Message TLVs that claim to carry the same information MUST NOT be put in the same message. No duplicates, bestie 💀
13.8. TIMESTAMP Message TLV Type Extensions
Same energy again 🌸 IANA went through [RFC6622] and made allocations from the "TIMESTAMP Message TLV Type Extensions" namespace for the Message TLVs in Table 7, then modified that allocation as indicated.
+-----------+-------------------------------------------+-----------+
| Type | Description | Reference |
| Extension | | |
+-----------+-------------------------------------------+-----------+
| 0 | Unsigned timestamp of arbitrary length, | RFC 7182 |
| | given by the TLV Length field. The MANET | |
| | routing protocol has to define how to | |
| | interpret this timestamp | |
| 1 | Unsigned 32-bit timestamp, as specified | RFC 7182 |
| | in POSIX [IEEE1003.1-2008] | |
| 2 | NTP timestamp format, as specified in | RFC 7182 |
| | [RFC5905] | |
| 3 | Signed timestamp of arbitrary length with | RFC 7182 |
| | no constraints such as monotonicity. In | |
| | particular, it may represent any random | |
| | value | |
| 4-251 | Unassigned; Expert Review | |
| 252-255 | Reserved for Experimental Use | RFC 7182 |
+-----------+-------------------------------------------+-----------+
Table 7: TIMESTAMP Message TLV Type ExtensionsOnly one TIMESTAMP Message TLV per type extension is allowed in a message, so two with the same type extension MUST NOT be included in a message 🚫
13.9. ICV Address Block TLV Type Extensions
IANA made allocations from the "ICV Address Block TLV Type Extensions" namespace of [RFC6622] for the Address Block TLVs in Table 8. They modified it as well, and that includes defining type extension = 2 🎀
+-----------+-------------------------------------------+-----------+
| Type | Description | Reference |
| Extension | | |
+-----------+-------------------------------------------+-----------+
| 0 | ICV of an object (e.g., an address) | RFC 7182 |
| 1 | ICV, using a cryptographic function and a | RFC 7182 |
| | hash function, as specified in Section 12 | |
| | of this document | |
| 2 | ICV, using a cryptographic function and a | RFC 7182 |
| | hash function, and including the IP | |
| | datagram source address, as specified in | |
| | Section 12 of this document | |
| 3-251 | Unassigned; Expert Review | |
| 252-255 | Reserved for Experimental Use | RFC 7182 |
+-----------+-------------------------------------------+-----------+
Table 8: ICV Address Block TLV Type ExtensionsMore than one ICV Address Block TLV with the same type extension MAY be associated with an address, as long as they're different ICV calculations (like type extension 1, or type extension 2 with a different cryptographic function, hash function, or key identifier). But ICV Address Block TLVs that claim to carry the same information MUST NOT be associated with the same address. Same rule, different vibe ✨
13.10. TIMESTAMP Address Block TLV Type Extensions
IANA went through [RFC6622] again 🧚 and made allocations from the "TIMESTAMP Address Block TLV Type Extensions" namespace for the Address Block TLVs in Table 9, then modified that allocation as indicated.
+-----------+-------------------------------------------+-----------+
| Type | Description | Reference |
| Extension | | |
+-----------+-------------------------------------------+-----------+
| 0 | Unsigned timestamp of arbitrary length, | RFC 7182 |
| | given by the TLV Length field. The MANET | |
| | routing protocol has to define how to | |
| | interpret this timestamp | |
| 1 | Unsigned 32-bit timestamp, as specified | RFC 7182 |
| | in POSIX [IEEE1003.1-2008] | |
| 2 | NTP timestamp format, as specified in | RFC 7182 |
| | [RFC5905] | |
| 3 | Signed timestamp of arbitrary length with | RFC 7182 |
| | no constraints such as monotonicity. In | |
| | particular, it may represent any random | |
| | value | |
| 4-251 | Unassigned; Expert Review | |
| 252-255 | Reserved for Experimental Use | RFC 7182 |
+-----------+-------------------------------------------+-----------+
Table 9: TIMESTAMP Address Block TLV Type ExtensionsTwo TIMESTAMP Address Block TLVs with the same type extension can't be associated with any address. So that's a MUST NOT too 🙈
13.11. Hash Functions
IANA created a registry 🌈 under [RFC6622] for hash functions that can be used when creating an ICV, as described in Section 12 of this document. The initial assignments and allocation policies are in Table 10, and IANA modified this allocation as indicated.
+---------+-----------+---------------------------------+-----------+
| Value | Algorithm | Description | Reference |
+---------+-----------+---------------------------------+-----------+
| 0 | none | The "identity function": The | RFC 7182 |
| | | hash value of an object is the | |
| | | object itself | |
| 1 | SHA-1 | [NIST-FIPS-180-4] | RFC 7182 |
| 2 | SHA-224 | [NIST-FIPS-180-4] | RFC 7182 |
| 3 | SHA-256 | [NIST-FIPS-180-4] | RFC 7182 |
| 4 | SHA-384 | [NIST-FIPS-180-4] | RFC 7182 |
| 5 | SHA-512 | [NIST-FIPS-180-4] | RFC 7182 |
| 6-251 | | Unassigned; Expert Review | |
| 252-255 | | Reserved for Experimental Use | RFC 7182 |
+---------+-----------+---------------------------------+-----------+
Table 10: Hash Function RegistryThe hash function registry is where the hash functions get their numbers, so it's a big deal for ICV calculations 👑
13.12. Cryptographic Functions ✨
okay bestie, so IANA made a registry for cryptographic functions 🔐 following [RFC6622], and it's the one from Section 12 of this document. 💅 The starting assignments and allocation policies live in Table 11, and IANA tweaked this allocation a little, as noted right there. 🦋
+---------+-----------+---------------------------------+-----------+
| Value | Algorithm | Description | Reference |
+---------+-----------+---------------------------------+-----------+
| 0 | none | The "identity function": The | RFC 7182 |
| | | value of an encrypted hash is | |
| | | the hash itself | |
| 1 | RSA | [RFC3447] | RFC 7182 |
| 2 | DSA | [NIST-FIPS-186-4] | RFC 7182 |
| 3 | HMAC | [RFC2104] | RFC 7182 |
| 4 | 3DES | [NIST-SP-800-67] | RFC 7182 |
| 5 | AES | [NIST-FIPS-197] | RFC 7182 |
| 6 | ECDSA | [RFC6090] | RFC 7182 |
| 7-251 | | Unassigned; Expert Review | |
| 252-255 | | Reserved for Experimental Use | RFC 7182 |
+---------+-----------+---------------------------------+-----------+
Table 11: Cryptographic Function Registry14. Security Considerations 🛡️
bestie, real talk: this document doesn't specify a protocol 🙈. What it does is give you a syntactical component for cryptographic ICVs of messages and packets, as defined in [RFC5444]. 🧩 It can be used to address security issues of a MANET routing protocol or MANET routing protocol extension, so it has the same security considerations as [RFC5444]. 🔒
In addition, a MANET routing protocol or MANET routing protocol extension that uses this specification MUST specify how to use the framework and the TLVs presented in this document. 👑 In addition, the protection that the MANET routing protocol or MANET routing protocol extensions attain by using this framework MUST be described. No skipping, no vibes-only security 😭
As an example 🎀, a MANET routing protocol that uses this component to reject "badly formed" or "insecure" messages if a control message does not contain a valid ICV SHOULD indicate the security assumption that if the ICV is valid, the message is considered valid. It also SHOULD indicate the security issues that are counteracted by this measure (e.g., link or identity spoofing) as well as the issues that are not counteracted (e.g., compromised keys). Those compromised keys are the main character villain here 💀
15. Acknowledgements 💖
The authors would like to thank Bo Berry (Cisco), Alan Cullen (BAE Systems), Justin Dean (NRL), Paul Lambert (Marvell), Jerome Milan (Ecole Polytechnique), and Henning Rogge (FGAN) for their constructive comments on [RFC6622]. 🫶
The authors also appreciate the detailed reviews of [RFC6622] from the Area Directors, in particular Stewart Bryant (Cisco), Stephen Farrell (Trinity College Dublin), and Robert Sparks (Tekelec), as well as Donald Eastlake (Huawei) from the Security Directorate. 🌸
The authors would like to thank Justin Dean (NRL) and Henning Rogge (FGAN) for their constructive comments on this specification. ✨
16. References 📚
16.1. Normative References
- [BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
- [IEEE1003.1-2008] IEEE, "Portable Operating System Interface (POSIX)", IEEE 1003.1-2008, Base Specifications, Issue 7, December 2008.
- [NIST-FIPS-180-4] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS 180-4, March 2012.
- [NIST-FIPS-186-4] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", FIPS 186-4, July 2013.
- [NIST-FIPS-197] National Institute of Standards and Technology, "Specification for the Advanced Encryption Standard (AES)", FIPS 197, November 2001.
- [NIST-SP-800-107] National Institute of Standards and Technology, "Recommendation for Applications Using Approved Hash Algorithms", SP 800-107, Revision 1, August 2012.
- [NIST-SP-800-67] National Institute of Standards and Technology, "Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher", Special Publication 800-67, Revision 1, January 2012.
- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
- [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The AES-CMAC Algorithm", RFC 4493, June 2006.
- [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format", RFC 5444, February 2009.
- [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.
- [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, February 2011.
16.2. Informative References
- [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", RFC 6130, April 2011.
- [RFC6622] Herberg, U. and T. Clausen, "Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)", RFC 6622, May 2012.
- [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, "The Optimized Link State Routing Protocol Version 2", RFC 7181, April 2014.
Authors' Addresses 🧑💻
Ulrich Herberg
Fujitsu Laboratories of America
1240 E. Arques Ave.
Sunnyvale, CA 94085
USA
EMail: ulrich@herberg.name
URI: http://www.herberg.name/
Thomas Heide Clausen
LIX, Ecole Polytechnique
91128 Palaiseau Cedex
France
Phone: +33 6 6058 9349
EMail: T.Clausen@computer.org
URI: http://www.thomasclausen.org/
Christopher Dearlove
BAE Systems Advanced Technology Centre
West Hanningfield Road
Great Baddow, Chelmsford
United Kingdom
Phone: +44 1245 242194
EMail: chris.dearlove@baesystems.com
URI: http://www.baesystems.com/📦 where this page comes from
- ietf: rfc7182 2014-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms