RFC 7402
Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)
RFC 7402: Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) 💖
Title block tea ☕: this one is RFC 7402, written by P. Jokela (Ericsson Research NomadicLab), R. Moskowitz (HTT Consulting), and J. Melen (Ericsson Research NomadicLab). It's a Standards Track doc, published April 2015, ISSN 2070-1721, under the IETF stream. It obsoletes RFC 5202, so 5202 is out and this is the new hotness 🔥.
Abstract ✨
okay so this memo specifies an Encapsulating Security Payload (ESP) based mechanism for sending user data packets, made to work with the Host Identity Protocol (HIP) 🦋. It also obsoletes RFC 5202, bestie, so update your bookmarks 📌.
Status of This Memo 📜
This is an Internet Standards Track document. 🌸
It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 5741. 💅
For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7402. 🧚
Copyright Notice 💜
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. 🎀
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Simplified BSD License. 🙈
Table of Contents 🗂️
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................4
3. Using ESP with HIP ..............................................4
3.1. ESP Packet Format ..........................................5
3.2. Conceptual ESP Packet Processing ...........................5
3.2.1. Semantics of the Security Parameter Index (SPI) .....6
3.3. Security Association Establishment and Maintenance .........6
3.3.1. ESP Security Associations ...........................6
3.3.2. Rekeying ............................................7
3.3.3. Security Association Management .....................8
3.3.4. Security Parameter Index (SPI) ......................8
3.3.5. Supported Ciphers ...................................8
3.3.6. Sequence Number .....................................9
3.3.7. Lifetimes and Timers ................................9
3.4. IPsec and HIP ESP Implementation Considerations ............9
3.4.1. Data Packet Processing Considerations ..............10
3.4.2. HIP Signaling Packet Considerations ................10
4. The Protocol ...................................................11
4.1. ESP in HIP ................................................11
4.1.1. IPsec ESP Transport Format Type ....................11
4.1.2. Setting Up an ESP Security Association .............11
4.1.3. Updating an Existing ESP SA ........................12
5. Parameter and Packet Formats ...................................13
5.1. New Parameters ............................................13
5.1.1. ESP_INFO ...........................................13
5.1.2. ESP_TRANSFORM ......................................15
5.1.3. NOTIFICATION Parameter .............................16
5.2. HIP ESP Security Association Setup ........................17
5.2.1. Setup during Base Exchange .........................17
5.3. HIP ESP Rekeying ..........................................18
5.3.1. Initializing Rekeying ..............................19
5.3.2. Responding to the Rekeying Initialization ..........19
5.4. ICMP Messages .............................................20
5.4.1. Unknown SPI ........................................20
6. Packet Processing ..............................................20
6.1. Processing Outgoing Application Data ......................20
6.2. Processing Incoming Application Data ......................21
6.3. HMAC and SIGNATURE Calculation and Verification ...........21
6.4. Processing Incoming ESP SA Initialization (R1) ............22
6.5. Processing Incoming Initialization Reply (I2) .............22
6.6. Processing Incoming ESP SA Setup Finalization (R2) ........23
6.7. Dropping HIP Associations .................................23
6.8. Initiating ESP SA Rekeying ................................23
6.9. Processing Incoming UPDATE Packets ........................24
6.9.1. Processing UPDATE Packet: No Outstanding
Rekeying Request ...................................25
6.10. Finalizing Rekeying ......................................26
6.11. Processing NOTIFY Packets ................................26
7. Keying Material ................................................27
8. Security Considerations ........................................27
9. IANA Considerations ............................................28
10. References ....................................................29
10.1. Normative References .....................................29
10.2. Informative References ...................................30
Appendix A. A Note on Implementation Options ......................32
Appendix B. Bound End-to-End Tunnel Mode for ESP ..................32
B.1. Protocol Definition ........................................33
B.1.1. Changes to Security Association Data Structures .....33
B.1.2. Packet Format .......................................34
B.1.3. Cryptographic Processing ............................36
B.1.4. IP Header Processing ................................36
B.1.5. Handling of Outgoing Packets ........................37
B.1.6. Handling of Incoming Packets ........................38
B.1.7. Handling of IPv4 Options ............................39
Acknowledgments ...................................................40
Authors' Addresses ................................................401. Introduction 🌈
okay so in the Host Identity Protocol Architecture [HIP-ARCH], hosts are identified with public keys 🔑. The Host Identity Protocol (HIP) [RFC7401] base exchange lets any two HIP-supporting hosts authenticate each other and create a HIP association between themselves. During the base exchange, the hosts generate a piece of shared keying material using an authenticated Diffie-Hellman exchange. It's giving secure handshake energy 🤝.
The HIP base exchange specification [RFC7401] doesn't describe any transport formats or methods for user data during the actual communication. It only defines that it is mandatory to implement the Encapsulating Security Payload (ESP) [RFC4303] based transport format and method. So this document is where we spell out how ESP is used with HIP to carry the actual user data 📦.
To be more specific, this document specifies a set of HIP protocol extensions and how to handle them 🛠️. With these extensions, a pair of ESP Security Associations (SAs) is created between the hosts during the base exchange. The resulting ESP Security Associations use keys drawn from the keying material (KEYMAT) generated during the base exchange. Once the HIP association and the required ESP SAs have been established between the hosts, the user data communication is protected using ESP. This document also specifies methods to update an existing ESP Security Association 🔄.
It should be noted that representations of Host Identity are not carried explicitly in the headers of user data packets 👀. Instead, the ESP Security Parameter Index (SPI) is used to indicate the right host context. The SPIs are selected during the HIP ESP setup exchange. For user data packets, ESP SPIs (in possible combination with IP addresses) are used indirectly to identify the host context, which means no extra explicit protocol headers are needed. Lowkey genius 🧠.
HIP and ESP traffic have known issues with middlebox traversal (RFC 5207 [RFC5207]). Other specifications exist for running HIP and ESP over UDP. (RFC 5770 [RFC5770] is an experimental specification, and others are being developed.) Middlebox traversal is out of scope for this document 🚫.
This document obsoletes RFC 5202. 💀
2. Conventions Used in This Document 📝
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 🎀
3. Using ESP with HIP 🦋
The HIP base exchange is used to set up a HIP association between two hosts. The base exchange provides two-way host authentication and key material generation, but it doesn't give any means for protecting data communication between the hosts 🙅♀️. In this document, we specify the use of ESP for protecting user data traffic after the HIP base exchange. Note that this use of ESP is intended only for host-to-host traffic, and security gateways are not supported. Main character energy, but only for hosts 💅.
To support ESP use, the HIP base exchange messages need some minor additions to the parameters they carry. In the R1 packet, the Responder adds the possible ESP transforms in an ESP_TRANSFORM parameter before sending it to the Initiator. The Initiator gets the proposed transforms, selects one of them, and adds it to the I2 packet in an ESP_TRANSFORM parameter. In this I2 packet, the Initiator also sends the SPI value it wants to be used for ESP traffic flowing from the Responder to the Initiator. This information is carried using the ESP_INFO parameter. When the ESP SA setup is finalized, the Responder sends its SPI value to the Initiator in the R2 packet, again using ESP_INFO. It's a whole choreographed dance 💃✨.
3.1. ESP Packet Format 📦
The ESP specification [RFC4303] defines the ESP packet format for IPsec. The HIP ESP packet looks exactly the same as the IPsec ESP transport format packet. The semantics, however, are a bit different, and they're described in more detail in the next subsection. Same look, different vibes 🌸.
3.2. Conceptual ESP Packet Processing ✨
okay so there's more than one way to do ESP packet processing in HIP 💅 One option is to use a standards compliant, unmodified IPsec implementation [RFC4303], add some extra transport checksum processing on top of it, and use IP addresses as the indexes that point to the right host context. Super clean, very chill 🦋
When you're using a standards compliant IPsec implementation that uses IP addresses in the Security Policy Database (SPD) and Security Association Database (SAD), the packet processing may go through these steps 🌸 For outgoing packets, assuming the upper-layer pseudo header was built using IP addresses, the implementation recalculates the upper-layer checksums using Host Identity Tags (HITs). After that, it swaps the packet's source and destination addresses back to the corresponding IP addresses. The packet then goes to IPsec ESP for transport mode handling, and from there the encrypted packet heads out to the network. When an ESP packet comes in, it goes through IPsec ESP transport mode handling first. After decryption, the source and destination IP addresses get replaced with HITs, and then the upper-layer checksums get verified before the packet is passed up to the upper layer. the whole thing is so satisfying 😭
Another way to do packet processing is BEET (Bound End-to-End Tunnel) mode (see Appendix B) 🧚 In BEET mode, the ESP packet is formatted like a transport mode packet, but the connection behaves like tunnel mode. The "outer" addresses are the IP addresses, and the "inner" addresses are the HITs. For outgoing traffic, once the packet is encrypted, its IP header gets swapped for a new one that has IP addresses instead of HITs, and then it's sent to the network. When an ESP packet is received, the SPI value and the integrity protection together let the packet be securely tied to the right HIT pair 🔥 The header is then replaced with a new one containing HITs, and the packet gets decrypted. BEET mode is completely internal to a host and doesn't require the corresponding host to implement it. Instead, the corresponding host can use ESP transport mode and do the HIT-to-IP conversions outside of ESP. main character energy, literally 👑
3.2.1. Semantics of the Security Parameter Index (SPI) 🎀
okay the SPI is what ESP uses to find the right Security Association for incoming packets 💖 With HIP, SPIs get extra special significance, because they're a compressed representation of a pair of HITs. So SPIs MAY be used by intermediary systems to provide services like address mapping ✨ Here's the tea: since the SPI only means something at the receiver, only the < DST, SPI > pair (where DST is a destination IP address) uniquely identifies the receiver HIT at any given moment. The same SPI value may be used by several hosts. And a single < DST, SPI > value can point to different hosts and contexts at different times, depending on which host is currently reachable at that DST 🙈
Each host picks its own SPI for the packets it wants to receive from its peer. This lets it pick different SPIs for different peers 💅 The SPI selection SHOULD be random, and the rules in Section 2.1 of the ESP specification [RFC4303] must be followed. A different SPI SHOULD be used for each HIP exchange with a particular host, and the reason is to avoid a replay attack 🛡️ Also, when a host rekeys, the SPI MUST be changed. And if a host switches over to a different IP address, it MAY change the SPI too.
One method of SPI creation that meets all of the above is to concatenate the HIT with a 32-bit random or sequential number, hash the result (using SHA1), and then use the high-order 32 bits as the SPI 🍓
The selected SPI gets sent to the peer in the third (I2) and fourth (R2) packets of the base HIP exchange. If the SPI changes later, that gets signaled with ESP_INFO parameters 🌈
3.3. Security Association Establishment and Maintenance 🧁
3.3.1. ESP Security Associations 💜
In HIP, ESP Security Associations are set up between the HIP nodes during the base exchange [RFC7401]. Existing ESP SAs can be updated later using UPDATE messages. One reason to update an ESP SA later is, for example, needing to rekey the SA because the sequence number is about to roll over ✨
When a HIP association gets set up, each association is linked to two ESP SAs: one for incoming packets and one for outgoing packets 🦋 The Initiator's incoming SA matches up with the Responder's outgoing one, and vice versa. The Initiator defines the SPI for its incoming association, as described in Section 3.2.1. This SA is called SA-RI, and its SPI is called SPI-RI. In the same way, the Responder's incoming SA matches the Initiator's outgoing SA. That one is called SA-IR, and its SPI is called SPI-IR 💖
The Initiator creates SA-RI as part of R1 processing, before sending out the I2, as explained in Section 6.4. The keys are derived from KEYMAT, as defined in Section 7. The Responder creates SA-RI as part of I2 processing; see Section 6.5.
The Responder creates SA-IR as part of I2 processing, before sending out R2; see Section 6.5. The Initiator creates SA-IR when it processes R2; see Section 6.6 🔥
The initial session keys are drawn from the generated keying material, KEYMAT, after the HIP keys have been drawn as specified in [RFC7401] 🌸
When the HIP association is removed, the related ESP SAs MUST also be removed. no leftovers allowed, bestie 🧹
3.3.2. Rekeying 🔄
After the initial HIP base exchange and SA establishment, both hosts are in the ESTABLISHED state. There are no longer Initiator and Responder roles, and the association is symmetric. In this subsection, the party that starts the rekey procedure is called I' and the peer is called R' 🫶
An existing HIP-created ESP SA may need updating during the lifetime of the HIP association. This document specifies how to rekey an existing HIP-created ESP SA, using the UPDATE message. The ESP_INFO parameter we introduced above is used for this purpose 🎀
I' starts the ESP SA updating process when it's needed (see Section 6.8). It creates an UPDATE packet with the required information and sends it to the peer node. The old SAs are still in use, as long as local policy allows it 💅
R', after receiving and processing the UPDATE (see Section 6.9), generates new SAs: SA-I'R' and SA-R'I'. It doesn't start using the new outgoing SA yet. It keeps using the old one, so for a little while there are two SA pairs towards the same peer host, which is a whole mood 🌈 The SPI for the new outgoing SA, SPI-R'I', is specified in the ESP_INFO parameter that came in the UPDATE packet. For the new incoming SA, R' generates a new SPI value, SPI-I'R', and includes it in the response UPDATE packet ✨
When I' gets a response UPDATE from R', it generates new SAs, as described in Section 6.9: SA-I'R' and SA-R'I'. I' starts using the new outgoing SA right away 🚀
R' starts using the new outgoing SA when it receives traffic on the new incoming SA, or when it receives the UPDATE ACK confirming that the rekeying is complete. After that, R' can remove the old SAs 🧚 Similarly, once I' receives traffic from the new incoming SA, it can safely remove the old SAs. so smooth 🦋
3.3.3. Security Association Management 🌷
An SA pair is indexed by its 2 SPIs and its 2 HITs (both the local and the remote HITs, since a system can have more than one HIT) 💜 An inactivity timer is RECOMMENDED for all SAs. If the state calls for deleting an SA, a timer gets set so late-arriving packets still have a place to land 🙈
3.3.4. Security Parameter Index (SPI) 🍭
The SPIs in ESP give a simple compression of the HIP data from all packets after the HIP exchange. This does require a per HIT-pair Security Association (and SPI), and it means less policy granularity compared to other Key Management Protocols like Internet Key Exchange (IKE) [RFC7296] 💖
When a host updates the ESP SA, it gives its peer a new inbound SPI and gets a new outbound SPI from that peer 🔁
3.3.5. Supported Ciphers 🔐
All HIP implementations MUST support AES-128-CBC and AES-256-CBC [RFC3602]. If the Initiator doesn't support any of the transforms the Responder offers, it should abandon the negotiation and tell the peer with a NOTIFY message about the unsupported transform ❌
On top of AES-128-CBC, all implementations SHOULD implement the ESP NULL encryption algorithm. When ESP NULL encryption is used, it MUST be used together with SHA-256 authentication, as specified in Section 5.1.2 🧃
When an authentication-only suite is used (NULL, AES-CMAC-96, and AES-GMAC are examples), the suite MUST NOT be accepted if the peer offers it, unless the local policy for that peer is explicitly set to allow an authentication-only mode. This is to stop sessions from being downgraded to authentication-only mode when one side's policy asks for privacy on the session 🛑 no downgrade arcs, periodt 💀
3.3.6. Sequence Number 🔢
The Sequence Number field is MANDATORY when ESP is used with HIP 🫡 Anti-replay protection MUST be used in any ESP SA established with HIP. When ESP is used with HIP, a 64-bit sequence number MUST be used. That means each host MUST rekey before its sequence number reaches 2^64 💅
When a 64-bit sequence number is used, the higher 32 bits are NOT included in the ESP header. They're just kept local to both peers. See [RFC4301] ✨
3.3.7. Lifetimes and Timers ⏳
HIP doesn't negotiate any lifetimes. All ESP lifetimes are local policy 💜 The only lifetimes a HIP implementation MUST support are sequence number rollover (for replay protection), and it SHOULD support timing out inactive ESP SAs. An SA times out if no packets are received on that SA. Implementations SHOULD support a configurable SA timeout value. Implementations MAY support lifetimes for the various ESP transforms. Each implementation SHOULD implement per-HIT configuration of the inactivity timeout, which lets statically configured HIP associations stay alive for days, even when they're inactive 🌙
3.4. IPsec and HIP ESP Implementation Considerations ⚙️
When HIP runs on a node that uses a standards compliant IPsec, a few issues need to be considered 🎀
The HIP implementation must be able to co-exist with other IPsec keying protocols. When the HIP implementation selects the SPI value, a collision may happen if it isn't implemented properly. To avoid that possibility, the HIP implementation MUST ensure that the SPI values used for HIP SAs are not used for IPsec or other SAs, and vice versa 🫶
Incoming packets that use an SA not negotiated by HIP MUST NOT be processed as described in Section 3.2, paragraph 2. The SPI identifies the correct SA for packet decryption, and it MUST be used to identify that the packet has an upper-layer checksum calculated as specified in [RFC7401] 🦋
3.4.1. Data Packet Processing Considerations ✨
okay so for outbound traffic, the SPD (or coordinated SPDs, if there are two -- one for HIP and one for IPsec) MUST make sure packets meant for HIP processing get a HIP-enabled SA, and packets meant for IPsec processing get an IPsec-enabled SA. The SP then MUST be bound to the matching SA, and non-HIP packets will not be processed by this SA. Data from a socket that isn't using HIP MUST NOT have its checksum recalculated (as described in Section 3.2, paragraph 2), and that data MUST NOT be passed to the SP or SA created by HIP. 💅
it's possible that with overlapping policies, an outgoing packet gets handled by both IPsec and HIP 👀. In that case, the HIP association can be end to end, while the IPsec SA is for encryption between the HIP host and a security gateway. When there's a security gateway ESP association, ESP always uses tunnel mode 🧚
with IPsec tunnel mode it's kinda hard to tell during HIP SA processing whether the IPsec ESP SA has the same final destination 😭. So traffic MUST be encrypted with both the HIP ESP SA and the IPsec SA whenever the IPsec ESP SA is used in tunnel mode.
with IPsec transport mode, the connection endpoints are the same. BUT for HIP data packets, you can't avoid HIP SA processing, and mapping the HIP data packet's IP addresses to the right HITs needs SPI values from the ESP header 🫶. So for a transport mode IPsec SA, the IPsec encryption MAY be skipped to avoid double encryption, if the local policy allows.
3.4.2. HIP Signaling Packet Considerations 🌸
generally, HIP signaling packets should follow the same processing as HIP data packets, bestie.
with IPsec tunnel mode, HIP signaling packets are always encrypted using an IPsec ESP SA. Lowkey this hides the HIP signaling packets from any HIP middleboxes sitting on the path between the originating host and the security gateway 🙈
with IPsec transport mode, HIP signaling packets MAY skip the IPsec ESP SA encryption if the local policy allows. This lets the HIP middleboxes handle the HIP signaling packets as they pass through 🦋
4. The Protocol 🎀
in this section, we get into the protocol for setting up an ESP association to be used with a HIP association 🔥
4.1. ESP in HIP 💜
4.1.1. IPsec ESP Transport Format Type
the HIP handshake signals the TRANSPORT_FORMAT_LIST parameter in the R1 and I2 messages. This parameter is a list of the supported HIP transport formats of the sending host, in order of preference 📋. The transport format type for IPsec ESP is the type number of the ESP_TRANSFORM parameter, which is 4095 ✨
4.1.2. Setting Up an ESP Security Association 🧁
setting up an ESP Security Association between hosts using HIP happens by including parameters in the last three messages (R1, I2, and R2 messages) of the four-message HIP base exchange 💖
Initiator Responder
I1
---------------------------------->
R1: ESP_TRANSFORM
<----------------------------------
I2: ESP_TRANSFORM, ESP_INFO
---------------------------------->
R2: ESP_INFO
<----------------------------------the R1 message has the ESP_TRANSFORM parameter, where the sending host lists the possible ESP transforms it's willing to use for the ESP SA 🍓
including the ESP_TRANSFORM parameter in the R1 message adds clarity to the TRANSPORT_FORMAT_LIST, but it may kick off negotiations for transforms that end up unselected 🤔. Resource-constrained devices will most likely restrict support to a single transform to save ROM overhead, and the extra parameter adds negligible overhead for unconstrained devices 🌈
the I2 message is the response to an ESP_TRANSFORM received in the R1 message. The sender must select one of the proposed ESP transforms from the ESP_TRANSFORM parameter in the R1 message, and include the selected one in the ESP_TRANSFORM parameter in the I2 packet. On top of the transform, the host includes the ESP_INFO parameter, which contains the SPI value to be used by the peer host 🔑
in the R2 message, the ESP SA setup gets finalized ✅. The packet contains the SPI information the Initiator needs for the ESP SA.
4.1.3. Updating an Existing ESP SA 🔄
updating works in three messages. The HIP UPDATE message is used to update the parameters of an existing ESP SA. The UPDATE mechanism and message are defined in [RFC7401], and the extra parameters for updating an existing ESP SA are described here 💅
here's a typical exchange when an existing ESP SA gets updated. The messages include the SEQ and ACK parameters the UPDATE mechanism requires 👑
H1 H2
UPDATE: SEQ, ESP_INFO [, DIFFIE_HELLMAN]
----------------------------------------------------->
UPDATE: SEQ, ACK, ESP_INFO [, DIFFIE_HELLMAN]
<-----------------------------------------------------
UPDATE: ACK
----------------------------------------------------->the host that wants to update the ESP SA creates and sends an UPDATE message. That message has the ESP_INFO parameter, which carries the old SPI value that was used, the new SPI value to be used, and the index value for the keying material. That index is the point where the next keys get drawn from 🧚. If new keying material needs to be generated, the UPDATE message also contains the DIFFIE_HELLMAN parameter defined in [RFC7401].
the host that receives an UPDATE message asking to update an existing ESP SA MUST reply with an UPDATE message 📨. In the reply, the host sends the ESP_INFO parameter with the matching values: old SPI, new SPI, and the keying material index. If the incoming UPDATE had a DIFFIE_HELLMAN parameter, the reply packet MUST also contain a DIFFIE_HELLMAN parameter 🫶
5. Parameter and Packet Formats 📦
in this section, we present the new and modified HIP parameters, plus the modified HIP packets 💖
5.1. New Parameters 🌟
two HIP parameters are defined for setting up ESP transport format associations in HIP communication and for rekeying existing ones 🦋. The NOTIFICATION parameter, described in [RFC7401], also has two error values defined for this specification 🙈
Parameter Type Length Data
ESP_INFO 65 12 Remote's old SPI,
new SPI, and other info
ESP_TRANSFORM 4095 variable ESP Encryption and
Authentication Transform(s)5.1.1. ESP_INFO 🎀
during the establishment and update of an ESP SA, both hosts have to transmit their SPI values to each other. Hosts also need the index value into the KEYMAT when they're drawing keys from the generated keying material. The ESP_INFO parameter is how the SPI values and the KEYMAT index information get passed between the hosts 🔑
during the initial ESP SA setup, each host sends the SPI value it wants its peer to use when sending ESP data to it. That value goes in the NEW SPI field of the ESP_INFO parameter. Since there's no old value in the initial setup, the OLD SPI field is set to zero. The OLD SPI field may also be zero when additional SAs get set up between HIP hosts, for example with multihomed HIP hosts [RFC5206]. Just know that this kind of use is beyond the scope of this specification 🚫
the KEYMAT index value points to the place in the KEYMAT where the keying material for the ESP SAs gets drawn from 🧚. The KEYMAT index value is zero only when ESP_INFO is sent during a rekeying process and new keying material is generated 💜
during the life of an SA established by HIP, one of the hosts may need to reset the Sequence Number to one and rekey 😭. The reason could be an approaching sequence number wrap in ESP, or a local policy on how long a key can be used. Rekeying ends the current SAs and starts new ones on both peers 🔄
during the rekeying process, the ESP_INFO parameter is used to transmit the changed SPI values and the keying material index 🌈
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | KEYMAT Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OLD SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NEW SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+here's what each field means 📝
Type: 65Length: 12KEYMAT Index: the index, in bytes, where ESP keys continue to be drawn from KEYMAT. If the packet includes a new Diffie-Hellman key and ESP_INFO is sent in an UPDATE packet, this field MUST be zero. If ESP_INFO is included in base exchange messages, the KEYMAT Index MUST have the index value of the point where the ESP SA keys are drawn from. Note that the length of this field limits how much keying material can be drawn from KEYMAT. If that amount is exceeded, the packet MUST contain a new Diffie-Hellman key 🚨OLD SPI: the old SPI for data sent to the address(es) associated with this SA. For an initial SA setup, the OLD SPI value is zero.NEW SPI: the new SPI for data sent to the address(es) associated with this SA.
5.1.2. ESP_TRANSFORM ✨
okay so the ESP_TRANSFORM parameter is what gets used during ESP SA establishment 🫶 The first party sends a selection of transform families in it, and the peer has to pick one of the proposed values and drop it into the response ESP_TRANSFORM parameter 💅
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Suite ID #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Suite ID #2 | Suite ID #3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Suite ID #n | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's the breakdown of the fields 🎀
Typeis4095.Lengthis the length in octets, excluding Type, Length, and padding.Reservedis zero when sent and ignored when received.Suite IDdefines the ESP Suite to be used.
The following Suite IDs can be used 🍓
Suite ID Value
RESERVED 0 [RFC7402]
AES-128-CBC with HMAC-SHA1 1 [RFC3602], [RFC2404]
DEPRECATED 2 [RFC7402]
DEPRECATED 3 [RFC7402]
DEPRECATED 4 [RFC7402]
DEPRECATED 5 [RFC7402]
DEPRECATED 6 [RFC7402]
NULL with HMAC-SHA-256 7 [RFC2410], [RFC4868]
AES-128-CBC with HMAC-SHA-256 8 [RFC3602], [RFC4868]
AES-256-CBC with HMAC-SHA-256 9 [RFC3602], [RFC4868]
AES-CCM-8 10 [RFC4309]
AES-CCM-16 11 [RFC4309]
AES-GCM with an 8-octet ICV 12 [RFC4106]
AES-GCM with a 16-octet ICV 13 [RFC4106]
AES-CMAC-96 14 [RFC4493], [RFC4494]
AES-GMAC 15 [RFC4543]The sender of an ESP transform parameter MUST make sure that there are no more than six (6) Suite IDs in one ESP transform parameter. Conversely, a recipient MUST be prepared to handle received transform parameters that contain more than six Suite IDs. The limited number of Suite IDs sets the maximum size of the ESP_TRANSFORM parameter. As the default configuration, the ESP_TRANSFORM parameter MUST contain at least one of the mandatory Suite IDs. There MAY be a configuration option that allows the administrator to override this default.
Mandatory implementations: AES-128-CBC with HMAC-SHA-256. NULL with HMAC-SHA-256 SHOULD also be supported (see also Section 3.3.5).
Under some conditions, it is possible to use Traffic Flow Confidentiality (TFC) [RFC4303] with ESP in BEET mode. However, the definition of such an operation is left for future work and must be done in a separate specification. 🧚
5.1.3. NOTIFICATION Parameter 🔥
The HIP base specification defines a set of NOTIFICATION error types. The following error types are required for describing errors in ESP Transform crypto suites during negotiation.
NOTIFICATION PARAMETER - ERROR TYPES Value
------------------------------------ -----
NO_ESP_PROPOSAL_CHOSEN 18
None of the proposed ESP Transform crypto suites was
acceptable.
INVALID_ESP_TRANSFORM_CHOSEN 19
The ESP Transform crypto suite does not correspond to
one offered by the Responder.5.2. HIP ESP Security Association Setup 🌸
The ESP Security Association is set up during the base exchange. The following subsections define the ESP SA setup procedure using both base exchange messages (R1, I2, R2) and UPDATE messages.
5.2.1. Setup during Base Exchange 💖
5.2.1.1. Modifications in R1
The ESP_TRANSFORM contains the ESP modes supported by the sender, in the order of preference. All implementations MUST support AES-128-CBC [RFC3602] with HMAC-SHA-256 [RFC4868].
The following figure shows the resulting R1 packet layout 👀
The HIP parameters for the R1 packet:
IP ( HIP ( [ R1_COUNTER, ]
PUZZLE,
DIFFIE_HELLMAN,
HIP_CIPHER,
ESP_TRANSFORM,
HOST_ID,
[ ECHO_REQUEST, ]
HIP_SIGNATURE_2 )
[, ECHO_REQUEST ])5.2.1.2. Modifications in I2
The ESP_INFO contains the sender's SPI for this association as well as the KEYMAT index from where the ESP SA keys will be drawn. The old SPI value is set to zero.
The ESP_TRANSFORM contains the ESP mode selected by the sender of R1. All implementations MUST support AES-128-CBC [RFC3602] with HMAC-SHA-256 [RFC4868].
The following figure shows the resulting I2 packet layout 🦋
The HIP parameters for the I2 packet:
IP ( HIP ( ESP_INFO,
[R1_COUNTER,]
SOLUTION,
DIFFIE_HELLMAN,
HIP_CIPHER,
ESP_TRANSFORM,
ENCRYPTED { HOST_ID },
[ ECHO_RESPONSE ,]
HMAC,
HIP_SIGNATURE
[, ECHO_RESPONSE] ) )5.2.1.3. Modifications in R2
The R2 contains an ESP_INFO parameter, which has the SPI value of the sender of the R2 for this association. The ESP_INFO also has the KEYMAT index value specifying where the ESP SA keys are drawn.
The following figure shows the resulting R2 packet layout ✨
The HIP parameters for the R2 packet:
IP ( HIP ( ESP_INFO, HMAC_2, HIP_SIGNATURE ) )5.3. HIP ESP Rekeying 🔄
In this section, the procedure for rekeying an existing ESP SA is presented.
Conceptually, the process can be represented by the following message sequence using the host names I' and R' defined in Section 3.3.2. For simplicity, HMAC and HIP_SIGNATURE are not depicted, and DIFFIE_HELLMAN keys are optional. The UPDATE with ACK_I need not be piggybacked with the UPDATE with SEQ_R; it may be ACKed separately (in which case the sequence would include four packets).
I' R'
UPDATE(ESP_INFO, SEQ_I, [DIFFIE_HELLMAN])
----------------------------------->
UPDATE(ESP_INFO, SEQ_R, ACK_I, [DIFFIE_HELLMAN])
<-----------------------------------
UPDATE(ACK_R)
----------------------------------->Below, the first two packets in this figure are explained.
5.3.1. Initializing Rekeying 🌈
When HIP is used with ESP, the UPDATE packet is used to initiate rekeying. The UPDATE packet MUST carry an ESP_INFO and MAY carry a DIFFIE_HELLMAN parameter.
Intermediate systems that use the SPI will have to inspect HIP packets for those that carry rekeying information. The packet is signed for the benefit of the intermediate systems. Since intermediate systems may need the new SPI values, the contents cannot be encrypted.
The following figure shows the contents of a rekeying initialization UPDATE packet 🎀
The HIP parameters for the UPDATE packet initiating rekeying:
IP ( HIP ( ESP_INFO,
SEQ,
[DIFFIE_HELLMAN, ]
HMAC,
HIP_SIGNATURE ) )5.3.2. Responding to the Rekeying Initialization 💜
The UPDATE ACK is used to acknowledge the received UPDATE rekeying initialization. The acknowledgment UPDATE packet MUST carry an ESP_INFO and MAY carry a DIFFIE_HELLMAN parameter.
Intermediate systems that use the SPI will have to inspect HIP packets for packets carrying rekeying information. The packet is signed for the benefit of the intermediate systems. Since intermediate systems may need the new SPI values, the contents cannot be encrypted.
The following figure shows the contents of a rekeying acknowledgment UPDATE packet 🫶
The HIP parameters for the UPDATE packet:
IP ( HIP ( ESP_INFO,
SEQ,
ACK,
[ DIFFIE_HELLMAN, ]
HMAC,
HIP_SIGNATURE ) )5.4. ICMP Messages 🧁
ICMP message handling is mainly described in the HIP base specification [RFC7401]. In this section, we describe the actions related to ESP security associations.
5.4.1. Unknown SPI 🙈
If a HIP implementation receives an ESP packet that has an unrecognized SPI number, it MAY respond (subject to rate limiting the responses) with an ICMP packet with type "Parameter Problem", with the pointer pointing to the beginning of the SPI field in the ESP header.
6. Packet Processing 📦
Packet processing is mainly defined in the HIP base specification [RFC7401]. This section describes the changes and new requirements for packet handling when the ESP transport format is used. Note that all HIP packets (currently protocol 139) MUST bypass ESP processing.
6.1. Processing Outgoing Application Data 🚀
Outgoing application data handling is specified in the HIP base specification [RFC7401]. When the ESP transport format is used, and there is an active HIP session for the given < source, destination > HIT pair, the outgoing datagram is protected using the ESP security association. The following additional steps define the conceptual processing rules for outgoing ESP protected datagrams.
- Detect the proper ESP SA using the HITs in the packet header or other information associated with the packet.
- Process the packet normally, as if the SA was a transport mode SA.
- Ensure that the outgoing ESP protected packet has proper IP header format, depending on the used IP address family, and proper IP addresses in its IP header, e.g., by replacing HITs left by the ESP processing. Note that this placement of proper IP addresses MAY also be performed at some other point in the stack, e.g., before ESP processing.
6.2. Processing Incoming Application Data 🎀
okay so incoming HIP user data packets show up wrapped in ESP protection, right? 🎁 Usually the receiving host already has a matching ESP security association, found by the SPI and the destination IP address in the packet. ✨ But if the host crashed or otherwise lost its HIP state, it might not have that SA anymore. 😭
The basic incoming data handling is spelled out in the HIP base specification. ESP adds a few extra steps when it's protecting the data traffic. These steps are the conceptual processing rules for incoming ESP protected datagrams aimed at an ESP security association that was created with HIP. 💅
- Detect the proper ESP SA using the SPI. If the resulting SA is a non-HIP ESP SA, process the packet according to standard IPsec rules. If there are no SAs identified with the SPI, the host MAY send an ICMP packet as defined in Section 5.4. How to handle lost state is an implementation issue. 🙈
- If the SPI matches an active HIP-based ESP SA, the IP addresses in the datagram get replaced with the HITs associated with the SPI. ✨ This IP-address-to-HIT conversion step MAY also be performed at some other point in the stack, e.g., after ESP processing. Also, if the incoming packet has IPv4 addresses, the packet must be converted to IPv6 format before the addresses are replaced with HITs. That way the transport checksum will pass if there are no errors. 🦋
- The transformed packet then gets processed normally by ESP, as if it were a transport mode packet. ESP may drop the packet, as usual. In a typical implementation, a successful ESP decryption and verification gives you a datagram with the associated HITs as source and destination. 🧚
- The datagram gets delivered to the upper layer. Demultiplexing it to the right upper-layer socket works as usual, except the HITs are used in place of IP addresses during demultiplexing. 👑
6.3. HMAC and SIGNATURE Calculation and Verification 🔐
the new HIP parameters in this document, ESP_INFO and ESP_TRANSFORM, must be protected using HMAC and signature calculations. 💜 In a typical implementation, they get included in the R1, I2, R2, and UPDATE packet HMAC and SIGNATURE calculations, as described in [RFC7401]. ngl this one is pretty straightforward 🫶
6.4. Processing Incoming ESP SA Initialization (R1) 🌸
The ESP SA setup kicks off in the R1 message. The receiving host (Initiator) picks one of the ESP transforms from the values that were presented. If no suitable value shows up, the negotiation is terminated. ❌ The selected values are then used when generating and using encryption keys, and when sending the reply packet. 🔥 If the proposed alternatives aren't acceptable to the system, it may abandon the ESP SA establishment negotiation, or it may resend the I1 message within the retry bounds. 🍓
After the ESP transform is selected and the rest of the R1 processing is done, the system prepares and creates an incoming ESP security association. ✨ It may also prepare a security association for outgoing traffic. But since it doesn't have the correct SPI value yet, it can't activate it. 🙃
6.5. Processing Incoming Initialization Reply (I2) 💖
These steps are required to process the incoming ESP SA initialization replies in I2. The steps assume that the I2 has already been accepted for processing (for example, it wasn't dropped because of HIT comparisons, as described in [RFC7401]). 🦋
- The
ESP_TRANSFORMparameter gets verified. It MUST contain a single value in the parameter, and it MUST match one of the values offered in the initialization packet. 💅 - The
ESP_INFONEW SPI field gets parsed to find the SPI that will be used for the Security Association outbound from the Responder and inbound to the Initiator. For this initial ESP SA establishment, the old SPI value MUST be zero. TheKEYMAT Indexfield MUST contain the index value to the KEYMAT where the ESP SA keys are drawn from. 🔑 - The system prepares and creates both incoming and outgoing ESP security associations. 🎀
- Once the initialization reply message is processed successfully, any old Security Associations left over from an earlier incarnation of the HIP association get dropped and the new ones get installed. Then a finalizing packet, R2, is sent. ✨ Any ongoing rekeying attempts get dropped too. 🧹
6.6. Processing Incoming ESP SA Setup Finalization (R2) 🎉
Before the ESP SA can be finalized, the ESP_INFO NEW SPI field gets parsed to find the SPI that will be used for the ESP Security Association inbound to the sender of the finalization message R2. 🧚 The system uses this SPI to create or activate the outgoing ESP security association that it uses for sending packets to the peer. 🚀
6.7. Dropping HIP Associations 💀
When the system drops a HIP association, as described in the HIP base specification, the associated ESP SAs MUST also be dropped. No leftovers, bestie. 🧹✨
6.8. Initiating ESP SA Rekeying 🔄
During ESP SA rekeying, the hosts either draw new keys from the existing keying material, or new keying material gets generated and the new keys are drawn from that. 🌈
A system may start the SA rekeying procedure at any time. It MUST initiate a rekey if its incoming ESP sequence counter is about to overflow. ⚠️ The system MUST NOT replace its keying material until the rekeying packet exchange has successfully completed. 🫶
Optionally, a system may include a new Diffie-Hellman key for use in new KEYMAT generation. New KEYMAT generation happens before the new keys get drawn. 💜
The rekeying procedure uses the UPDATE mechanism defined in [RFC7401]. Because each peer has to update its half of the security association pair (including creating a new SPI), the rekeying process requires that each side both sends and receives an UPDATE. 🤝 A system then rekeys the ESP SA once it has sent its parameters to the peer and has received both an ACK for the relevant UPDATE message and the corresponding peer's parameters. 🎯 The ACK and the required HIP parameters might arrive in different UPDATE messages. This is always true if a system doesn't start an ESP SA update itself but responds to an update request from the peer. It can also happen if two systems start updates at nearly the same time. 👯 In that case, if the system has an outstanding update request, it saves the one parameter and waits for the other before completing the rekeying. 🙌
These steps define the processing rules for starting an ESP SA update:
- The system decides whether to keep using the existing KEYMAT or to generate a new KEYMAT. If it's generating a new KEYMAT, the system MUST generate a new Diffie-Hellman public key. 🔑
- The system creates an UPDATE packet that contains the
ESP_INFOparameter. The host may also include the optionalDIFFIE_HELLMANparameter. If the UPDATE contains theDIFFIE_HELLMANparameter, theKEYMAT Indexin theESP_INFOparameter MUST be zero, and the Diffie-Hellman Group ID must be unchanged from the one used in the initial handshake. If the UPDATE does not containDIFFIE_HELLMAN, theESP_INFOKEYMAT Index MUST be greater than or equal to the index of the next byte to be drawn from the current KEYMAT. 🧮 - The system sends the UPDATE packet. For reliability, the underlying UPDATE retransmission mechanism MUST be used. 📬
- The system MUST NOT delete its existing SAs. It keeps using them if its policy still allows it. The rekeying procedure SHOULD be started early enough to make sure the SA replay counters don't overflow. ⏰
- If a protocol error happens and the peer system acknowledges the UPDATE but doesn't send an
ESP_INFOitself, the system may not finalize the outstanding ESP SA update request. 😬 To guard against this, a system MAY restart the ESP SA update procedure after waiting some time for the peer to respond. Or it MAY decide to abort the ESP SA after waiting for an implementation-dependent time. The system MUST NOT keep an outstanding ESP SA update request for an indefinite time. ⏳
To keep the state machine simple, a host MUST NOT generate new UPDATEs while it has an outstanding ESP SA update request, unless it's restarting the update process. 🧠✨
6.9. Processing Incoming UPDATE Packets 📦
When a system receives an UPDATE packet, it must be processed if the following conditions hold. These are in addition to the generic conditions for UPDATE processing in Section 6.12 of [RFC7401]. 👀
- A corresponding HIP association must exist. The underlying UPDATE mechanism usually makes sure of this.
- The state of the HIP association is ESTABLISHED or R2-SENT.
If the above conditions hold, these steps define the conceptual processing rules for handling the received UPDATE packet:
- If the received UPDATE contains a
DIFFIE_HELLMANparameter, the received KEYMAT Index MUST be zero, and the Group ID must match the Group ID in use on the association. If this test fails, the packet SHOULD be dropped and the system SHOULD log an error message. 🚫 - If there is no outstanding rekeying request, packet processing continues as specified in Section 6.9.1. 💁♀️
- If there is an outstanding rekeying request, the UPDATE MUST be acknowledged. The received
ESP_INFO(and possiblyDIFFIE_HELLMAN) parameters must be saved, and packet processing continues as specified in Section 6.10. 📝
6.9.1. Processing UPDATE Packet: No Outstanding Rekeying Request 🌷
These steps define the conceptual processing rules for handling a received UPDATE packet that carries the ESP_INFO parameter:
- The system checks its policy to see whether it needs to generate a new Diffie-Hellman key. If it does, it generates a new key (with the same Group ID). The system records any newly generated or received Diffie-Hellman keys, to be used for KEYMAT generation when the ESP SA update is finalized. 🔐
- If the system generated a new Diffie-Hellman key in the previous step, or if it received a
DIFFIE_HELLMANparameter, it sets theESP_INFOKEYMAT Index to zero. Otherwise, theESP_INFOKEYMAT Index MUST be greater than or equal to the index of the next byte to be drawn from the current KEYMAT. In this case, it is RECOMMENDED that the host use the KEYMAT Index requested by the peer in the receivedESP_INFO. 🧡 - The system creates an UPDATE packet that contains an
ESP_INFOparameter and the optionalDIFFIE_HELLMANparameter. This UPDATE would also typically acknowledge the peer's UPDATE with an ACK parameter, although a separate UPDATE ACK may be sent. 💌 - The system sends the UPDATE packet and stores any received
ESP_INFOandDIFFIE_HELLMANparameters. At this point, it only needs to receive an acknowledgment for the newly sent UPDATE to finish the ESP SA update. In the usual case, the underlying UPDATE mechanism handles that acknowledgment. 🥳
6.10. Finalizing Rekeying 🦋
okay so a system finalizes rekeying once it has BOTH the UPDATE ack from its peer AND the peer's UPDATE successfully received. only then does it wrap things up 💅 Here's the checklist:
- ✨ If the received UPDATE messages carry a new Diffie-Hellman key, OR the system got a new Diffie-Hellman key because it started an ESP SA update, OR both, then the system generates a new KEYMAT. If there's only one new Diffie-Hellman key, the old existing key gets used as the other key. 🔥
- 💜 If the system made a new KEYMAT in step 1, it sets the KEYMAT Index to zero, no matter whether the received UPDATE had a Diffie-Hellman key or not. If it did NOT make a new KEYMAT, it uses the greater KEYMAT Index out of the two
ESP_INFOparameters (the one it sent and the one it got). 🌸 - 🧚 The system draws keys for the new incoming and outgoing ESP SAs, starting from the KEYMAT Index, and sets up both new SAs. The SPI for the outgoing SA is the new SPI value from the received
ESP_INFOparameter. The SPI for the incoming SA was generated when theESP_INFOgot sent to the peer. The order of the keys pulled from KEYMAT during rekeying is similar to what's in Section 7. Also, only IPsec ESP keys get pulled during rekeying, NOT the HIP keys. not me being picky, it's just the rule 🙈 - 🎀 The system starts sending on the new outgoing SA and gets ready to receive data on the new incoming SA. Once it actually receives data on the new incoming SA, it may safely delete the old SAs. bye bye, old SAs 👋🦋
6.11. Processing NOTIFY Packets 💌
the whole NOTIFY packet processing story lives in the HIP base specification, so go read it there bestie 📖✨
7. Keying Material 🔑
the keying material gets generated the way the HIP base specification says. during the base exchange, the initial keys are drawn from that material. once the HIP association keys are drawn, the ESP keys get drawn in this order:
- SA-gl ESP encryption key for HOST_g's outgoing traffic 🌈
- SA-gl ESP authentication key for HOST_g's outgoing traffic 🌈
- SA-lg ESP encryption key for HOST_l's outgoing traffic 💜
- SA-lg ESP authentication key for HOST_l's outgoing traffic 💜
HOST_g is the host with the greater HIT value, and HOST_l is the host with the lower HIT value. when HIT values get compared, they're read as positive (unsigned) 128-bit integers in network byte order. big brain stuff 🧠💅
The four HIP keys only get drawn from KEYMAT during a HIP I1->R2 exchange. later rekeys using UPDATE only draw the four ESP keys from KEYMAT. Section 6.9 explains the rules for reusing or regenerating KEYMAT based on the rekeying. 🔁
The number of bits drawn for a given algorithm is the "natural" size of the keys, as specified in Section 6.5 of [RFC7401]. ✨
8. Security Considerations 🛡️😭
okay this section is SERIOUS, so read it with your whole chest 💀
In this document, the usage of ESP [RFC4303] between HIP hosts to protect data traffic is introduced. The security considerations for ESP are discussed in the ESP specification. ESP's own security stuff is covered there, so check it out 🔒
There are different ways to establish an ESP Security Association between two nodes. This can be done, e.g., using IKE [RFC7296]. This document specifies how the Host Identity Protocol is used to establish ESP Security Associations. 🌸
The following issues are new or have changed from the standard ESP usage:
- Initial keying material generation
- Updating the keying material
The initial keying material is generated using the Host Identity Protocol [RFC7401] using the Diffie-Hellman procedure. This document extends the usage of the UPDATE packet, defined in the base specification, to modify existing ESP SAs. The hosts may rekey, i.e., force the generation of new keying material using the Diffie-Hellman procedure. The initial setup of ESP SAs between the hosts is done during the base exchange, and the message exchange is protected using methods provided by the base exchange. Changes in connection parameters basically mean that the old ESP SA is removed and a new one is generated once the UPDATE message exchange has been completed. The message exchange is protected using the HIP association keys. Both HMAC and signing of packets are used. 🔐🎀
9. IANA Considerations 📋💖
the following changes to the "Host Identity Protocol (HIP) Parameters" registries have been made. in every case, the changes updated the reference from [RFC5202] to this specification. 🧾
this document defines two Parameter Types and two NOTIFY Message Types for the Host Identity Protocol [RFC7401].
the parameters and their type numbers are defined in Sections 5.1.1 and 5.1.2, and they've been added to the "Parameter Types" namespace created by [RFC7401]. no new action about these values is needed from this specification, other than updating the reference from [RFC5202] to this specification. ✅
the new NOTIFICATION error types and their values are defined in Section 5.1.3, and they've been added to the "Notify Message Types" namespace created by [RFC7401]. no new action about these values is needed from this specification, other than updating the reference from [RFC5202] to this specification. ✅
Section 5.1.2 of this document defines values for "ESP Transform Suite IDs", which are registered in a new IANA registry, with an "IETF Review" registration procedure [RFC5226] for new values. 🌟
10. References 📚
10.1. Normative References 💜
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, November 1998,
<http://www.rfc-editor.org/info/rfc2404>.
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
Its Use With IPsec", RFC 2410, November 1998,
<http://www.rfc-editor.org/info/rfc2410>.
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
Algorithm and Its Use with IPsec", RFC 3602,
September 2003, <http://www.rfc-editor.org/info/rfc3602>.
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
(GCM) in IPsec Encapsulating Security Payload (ESP)",
RFC 4106, June 2005, <http://www.rfc-editor.org/
info/rfc4106>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005, <http://www.rfc-editor.org/
info/rfc4303>.
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM
Mode with IPsec Encapsulating Security Payload (ESP)",
RFC 4309, December 2005, <http://www.rfc-editor.org/
info/rfc4309>.
[RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The
AES-CMAC Algorithm", RFC 4493, June 2006,
<http://www.rfc-editor.org/info/rfc4493>.
[RFC4494] Song, JH., Poovendran, R., and J. Lee, "The AES-CMAC-96
Algorithm and Its Use with IPsec", RFC 4494, June 2006,
<http://www.rfc-editor.org/info/rfc4494>.
[RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message
Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543,
May 2006, <http://www.rfc-editor.org/info/rfc4543>.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256,
HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868,
May 2007, <http://www.rfc-editor.org/info/rfc4868>.
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
Henderson, "Host Identity Protocol Version 2 (HIPv2)",
RFC 7401, April 2015, <http://www.rfc-editor.org/
info/rfc7401>.10.2. Informative References 🦋
[HIP-ARCH] Moskowitz, R., Ed., and M. Komu, "Host Identity Protocol
Architecture", Work in Progress,
draft-ietf-hip-rfc4423-bis-09, October 2014.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981, <http://www.rfc-editor.org/info/rfc791>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005,
<http://www.rfc-editor.org/info/rfc4301>.
[RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the
Encapsulating Security Payload (ESP) Transport Format with
the Host Identity Protocol (HIP)", RFC 5202, April 2008,
<http://www.rfc-editor.org/info/rfc5202>.
[RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko,
"End-Host Mobility and Multihoming with the Host Identity
Protocol", RFC 5206, April 2008,
<http://www.rfc-editor.org/info/rfc5206>.
[RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and
Firewall Traversal Issues of Host Identity Protocol (HIP)
Communication", RFC 5207, April 2008,
<http://www.rfc-editor.org/info/rfc5207>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A.
Keranen, "Basic Host Identity Protocol (HIP) Extensions
for Traversal of Network Address Translators", RFC 5770,
April 2010, <http://www.rfc-editor.org/info/rfc5770>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, October 2014,
<http://www.rfc-editor.org/info/rfc7296>.Appendix A. A Note on Implementation Options 🧩
it's possible to implement this specification in multiple different ways. as noted above, one possible way is to rewrite IP headers below IPsec. in that setup, IPsec gets used as if it were processing IPv6 transport mode packets, with the IPv6 header holding HITs instead of IP addresses in the source and destination address fields. on outgoing packets, after IPsec processing, the HITs get swapped for actual IP addresses, based on the HITs and the SPI. on incoming packets, before IPsec processing, the IP addresses get swapped for HITs, based on the SPI in the incoming packet. in that kind of implementation, all IPsec policies are based on HITs, and the upper layers only ever see packets with HITs where the IP addresses would be. so, supporting HIP doesn't conflict with other uses of IPsec as long as the SPI spaces stay separate. 🌈 Appendix B describes another way to implement this specification. 💅
Appendix B. Bound End-to-End Tunnel Mode for ESP 🦋
okay bestie, this section is about an alternative way to do the HIP ESP transport stuff 💅 Compared to doing the address rewrites outside of IPsec, BEET has one implementation-level win: the address-rewriting info lives in one place, the SAD ✨ When rewriting is handled separately, the implementation MUST make sure the info in the SAD and the info in the separate address-rewriting database stay in synchrony 😭 So the BEET-mode way of doing this spec is RECOMMENDED over the separate approach, because it binds the identities, encryption, and locators super tightly together 🔗 Also, implementing BEET mode doesn't mean your corresponding hosts have to implement it too, since the behavior is only visible inside your own host 🙈
BEET mode is a mashup of IPsec tunnel and transport modes, and it gets some vibes from both 🌈 HIP uses HITs as the "inner" addresses and IP addresses as the "outer" addresses, the same way IP addresses work in tunnel mode. Instead of tunneling packets between hosts, the end hosts convert between inner and outer addresses, and the inner address never goes on the wire after the initial HIP negotiation 🧚 So BEET gives you IPsec transport mode syntax (no inner headers) with limited tunnel mode semantics: fixed logical inner addresses (the HITs) and changeable outer IP addresses 💜
B.1. Protocol Definition
In this section, we define the exact protocol formats and operations 📝
B.1.1. Changes to Security Association Data Structures
A BEET mode Security Association has the same data as a regular tunnel mode Security Association, except the inner selectors must be single addresses and cannot be subnets 🎀 The data includes:
- A pair of inner IP addresses.
- A pair of outer IP addresses.
- Cryptographic keys and other data as defined in Section 4.4.2 of RFC 4301 [RFC4301].
A conforming implementation MAY store the data in a way similar to a regular tunnel mode Security Association 🌸
Note that in a conforming implementation the inner and outer addresses MAY belong to different address families 👀 All implementations that support both IPv4 and IPv6 SHOULD support both IPv4-over-IPv6 and IPv6-over-IPv4 tunneling 🫶
B.1.2. Packet Format
The wire packet format is identical to the ESP transport mode wire format as defined in Section 3.1.1 of [RFC4303] 📦 However, the resulting packet contains outer IP addresses instead of the inner IP addresses received from the upper layer. The construction of the outer headers is defined in Section 5.1.2 of RFC 4301 [RFC4301]. Here's how ESP BEET mode positioning looks for typical IPv4 and IPv6 packets 👇
IPv4 INNER ADDRESSES
--------------------
BEFORE APPLYING ESP
------------------------------
| inner IP hdr | | |
| | TCP | Data |
------------------------------
AFTER APPLYING ESP, OUTER v4 ADDRESSES
----------------------------------------------------
| outer IP hdr | | | | ESP | ESP |
| (any options) | ESP | TCP | Data | Trailer | ICV |
----------------------------------------------------
|<---- encryption ---->|
|<-------- integrity ------->|
AFTER APPLYING ESP, OUTER v6 ADDRESSES
------------------------------------------------------
| outer | new ext | | | | ESP | ESP |
| IP hdr | hdrs | ESP | TCP | Data | Trailer| ICV |
------------------------------------------------------
|<--- encryption ---->|
|<------- integrity ------->|
IPv4 INNER ADDRESSES with options
---------------------------------
BEFORE APPLYING ESP
------------------------------
| inner IP hdr | | |
| + options | TCP | Data |
------------------------------
AFTER APPLYING ESP, OUTER v4 ADDRESSES
----------------------------------------------------------
| outer IP hdr | | | | | ESP | ESP |
| (any options) | ESP | PH | TCP | Data | Trailer | ICV |
----------------------------------------------------------
|<------- encryption ------->|
|<----------- integrity ---------->|
AFTER APPLYING ESP, OUTER v6 ADDRESSES
------------------------------------------------------------
| outer | new ext | | | | | ESP | ESP |
| IP hdr | hdrs | ESP | PH | TCP | Data | Trailer| ICV |
------------------------------------------------------------
|<------ encryption ------->|
|<---------- integrity ---------->|
PH Pseudo Header for IPv4 options
IPv6 INNER ADDRESSES
--------------------
BEFORE APPLYING ESP
------------------------------------------
| | ext hdrs | | |
| inner IP hdr | if present | TCP | Data |
------------------------------------------
AFTER APPLYING ESP, OUTER v6 ADDRESSES
--------------------------------------------------------------
| outer | new ext | | dest | | | ESP | ESP |
| IP hdr | hdrs | ESP | opts.| TCP | Data | Trailer | ICV |
--------------------------------------------------------------
|<---- encryption ---->|
|<------- integrity ------>|
AFTER APPLYING ESP, OUTER v4 ADDRESSES
----------------------------------------------------
| outer | | dest | | | ESP | ESP |
| IP hdr | ESP | opts.| TCP | Data | Trailer | ICV |
----------------------------------------------------
|<------- encryption -------->|
|<----------- integrity ----------->|B.1.3. Cryptographic Processing
The outgoing packets MUST be protected exactly as in ESP transport mode [RFC4303] 🔐 That means the upper-layer protocol packet gets wrapped into an ESP header, encrypted, and authenticated exactly as if regular transport mode was in use. The resulting ESP packet then goes through IP header processing as defined in Appendices B.1.4 and B.1.5. On the way in, incoming ESP protected messages are verified and decrypted exactly as if regular transport mode was used, and the resulting cleartext packet goes through IP header processing as defined in Appendices B.1.4 and B.1.6 ✨
B.1.4. IP Header Processing
The biggest difference between BEET mode and the other two modes is in IP header processing 🎀 In regular transport mode, the IP header is kept intact. In regular tunnel mode, an outer IP header is created on output and discarded on input. In BEET mode, the IP header gets replaced with another one on both input and output 🔄
On the BEET mode output side, the IP header processing MUST first ensure that the IP addresses in the original IP header contain the inner addresses as specified in the SA. This MAY be ensured by proper policy processing, and it's possible that no checks are needed at the time of SA processing 🧐 Once the IP header has been verified to contain the right inner IP addresses, it gets discarded. A new IP header is created, using the fields of the discarded inner header (except the IP addresses) to fill in the fields of the new outer header. The IP addresses in the new header MUST be the outer tunnel addresses 🌷
On the input side, the received IP header is simply discarded. Since the packet has been decrypted and verified, no further checks are necessary 💁 A new IP header corresponding to a BEET mode inner header is created, using the fields of the discarded outer header (except the IP addresses) to fill in the fields of the new inner header. The IP addresses in the new header MUST be the inner addresses 💖
Here's the tea ☕ Because the outer header fields are used as a hint for creating the inner header, the inner header is different from a tunnel mode inner header. In BEET mode, the inner header gets the Time to Live (TTL), Don't Fragment (DF) bit, and other option values from the outer header. The TTL, DF bit, and other option values of the inner header MUST be processed by the stack 🥞
B.1.5. Handling of Outgoing Packets
The outgoing BEET mode packets are processed as follows 📮
- The system MUST verify that the IP header contains the inner source and destination addresses, exactly as defined in the SA. This verification MAY be explicit, or it MAY be implicit, for example, as a result of prior policy processing. Note that in some implementations there may be no real IP header at this time, but the source and destination addresses may be carried out of band. If the source address is still unassigned, it SHOULD be ensured that the designated inner source address would be selected at a later stage 🕵️♀️
- The IP payload (the contents of the packet beyond the IP header) is wrapped into an ESP header as defined in Section 3.3 of [RFC4303] 🎁
- A new IP header is constructed, replacing the original one. The new IP header MUST contain the outer source and destination addresses, as defined in the SA. Note that in some implementations there may be no real IP header at this time, but the source and destination addresses may be carried out of band.
In the case where the source address must be left unassigned, it SHOULD be ensured that the right source address is selected at a later stage. Other than the addresses, it is RECOMMENDED that the new IP header copies the fields from the original IP header 🌈
- If there are any IPv4 options in the original packet, it is RECOMMENDED that they are discarded. If the inner header contains one or more options that need to be transported between the tunnel endpoints, the sender MUST encapsulate the options as defined in Appendix B.1.7 🧚♀️
Instead of literally discarding the IP header and constructing a new one, a conforming implementation MAY simply replace the addresses in an existing header 🪄 However, if the RECOMMENDED feature of allowing the inner and outer addresses from different address families is used, this simple strategy does not work 🙅♀️💥
Appendix B. Bound End-to-End Tunnel Mode for ESP 🦋
B.1. Protocol Definition 💖
B.1.6. Handling of Incoming Packets ✨
okay bestie, let's talk about what the receiver does when a BEET packet lands 📬 It's giving very careful bouncer energy 💅
- The system MUST verify and decrypt the incoming packet successfully, as defined in Section 3.4 of [RFC4303]. If the verification or decryption fails, the packet MUST be discarded. 🔒 no verify, no entry, periodt
- The original IP header is simply discarded, without any checks. 🗑️ Since the ESP verification already passed, we can safely assume the packet came from the right sender. Main character energy for the header: it's out 👋
- A new IP header gets built to replace the original one 🧱 The new IP header MUST contain the inner source and destination addresses, as defined in the SA. If the sender set the ESP Next Header field to 94 and included the pseudo header from Appendix B.1.7, the receiver MUST include the options after the constructed IP header. 🎀 Also, some implementations have already tossed the real IP header and carry the source and destination addresses out of band. In that case, the out-of-band addresses MUST be the inner addresses 🫶 Other than the addresses, it is RECOMMENDED that the new IP header copies the fields from the original IP header ✨
Okay so, you don't HAVE to literally throw the old header away and build a brand new one 🙈 A conforming implementation MAY simply replace the addresses in an existing header. BUT, and this is a big but 😭, if you use the RECOMMENDED feature of allowing the inner and outer addresses to come from different address families, this simple strategy does not work. Not me trying to swap an IPv4 address for an IPv6 one in place 💀
B.1.7. Handling of IPv4 Options 🌸
ngl this section is so fun 🧚 In BEET mode, if IPv4 options are transported inside the tunnel, the sender MUST include a pseudo header after the ESP header. This pseudo header tells the receiver that the IPv4 options from the original packet should be applied to the packet on the input side 💜
The sender MUST set the Next Header field in the ESP header to 94. The resulting pseudo header, including the IPv4 options, MUST be padded to an 8-octet boundary 🍓 The padding length is expressed in octets, and the valid padding lengths are 0 or 4 octets, because the original IPv4 options are already padded to a 4-octet boundary. The padding MUST be filled with No Operation (NOP) options as defined in Section 3.1 ("Internet Header Format") of [RFC0791] ("Internet Protocol"). The padding goes in front of the original options so the receiver can reconstruct the original IPv4 datagram 🦋 The Header Length field holds the length of the IPv4 options plus padding, in 8-octet units.
Here's the pseudo header layout 👑
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Header Len | Pad Len | Reserved |
+---------------+---------------+-------------------------------+
| Padding (if needed) |
+---------------------------------------------------------------+
| IPv4 options ... |
| |
+---------------------------------------------------------------+And here's what each field means 🌈
Next Header identifies the data following this header.
Length in octets 8-bit unsigned integer. Length of the
pseudo header in 8-octet units, not
including the first 8 octets.The receiver MUST remove this pseudo header and the padding as part of BEET processing, so it can rebuild the original IPv4 datagram ✨ The IPv4 options carried in the pseudo header MUST be added after the reconstructed IPv4 (inner) header on the receiving side. Full glow-up arc, honestly 🥹
Acknowledgments 🫶
This document was split off from the base Host Identity Protocol specification at the beginning of 2005. Since then, a bunch of people have contributed to the text by giving comments and proposing changes 💖 The list includes Tom Henderson, Jeff Ahrenholz, Jan Melen, Jukka Ylitalo, and Miika Komu. The authors especially want to thank Pekka Nikander for his invaluable contributions since the first draft version 🌸 They also want to thank Charlie Kaufman for reviewing the document with his eye on the usage of crypto algorithms 🔐
Because this document has so much history, most of its ideas were inherited from the base Host Identity Protocol specification. So the acknowledgments list in that specification is also valid for this document. Many people have given valuable feedback, and apologies to anyone whose name is missing 🙏✨
Authors' Addresses 💅
Petri Jokela Ericsson Research NomadicLab JORVAS FIN-02420 Finland
Phone: +358 9 299 1 EMail: petri.jokela@nomadiclab.com
Robert Moskowitz HTT Consulting Oak Park, MI United States
EMail: rgm@labs.htt-consult.com
Jan Melen Ericsson Research NomadicLab JORVAS FIN-02420 Finland
Phone: +358 9 299 1 EMail: jan.melen@nomadiclab.com
📦 where this page comes from
- ietf: rfc7402 2015-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms