Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)
obsoleted by
- rfc-7182 — Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)
Extracted elements (26)
Existing ICV TLVs are removed before calculating a new ICV to support attaching multiple ICVs (using different ICV functions) to the same packet, message, or address without each ICV covering the others.
Hash function and cryptographic function are encoded as two separate 8-bit fields rather than as a single combined octet or TLV type extension, because adding further hash or cryptographic functions in the future could lead to a non-contiguous number space if combined.
No field listing cryptographic ICV parameters is included in the TLV because routers must exchange or acquire keys before validating an ICV; additional parameters can be provided during that bootstrap process, making in-message parameter transmission unnecessary and wasteful. The ICV length is implicitly derivable as <length> - 3 - <key-id-length>.
The security architecture is deliberately 'oblivious to security' at the base protocol layer, allowing extensions to reject messages as 'badly formed' or 'insecure'. This reflects that MANET deployment domains have varying security requirements and a one-size-fits-all approach is inappropriate.
This specification is intended to be used in the non-normative but intended mode of use described in Appendix B of RFC 5444, and serves as a specific example of the authentication aspect of RFC 5444's Security Considerations.
A MANET routing protocol or extension using Address Block ICV TLVs MUST specify how to include any concatenated attributes of the address in the ICV verification process. TLVs concatenated with the address for calculating the ICV MUST NOT include Address Block ICV TLVs already associated with the address.
A MANET routing protocol or extension using this specification MUST specify how to use the framework and the TLVs presented, and MUST describe the protection attained by using this framework.
Any Packet ICV TLVs already present in the Packet TLV block MUST be removed before calculating the ICV, the Packet TLV block size MUST be recalculated accordingly, and removed ICV TLVs MUST be restored after calculating the ICV value.
For a Message ICV TLV with type extension=1, the ICV is calculated over <hash-function>, <cryptographic-function>, <key-id-length>, and <key-id> (in that order) concatenated with the entire message; the considerations in Section 9.1 (zeroing mutable fields, removing existing ICV TLVs) MUST be applied.
For a Packet ICV TLV with type extension=1, the ICV is calculated over <hash-function>, <cryptographic-function>, <key-id-length>, and <key-id> (in that order) concatenated with the entire packet including packet header, all Packet TLVs (excluding Packet ICV TLVs), and all included messages.
If a message contains a TIMESTAMP TLV and an ICV TLV, the TIMESTAMP TLV SHOULD be added to the message before the ICV TLV so that it is included in the ICV calculation.
If a packet contains both a TIMESTAMP TLV and an ICV TLV, the TIMESTAMP TLV SHOULD be added to the packet before any ICV TLV so that it is included in the ICV calculation.
If both a TIMESTAMP TLV and an ICV TLV are associated with an address, the TIMESTAMP TLV value MUST be covered when calculating the ICV (concatenated with the address and any other values).
MANET routing protocols and extensions using this specification MUST provide instructions for how to handle packets, messages, and addresses with security information, as this specification does not stand alone.
Type extension documents other than those defined here MUST specify the internal structure (if any) and interpretation of the <value> field for their assigned type extension.
When calculating the ICV for a Message ICV TLV, the fields <msg-hop-limit> and <msg-hop-count>, if present, MUST both be assumed to have the value 0. Any Message ICV TLVs already present MUST be removed before calculating and MUST be restored afterward.
Two Packet TLVs (ICV type=5, TIMESTAMP type=6), two Message TLVs (ICV type=5, TIMESTAMP type=6), and two Address Block TLVs (ICV type=5, TIMESTAMP type=6) are defined for affixing ICVs and timestamps to RFC 5444 packets, messages, and addresses respectively. IANA assigns the same numerical value to Packet, Message, and Address Block TLV types with the same name.
IANA allocated Address Block TLV type 5 (ICV) and type 6 (TIMESTAMP) from the RFC 5444 Address Block TLV Types namespace (0-127 range), with type extension registries mirroring those of the Packet and Message TLV types.
IANA allocated Message TLV type 5 (ICV) and type 6 (TIMESTAMP) from the RFC 5444 Message TLV Types namespace (0-127 range), with type extension registries. TIMESTAMP type extensions include: 0 (arbitrary unsigned), 1 (POSIX 32-bit), 2 (NTP format per RFC 5905), 3 (signed arbitrary).
IANA allocated Packet TLV type 5 (ICV) and type 6 (TIMESTAMP) from the RFC 5444 Packet TLV Types namespace (0-223 range), with type extension registries. Type extensions 0 and 1 are defined; 2-251 are Unassigned (Expert Review); 252-255 are Experimental Use.
IANA created a Cryptographic Functions registry with initial values: 0=none (identity), 1=RSA, 2=DSA, 3=HMAC, 4=3DES, 5=AES, 6=ECDSA; values 7-251 are Unassigned (Expert Review); 252-255 are Experimental Use.
IANA created a Hash Functions registry with initial values: 0=none (identity), 1=SHA1, 2=SHA224, 3=SHA256, 4=SHA384, 5=SHA512; values 6-251 are Unassigned (Expert Review); 252-255 are Experimental Use.
A MANET routing protocol using this framework to reject messages without a valid ICV SHOULD indicate the security assumption that a valid ICV implies message validity, identify the security issues counteracted (e.g., link or identity spoofing), and identify issues not counteracted (e.g., compromised keys).
For ICV type extension=1, the <ICV-value> field has the structure: <hash-function> (8-bit), <cryptographic-function> (8-bit), <key-id-length> (8-bit), <key-id> (variable, absent if key-id-length=0x00), and <ICV-data> (length - 3 - key-id-length octets). The value 0x00 for <key-id-length> indicates a pre-installed shared key.
The ICV TLV value field is <ICV-value>, a field of <length> octets containing the ICV data. For type extension=0 (basic), the value is simply <ICV-data>, an unsigned integer of <length> octets with no pre-defined internal structure.
The Timestamp TLV value field is <time-value>, an unsigned integer of <length> octets containing the timestamp. The interpretation (UNIX timestamp, GPS timestamp, sequence number, etc.) is defined by the using MANET routing protocol.