Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)
updates
Extracted elements (24)
Different ICV TLV type extensions are used for HELLO messages (type-extension 2) versus TC messages (type-extension 1) because HELLO message ICVs also protect the IP datagram source address, which NHDP uses to determine neighbor interface addresses and which is not necessarily contained in the HELLO message itself. TC messages are forwarded in new packets and thus have no single IP datagram source address.
ICV Packet TLVs MAY be used instead of or in addition to message-level protection. For OLSRv2, packet protection has different properties than message protection; when packets contain multiple messages, packet protection has lower overhead in space and computation time.
No key management mechanism is specified; Section 23.6 of RFC 7181 provides a rationale based on BCP107 explaining why automated key management requirements do not apply for OLSRv2 and NHDP.
POSIX time (1-second resolution) is chosen for the timestamp because many MANET use cases cannot achieve sub-second time synchronization due to unreliable and high-delay channels, mobility, and resource limitations. A finer granularity is RECOMMENDED only when message validity times fall below 1 second.
Routers whose implementation of NHDP and/or OLSRv2 does not include this integrity protection will be ignored by routers using it, and the two sets of routers will form disjoint MANETs by design. The unsecured MANET retains some information about the secured MANET but cannot use it due to lack of recognized symmetric links.
A message MUST be considered invalid for processing if: it lacks exactly one TIMESTAMP TLV of the selected version, lacks exactly one ICV TLV using the selected algorithm and key identifier, or if validation of either the TIMESTAMP TLV or the ICV TLV fails.
An implementation of RFC 6130 and RFC 7181 MAY use more than one ICV TLV in a message, but multiple ICV TLVs MUST each use different keys or a different algorithm to calculate the ICV.
An implementation using this mechanism MUST NOT use the same type extension for more than one TIMESTAMP TLV in a message.
Before generating ICVs or validating messages, a router MUST acquire shared secret key(s) to be used by all participating routers; this specification does not define how keys are acquired.
During ICV generation, all existing ICV TLVs MUST be temporarily removed and msg-hop-count and msg-hop-limit MUST be temporarily set to 0; all TIMESTAMP TLVs MUST be inserted before adding ICV TLVs.
During ICV validation, all ICV Message TLVs are temporarily removed and msg-hop-count and msg-hop-limit are set to 0; if the recalculated ICV differs from the TLV value, message validation fails.
For TC messages, the ICV TLV MUST use type-extension 1; for HELLO messages, type-extension 2; with hash-function 3 (SHA-256) and cryptographic-function 3 (HMAC).
If the current POSIX time minus the timestamp in a TC message's TIMESTAMP TLV is greater than MAX_TC_TIMESTAMP_DIFF, the TC message MUST be silently discarded.
Implementations of RFC 6130 and RFC 7181 MUST support an HMAC-SHA-256 ICV TLV, and deployments SHOULD use it except when use of a different algorithm is more appropriate.
Implementations of RFC 6130 and RFC 7181 using this mechanism MUST support a TIMESTAMP TLV based on POSIX time, and deployments SHOULD use it if clocks in all routers can be synchronized with sufficient precision.
Implementations of RFC 6130 (NHDP) and RFC 7181 (OLSRv2) MUST include this integrity and replay protection mechanism, and deployments SHOULD use it except when a different security mechanism is more appropriate.
MAX_HELLO_TIMESTAMP_DIFF and MAX_TC_TIMESTAMP_DIFF MUST be at least as great as the maximum expected age of a message (time between sending and receipt by all intended destinations), and SHOULD be as large as required but not significantly larger.
Messages conforming to this mechanism MUST contain at least one ICV Message TLV and at least one TIMESTAMP Message TLV, added after message generation and before transmission.
MAX_HELLO_TIMESTAMP_DIFF and MAX_TC_TIMESTAMP_DIFF are router parameters controlling the maximum acceptable age of HELLO and TC messages respectively for replay protection. MAX_TC_TIMESTAMP_DIFF MAY be made dependent on the number of hops a TC message has traveled.
The mechanism uses two TLV types defined in RFC 7182: an ICV Message TLV (carrying an HMAC-SHA-256 integrity check value) and a TIMESTAMP Message TLV (carrying POSIX time). These are inserted into NHDP HELLO and OLSRv2 TC messages between RFC 5444 parsing/generation and NHDP/OLSRv2 processing.
Identity spoofing is countered because only routers possessing the shared secret key can generate a valid ICV TLV. However, when using shared keys, individual routers cannot be distinguished, so a compromised router with valid keys may still spoof another router's identity.
Link spoofing is countered by the same mechanism as identity spoofing: only routers possessing the shared secret key can generate valid ICV TLVs, preventing falsification of link existence or state.
Replay attacks are partly countered by timestamp validation: an attacker can only replay messages within the configured time window (MAX_HELLO_TIMESTAMP_DIFF or MAX_TC_TIMESTAMP_DIFF). If no synchronized clocks are available, replay attacks cannot be countered by this mechanism; an alternative TIMESTAMP TLV with monotonic sequence numbers may provide partial mitigation but requires storing observed sequence numbers.
This mechanism does not detect or prevent security attacks by routers that possess the shared secret key (e.g., compromised routers), does not provide key management, and relies on an out-of-band mechanism for distributing shared secret keys.