Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)
obsoletes
- rfc-5202 — Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)
Extracted elements (29)
BEET mode is RECOMMENDED over the separate address-rewriting implementation because it binds identities, encryption, and locators in one place (the SAD), whereas the alternative requires keeping a separate address-rewriting database in sync with the SAD.
Host Identity representations are not carried in user data packet headers; instead, the ESP SPI serves as a compressed reference to the HIT pair. This avoids adding explicit protocol headers to every data packet while still enabling host context lookup.
Including ESP_TRANSFORM in R1 adds clarity to TRANSPORT_FORMAT_LIST but may initiate negotiations for unselected transforms. Resource-constrained devices will likely restrict support to a single transform, making the overhead negligible.
HIP and ESP traffic have known issues with middlebox traversal; other specifications (e.g., RFC 5770) address operating HIP and ESP over UDP. Middlebox traversal is explicitly out of scope for this document.
When co-existing with a standards-compliant IPsec implementation, in tunnel mode overlap cases traffic MUST be encrypted with both HIP ESP SA and the IPsec SA. In transport mode overlap, the IPsec encryption MAY be skipped if local policy allows, to avoid double encryption.
A host receiving an UPDATE requesting ESP SA update MUST reply with an UPDATE containing ESP_INFO. If the incoming UPDATE contained a DIFFIE_HELLMAN parameter, the reply MUST also contain a DIFFIE_HELLMAN parameter.
All HIP implementations MUST support AES-128-CBC and AES-256-CBC. The mandatory suite for interoperability is AES-128-CBC with HMAC-SHA-256; NULL with HMAC-SHA-256 SHOULD also be supported.
All HIP packets (protocol 139) MUST bypass ESP processing. A host MUST initiate a rekey if its incoming ESP sequence counter is about to overflow, and MUST NOT replace keying material until rekeying completes.
Anti-replay protection MUST be used in an ESP SA established with HIP, and a 64-bit sequence number MUST be used. Each host MUST rekey before its sequence number reaches 2^64.
Authentication-only suites (NULL encryption, AES-CMAC-96, AES-GMAC) MUST NOT be accepted if offered by the peer unless local policy is explicitly set to allow authentication-only mode, to prevent downgrade attacks.
SPI selection SHOULD be random, following Section 2.1 of RFC 4303. A different SPI SHOULD be used for each HIP exchange with a particular host to avoid replay attacks. When a host rekeys, the SPI MUST be changed.
The HIP implementation MUST ensure that SPI values used for HIP SAs are not used for IPsec or other SAs, and vice versa, to avoid collisions when co-existing with a standards-compliant IPsec implementation.
The sender of an ESP_TRANSFORM parameter MUST ensure no more than six Suite IDs are included; a recipient MUST be prepared to handle parameters containing more than six Suite IDs. The parameter MUST contain at least one mandatory Suite ID.
When the HIP association is removed, the related ESP SAs MUST also be removed. Dropping a HIP association requires dropping the associated ESP SAs.
BEET (Bound End-to-End Tunnel) mode uses ESP transport mode syntax with tunnel mode semantics: HITs serve as inner addresses and IP addresses as outer addresses, with header replacement at endpoints rather than tunneling. BEET mode is internal to a host and transparent to peers.
ESP keys are drawn from KEYMAT after HIP keys in the following order: SA-gl encryption key, SA-gl authentication key, SA-lg encryption key, SA-lg authentication key, where HOST_g has the greater HIT value and HOST_l has the lower value.
ESP SA rekeying uses three UPDATE messages: I' sends UPDATE with ESP_INFO and optional DIFFIE_HELLMAN; R' replies with UPDATE containing ESP_INFO, ACK, and optional DIFFIE_HELLMAN; I' sends final UPDATE with ACK. Both sides create new SA pairs during rekeying.
ESP SA setup during the base exchange uses three messages: R1 carries ESP_TRANSFORM (responder's supported transforms), I2 carries ESP_TRANSFORM (selected transform) and ESP_INFO (initiator's SPI), and R2 carries ESP_INFO (responder's SPI).
The ESP SPI in HIP serves as a compressed representation of a HIT pair. Only the pair <DST IP address, SPI> uniquely identifies the receiver HIT; the same SPI value may be used by multiple hosts at different times.
Two ESP Security Associations are created per HIP association: SA-RI (Responder-to-Initiator) and SA-IR (Initiator-to-Responder). The Initiator defines SPI-RI during R1 processing; the Responder defines SPI-IR during I2 processing and communicates it in R2.
IANA created a new registry for 'ESP Transform Suite IDs' under the HIP Parameters registries, with an IETF Review registration procedure. Suite IDs 1 and 7-15 are defined; values 2-6 are marked DEPRECATED; value 0 is RESERVED.
Two HIP Parameter Types are registered: ESP_INFO (Type 65, Length 12) and ESP_TRANSFORM (Type 4095, variable length), updated from RFC 5202 to this specification in the 'Parameter Types' namespace.
Two NOTIFY Message Types are registered: NO_ESP_PROPOSAL_CHOSEN (value 18), indicating none of the proposed ESP transforms was acceptable, and INVALID_ESP_TRANSFORM_CHOSEN (value 19), indicating the chosen transform was not offered by the Responder.
Rekeying UPDATE packets are signed but cannot be encrypted because intermediate systems using the SPI must be able to inspect the new SPI values they carry. This is an explicit design tradeoff between middlebox support and confidentiality of rekeying information.
The initial keying material is generated via the HIP Diffie-Hellman base exchange. Rekeying forces new Diffie-Hellman keying material generation via UPDATE messages. The UPDATE message exchange is protected using existing HIP association keys (HMAC and signature).
During rekeying, a host MUST NOT generate new UPDATEs while it has an outstanding ESP SA update request (unless restarting). A system transitions from using old SAs to new SAs after receiving both an ACK for its UPDATE and the peer's corresponding UPDATE parameters.
The BEET mode pseudo header for IPv4 options (Next Header 94) consists of a 1-octet Next Header, 1-octet Header Len, 1-octet Pad Len, 1-octet Reserved, followed by optional padding (0 or 4 octets of NOP) and the original IPv4 options, padded to an 8-octet boundary.
The ESP_INFO parameter (Type 65, Length 12) carries a 16-bit Reserved field, a 16-bit KEYMAT Index, a 32-bit OLD SPI, and a 32-bit NEW SPI. OLD SPI is zero during initial SA setup; KEYMAT Index is zero when new Diffie-Hellman keying material is generated.
The ESP_TRANSFORM parameter (Type 4095, variable length) carries a 16-bit Reserved field followed by one or more 16-bit Suite IDs identifying the ESP cipher and authentication transform combination to be used.