Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)
obsoletes
- rfc-6622 — Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)
Extracted elements (29)
An empty Packet TLV Block must be removed when computing ICV because a receiver cannot distinguish between an originally absent Packet TLV Block and an empty one, which would cause ICV verification to fail.
Hash function and cryptographic function are encoded as two separate one-octet fields rather than combined in a single octet or TLV type extension, because future additions could create a non-contiguous and smaller combined number space.
No cryptographic parameters field is included in the TLV because routers must exchange keys before validating an ICV; additional parameters can be distributed with the keys, making in-message parameter transmission redundant overhead.
Type extension 2 (ICV over IP source address) was added because protocols like NHDP (RFC 6130) use the IP source address to identify links; without protecting it, the address is vulnerable to tampering if it is not otherwise present in the packet/message payload. This extension is only applicable to single-hop packets and messages.
This document obsoletes RFC 6622 and replaces its TLV type and type extension registrations. The normative change from RFC 6622 is that TIMESTAMP TLVs MUST (changed from SHOULD) be added to a message before ICV TLVs when both are present.
For ECDSA, the hash function MUST be pinned to the curve: SHA-256 for P-256, SHA-384 for P-384, etc.
For ICV type extension = 2, the ICV MUST additionally cover the source address of the IP datagram, represented as a single length octet followed by the address in network byte order, prepended to the remaining input data.
ICV TLVs that carry what is declared to be the same information MUST NOT be included in the same packet, message, or address association; multiple ICV TLVs with the same type extension are permitted only when they represent different ICV calculations.
If a message contains one or more TIMESTAMP TLVs and one or more ICV TLVs, the TIMESTAMP TLVs (as well as any other Message TLVs) MUST be added to the message before the ICV TLVs.
If a packet contains one or more TIMESTAMP TLVs and one or more ICV TLVs, the TIMESTAMP TLVs (and any other Packet TLVs) MUST be added to the packet before the ICV TLVs, so that timestamps are covered by the ICV calculation.
Implementations MUST support appropriate padding mechanisms as specified by the relevant cryptographic or hash function (e.g., AES-CMAC padding for non-multiples of 16 octets).
More than one TIMESTAMP Packet TLV or TIMESTAMP Message TLV with the same type extension MUST NOT be included in the same packet or message, respectively.
TIMESTAMP Address Block TLV <time-value>(s) MUST be included (concatenated with associated addresses) before calculating the ICV value in an ICV Address Block TLV.
Using cryptographic-function 'none' is provided for symmetry but SHOULD NOT be used with any currently specified hash function.
When calculating the ICV for an ICV Address Block TLV, the TLVs concatenated with the addresses MUST NOT include any ICV Address Block TLVs already associated with those addresses, to avoid ordering ambiguity when multiple ICVs are present.
When calculating the ICV for an ICV Message TLV, the fields <msg-hop-limit> and <msg-hop-count> MUST both be assumed to have value 0, and all existing ICV Message TLVs MUST be removed before calculation and restored afterward.
When calculating the ICV for an ICV Packet TLV, any existing ICV Packet TLVs MUST be removed from the Packet TLV Block before computing, and an empty Packet TLV Block MUST be removed with the phastlv bit cleared; both MUST be restored after computation.
When ICV truncation is used, the guidelines in NIST SP 800-107 MUST be followed; in particular, <ICV-data> using HMAC MUST NOT be truncated below 4 octets.
ICV TLV carries a cryptographic Integrity Check Value in a <ICV-value> field whose length is <length> octets (or single-length octets in a multivalue Address Block TLV). Three type extensions are defined: 0 (opaque bit-field), 1 (hash+crypto function decomposition), and 2 (same as 1 but also covers the IP datagram source address).
TIMESTAMP TLV carries freshness information in a <time-value> field of <length> octets (or single-length in multivalue Address Block TLV). The timestamp interpretation (POSIX, NTP, sequence number, etc.) is determined by the type extension and the using protocol.
Address Block TLV Types registry (RFC 5444): type 5 = ICV, type 6 = TIMESTAMP, both updated from RFC 6622 to reference RFC 7182.
Cryptographic Functions registry: 0 = none (identity), 1 = RSA, 2 = DSA, 3 = HMAC, 4 = 3DES, 5 = AES, 6 = ECDSA; 7-251 unassigned (Expert Review); 252-255 reserved for experimental use.
Hash Functions registry: 0 = none (identity), 1 = SHA-1, 2 = SHA-224, 3 = SHA-256, 4 = SHA-384, 5 = SHA-512; 6-251 unassigned (Expert Review); 252-255 reserved for experimental use.
ICV TLV Type Extensions registries (Packet, Message, Address Block): extension 0 = opaque ICV, 1 = ICV with hash+crypto function, 2 = same as 1 including IP source address; 3-251 unassigned (Expert Review); 252-255 reserved for experimental use.
Message TLV Types registry (RFC 5444): type 5 = ICV, type 6 = TIMESTAMP, both updated from RFC 6622 to reference RFC 7182.
Packet TLV Types registry (RFC 5444): type 5 = ICV, type 6 = TIMESTAMP, both updated from RFC 6622 to reference RFC 7182.
TIMESTAMP TLV Type Extensions registries (Packet, Message, Address Block): extension 0 = unsigned arbitrary-length timestamp, 1 = unsigned 32-bit POSIX timestamp, 2 = NTP format (RFC 5905), 3 = signed arbitrary-length timestamp; 4-251 unassigned (Expert Review).
A MANET routing protocol using this framework MUST describe how the framework and TLVs are used and MUST describe the protection attained. It SHOULD indicate which security threats are counteracted (e.g., link or identity spoofing) and which are not (e.g., compromised keys).
ICV TLV value with type extension 1 or 2 encodes: <hash-function> (1 octet), <cryptographic-function> (1 octet), <key-id-length> (1 octet), optional <key-id> (<key-id-length> octets), and <ICV-data> (remaining octets). ICV-data length = <length> - 3 - <key-id-length>.