Host Identity Protocol Version 2 (HIPv2)
Extracted elements (31)
HIPv2 introduces HIT Suites grouping signature algorithm, hash function, and truncation to achieve crypto agility — the primary concern raised by the IESG against RFC 5201. DH group negotiation begins in I1 (unsigned) but the Responder's signed DH_GROUP_LIST in R1 enables the Initiator to detect downgrade manipulation of the unsigned I1 list.
The HIT (a fixed 128-bit hash) is used as the operational protocol identifier instead of the variable-length public key (HI) because different algorithms produce keys of different lengths, making the raw HI unsuitable as a packet identifier or state index. The HIT also provides a consistent format independent of the underlying identity technology.
The puzzle uses a CPU-bound hash function rather than a memory-bound function. The protocol developers explicitly considered and rejected memory-bound functions, preferring the simplicity and single-hash verifiability of a CPU-bound approach.
The R1 packet deliberately omits a timestamp for replay protection. The protocol developers explicitly decided NOT to include a timestamp to avoid problems with global time synchronization between hosts.
All HIP implementations MUST implement, at minimum, the ESP transport format for HIP [RFC7402]. This is the required method for matching data packets to HIP associations via the ESP SPI.
HIP implementations MUST support RSA and ECDSA for generating the Host Identity (HI). Additional algorithms MAY be supported.
If the DH group chosen in R1 does not match the best common preference of both parties, the Initiator MUST either restart the BEX with a new I1 or abort — indicating a downgrade attack. The Initiator MUST verify the R1 signature before restarting or aborting, and MUST silently ignore R1 if the signature is invalid.
In opportunistic mode (all-zeros destination HIT), HIP implementations MUST NOT place any expectation that the peer's HI returned in R1 matches any HI previously seen from that address, since the peer may be a different host.
In opportunistic mode, when a Responder's HIT Suite is not supported, the Initiator MUST treat R1 packets with unsupported Responder HITs as potentially forged and MUST NOT use any parameters from the unverified R1 besides the HIT_SUITE_LIST.
In the puzzle exchange, the Initiator must find #J such that the lowest-order #K bits of RHASH(#I | HIT_I | HIT_R | #J) are zero. The Initiator SHOULD give up after exceeding the puzzle Lifetime specified in the PUZZLE parameter.
The HIT MUST be generated according to the ORCHID generation method in RFC 7343 using a specific context ID (0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA) and an input encoding the Host Identity field from a HIP payload packet.
The R1 generation counter SHOULD be preserved across system reboots and BEX invocations. The counter MUST be incremented at least as often as every time old R1s cease to be valid, and SHOULD never be decremented to prevent replay of higher-numbered R1s.
To prevent precomputation attacks, the Responder MUST select #I such that the Initiator cannot guess it, and the construction MUST allow the Responder to verify that #I was selected by itself and not the Initiator. The Responder MUST periodically change its puzzle secret.
When a host receives user data for a non-existing HIP association it MUST discard the packet. Any ICMP responses sent to inform the sender MUST be rate-limited to prevent abuse.
The HIP Base Exchange (BEX) is a four-packet SIGMA-compliant exchange: I1 (trigger with DH group list), R1 (puzzle + DH public value + signed HI), I2 (puzzle solution + DH public value + optionally encrypted HI + signature), R2 (HMAC + signature). The Responder remains stateless until receiving a valid I2.
The HIP puzzle mechanism enables the Responder to delay state creation until receiving a valid I2. The Responder verifies puzzle solutions with a single hash computation and can reject invalid ones before creating state, performing public-key verification, or computing DH. Difficulty #K is adjustable based on trust level and load.
The Host Identity Tag (HIT) is a 128-bit self-certifying hash of the Host Identity, structured as an ORCHID with an IANA-assigned IPv6 prefix, a 4-bit OGA field encoding the HIT Suite ID, and a 96-bit truncated hash. Its fixed length matches an IPv6 address, enabling use in fixed-size API and protocol fields.
The R1 generation counter is a monotonically increasing 64-bit counter protecting Initiators from R1 replay attacks. There SHOULD be a separate counter per local Host Identity. When multiple R1s arrive, the Initiator SHOULD respond to the one with the largest generation counter.
The UPDATE packet carries a monotonically increasing sequence number and is explicitly acknowledged by the peer via an ACK parameter. UPDATE is protected by both HIP_MAC and HIP_SIGNATURE; requiring only signature processing for UPDATE would be a DoS vector against intermediate systems.
This document updates multiple IANA registries including: HIP Parameter Types, HIP Packet Types, HIP Version Numbers, Group IDs for the DIFFIE_HELLMAN parameter, HIT Suite IDs (4-bit OGA field values), HIP Cipher IDs, HIP Transport Modes, and HIP Notify Message Types. Protocol number 139 is assigned to HIP.
Both the Initiator's and Responder's HITs are transported in cleartext in BEX packets, allowing an eavesdropper with a priori knowledge of the parties to identify them. Encrypting the Initiator's HI in I2 does not provide privacy against such an attacker and may interfere with packet-inspecting middleboxes.
HIP provides layered replay protection: I1 replays are absorbed by stateless R1 generation; R1 replays are countered by the monotonic R1 generation counter; I2 replays are defeated by the puzzle tied to the Initiator's HIT; R2 and UPDATE replays are detected by HMAC verification before the more expensive signature check.
Opportunistic mode (all-zeros destination HIT) is vulnerable to man-in-the-middle attacks because the Initiator has no a priori public key information about the peer. An on-path attacker can insert itself by providing its own HI. However, subsequent datagrams within the same HIP association cannot be MitM-compromised after the BEX completes.
The puzzle mechanism protects the Responder from CPU- and memory-targeted DoS attacks by requiring the Initiator to expend CPU cycles before any association-specific state is created. Puzzle difficulty #K is tunable, and the Responder SHOULD use heuristics to detect DoS attacks and adjust #K accordingly.
HIP defines eight states: UNASSOCIATED (start), I1-SENT (BEX initiating), I2-SENT (waiting for R2 as initiator), R2-SENT (waiting for confirming data as responder), ESTABLISHED (association active), CLOSING (teardown initiated, UAL timeout), CLOSED (association closed), and E-FAILED (BEX failed after retries). Transitions are triggered by packet events, timeouts (I1_RETRIES_MAX, I2_RETRIES_MAX, UAL, UAL+MSL), and data-send requests.
HIP parameters use a TLV format: Type (2 bytes, where bit 0 of the type indicates criticality), Length (2 bytes, value field length in bytes), and Value (variable, padded to an 8-byte boundary). Parameter Type values enforce an ordering constraint — parameters MUST be in ascending order by type value within a packet.
The DIFFIE_HELLMAN parameter carries a Group ID (1 byte identifying the DH group) and the sender's DH public value. The DH_GROUP_LIST parameter carries an ordered list of Group IDs representing the sender's preferences, enabling DH group negotiation starting from the I1 packet.
The ENCRYPTED parameter wraps one or more HIP parameters under confidentiality protection. It contains a 4-byte Reserved field, an algorithm-dependent Initialization Vector (IV), and the ciphertext of the encrypted parameters using the cipher negotiated via HIP_CIPHER.
The HIP payload header is 40 bytes, containing: Next Header (1 byte), Header Length (1 byte, in 8-byte units excluding first 8 bytes), Packet Type (1 byte), Version (4 bits) and Reserved (4 bits), HIP Controls (2 bytes), Checksum (2 bytes), Sender's HIT (16 bytes), Receiver's HIT (16 bytes), followed by variable-length TLV parameters.
The HOST_ID parameter encodes the Host Identity public key. It includes HI Length (2 bytes), DI Type and DI Length fields, the algorithm-specific public key (RSA encoded per RFC 3110, DSA per RFC 2536, or ECDSA per RFC 6090), and an optional Domain Identifier.
The PUZZLE parameter (Section 5.2.4) carries: K (1 byte, difficulty), Lifetime (1 byte, in seconds as 2^value), Opaque (2 bytes, state cookie), and a random value #I (RHASH_len/8 bytes). The SOLUTION parameter (Section 5.2.5) echoes #I and provides the found #J.