RFC 5202
Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)
RFC 5202: Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) ✨
Okay bestie, here's the tea 🫶 RFC 5202 came out of the Network Working Group in April 2008. The authors are P. Jokela (Ericsson Research NomadicLab), R. Moskowitz (ICSAlabs), and P. Nikander (Ericsson Research NomadicLab). It's in the Experimental category, and its header doesn't list anything it obsoletes or updates, so it stands on its own 💅
Status of This Memo 📜
This memo defines an Experimental Protocol for the Internet community, so it's not an Internet standard of any kind 🧚 The authors want feedback and ideas for making it better, and anyone can distribute it freely.
IESG Note 🚩
The IESG listed some concerns about this document. They're expecting these issues to get sorted out when future versions of HIP are designed.
Here's the big one. When you've got complicated Security Policy Databases (SPDs) and HIP is hanging out with security protocols like IKE, implementors might run into situations that none of these documents spell out. For example, say the SPD says an IP address subnet should be protected, and a HIP host lives inside that subnet. Then the traffic might get encrypted more than once 😭 Readers should be extra careful when running HIP with complex SPD settings. Future specs should clearly say when multiple encryption is intended and when it should be avoided.
Abstract 🌸
This memo describes a mechanism based on the Encapsulated Security Payload (ESP) for sending user data packets, meant to be used with the Host Identity Protocol (HIP).
Table of Contents 🗂️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Using ESP with HIP . . . . . . . . . . . . . . . . . . . . . . 4
3.1. ESP Packet Format . . . . . . . . . . . . . . . . . . . . 4
3.2. Conceptual ESP Packet Processing . . . . . . . . . . . . . 4
3.2.1. Semantics of the Security Parameter Index (SPI) . . . 5
3.3. Security Association Establishment and Maintenance . . . . 6
3.3.1. ESP Security Associations . . . . . . . . . . . . . . 6
3.3.2. Rekeying . . . . . . . . . . . . . . . . . . . . . . . 6
3.3.3. Security Association Management . . . . . . . . . . . 7
3.3.4. Security Parameter Index (SPI) . . . . . . . . . . . . 7
3.3.5. Supported Transforms . . . . . . . . . . . . . . . . . 7
3.3.6. Sequence Number . . . . . . . . . . . . . . . . . . . 8
3.3.7. Lifetimes and Timers . . . . . . . . . . . . . . . . . 8
3.4. IPsec and HIP ESP Implementation Considerations . . . . . 8
4. The Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. ESP in HIP . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1. Setting Up an ESP Security Association . . . . . . . . 9
4.1.2. Updating an Existing ESP SA . . . . . . . . . . . . . 10
5. Parameter and Packet Formats . . . . . . . . . . . . . . . . . 10
5.1. New Parameters . . . . . . . . . . . . . . . . . . . . . . 11
5.1.1. ESP_INFO . . . . . . . . . . . . . . . . . . . . . . . 11
5.1.2. ESP_TRANSFORM . . . . . . . . . . . . . . . . . . . . 13
5.1.3. NOTIFY Parameter . . . . . . . . . . . . . . . . . . . 14
5.2. HIP ESP Security Association Setup . . . . . . . . . . . . 14
5.2.1. Setup During Base Exchange . . . . . . . . . . . . . . 14
5.3. HIP ESP Rekeying . . . . . . . . . . . . . . . . . . . . . 16
5.3.1. Initializing Rekeying . . . . . . . . . . . . . . . . 16
5.3.2. Responding to the Rekeying Initialization . . . . . . 17
5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 17
5.4.1. Unknown SPI . . . . . . . . . . . . . . . . . . . . . 17
6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 18
6.1. Processing Outgoing Application Data . . . . . . . . . . . 18
6.2. Processing Incoming Application Data . . . . . . . . . . . 19
6.3. HMAC and SIGNATURE Calculation and Verification . . . . . 19
6.4. Processing Incoming ESP SA Initialization (R1) . . . . . . 19
6.5. Processing Incoming Initialization Reply (I2) . . . . . . 20
6.6. Processing Incoming ESP SA Setup Finalization (R2) . . . . 20
6.7. Dropping HIP Associations . . . . . . . . . . . . . . . . 20
6.8. Initiating ESP SA Rekeying . . . . . . . . . . . . . . . . 20
6.9. Processing Incoming UPDATE Packets . . . . . . . . . . . . 22
6.9.1. Processing UPDATE Packet: No Outstanding Rekeying
Request . . . . . . . . . . . . . . . . . . . . . . . 22
6.10. Finalizing Rekeying . . . . . . . . . . . . . . . . . . . 23
6.11. Processing NOTIFY Packets . . . . . . . . . . . . . . . . 24
7. Keying Material . . . . . . . . . . . . . . . . . . . . . . . 24
8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
11.1. Normative references . . . . . . . . . . . . . . . . . . . 26
11.2. Informative references . . . . . . . . . . . . . . . . . . 26
Appendix A. A Note on Implementation Options . . . . . . . . . . 281. Introduction 🦋
Okay so, the Host Identity Protocol Architecture [RFC4423] says hosts are identified with public keys. Then the HIP base exchange [RFC5201] lets any two HIP-supporting hosts authenticate each other and set up a HIP association between themselves 🔥 During that base exchange, the hosts make a shared piece of keying material using an authenticated Diffie-Hellman exchange.
Now here's the plot twist 👀 The HIP base exchange spec [RFC5201] doesn't describe any transport format or method for user data once the actual communication starts. It only says that implementing the Encapsulated Security Payload (ESP) [RFC4303] based transport format and method is mandatory. This document is the one that explains how ESP carries the actual user data with HIP 🎀
To be more specific, this document defines a set of HIP protocol extensions and how they get handled. With these extensions, a pair of ESP Security Associations (SAs) gets created between the hosts during the base exchange. The resulting ESP SAs use keys pulled from the keying material (KEYMAT) made during the base exchange. Once the HIP association and the required ESP SAs are set up, the user data gets protected with ESP. The document also covers ways to update an existing ESP Security Association 💖
Quick note: user data packets don't carry Host Identity representations explicitly in their headers. Instead, the ESP Security Parameter Index (SPI) tells the receiver which host context to use. The SPIs get picked during the HIP ESP setup exchange. For user data packets, the ESP SPIs (sometimes paired with IP addresses) identify the host context indirectly, so no extra explicit protocol headers are needed ✨
2. Conventions Used in This Document 📚
Here's the key-words rule 💅 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read exactly as RFC 2119 [RFC2119] describes them.
3. Using ESP with HIP 🧚
The HIP base exchange sets up a HIP association between two hosts. It gives you two-way host authentication and key material, but it doesn't protect the data traffic between the hosts at all 🙈 This document says to use ESP to protect user data traffic after the HIP base exchange. Just so you know, this ESP use is only for host-to-host traffic. Security gateways are not supported.
The base exchange messages need a few small additions to the parameters they carry. In the R1 packet, the Responder puts the possible ESP transforms into a new ESP_TRANSFORM parameter before sending it to the Initiator. The Initiator looks at the proposed transforms, picks one, and puts it in an ESP_TRANSFORM parameter in the I2 packet. In that same I2 packet, the Initiator also sends the SPI value it wants used for ESP traffic going from the Responder to the Initiator. That info rides in the new ESP_INFO parameter. When the ESP SA setup gets finalized, the Responder sends its SPI value to the Initiator in the R2 packet, again using ESP_INFO 🌈
3.1. ESP Packet Format 🍓
The ESP spec [RFC4303] defines the ESP packet format for IPsec. The HIP ESP packet looks exactly the same as an IPsec ESP transport format packet. The semantics are a bit different, though, and the next subsection goes into more detail 🤓
3.2. Conceptual ESP Packet Processing 💜
ESP packet processing can be implemented in different ways in HIP. One option is to implement it so that a standards compliant, unmodified IPsec implementation [RFC4303] can be used.
Here's how that could go when a standards compliant IPsec implementation uses IP addresses in the SPD and Security Association Database (SAD). For outgoing packets, assume the upper-layer pseudoheader was built using IP addresses. The implementation recalculates the upper-layer checksums using Host Identity Tags (HITs), then swaps the packet source and destination addresses back to the matching IP addresses. The packet goes to IPsec ESP for transport mode handling, and from there the encrypted packet goes 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 are replaced with HITs, and then the upper-layer checksums are verified before the packet is passed up to the upper layer 💅
There's also the BEET (Bound End-to-End Tunnel) [ESP-BEET] mode, which is another way to do packet processing. In BEET mode the ESP packet is formatted as a transport mode packet, but the connection semantics match 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 together with the integrity protection lets the packet be securely tied to the right HIT pair. Then the packet header is replaced with a new header containing the HITs, and the packet is decrypted 🦋
3.2.1. Semantics of the Security Parameter Index (SPI) ✨
Okay bestie, SPIs are how ESP figures out which Security Association a received packet belongs to 🔍. With HIP they're extra special 💖 because they're a compressed version of a pair of HITs. So SPIs MAY be used by intermediary systems for stuff like address mapping 🦋. Since the SPI only has meaning at the receiver, it's the < DST, SPI > pair (where DST is a destination IP address) that uniquely identifies the receiver HIT at any given moment ⭐. The same SPI value can be used by several hosts 🍓, and one < DST, SPI > can point at different hosts and contexts at different times, depending on which host is reachable at that DST. Chaotic, but it makes sense once you see it 💅.
Each host picks its own SPI for the packets it wants to receive from its peer, so it can pick different SPIs for different peers 🎀. The SPI selection SHOULD be random, and the rules of 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, to avoid a replay attack 🙈. Also, when a host rekeys, the SPI MUST be changed 🔄. Furthermore, if a host switches to a different IP address, it MAY change the SPI 🌈.
One method for SPI creation that meets the above criteria is to concatenate the HIT with a 32-bit random or sequential number, hash this (using SHA1), and then use the high-order 32 bits as the SPI ✨.
The selected SPI gets communicated to the peer in the third (I2) and fourth (R2) packets of the base HIP exchange. Changes in SPI are signaled with ESP_INFO parameters 🧚.
3.3. Security Association Establishment and Maintenance 👑
3.3.1. ESP Security Associations 🔐
In HIP, ESP Security Associations get set up between the HIP nodes during the base exchange [RFC5201]. Existing ESP SAs can be updated later using UPDATE messages 💫. A reason to update later could be, for example, needing to rekey the SA because of sequence number rollover 🔁.
Once a HIP association is set up, each association is linked to two ESP SAs: one for incoming packets and one for outgoing packets. The Initiator's incoming SA corresponds 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. Respectively, the Responder's incoming SA corresponds with the Initiator's outgoing SA and is called SA-IR, with its SPI being 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 processing 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 [RFC5201].
When the HIP association is removed, the related ESP SAs MUST also be removed 🗑️.
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 I' and the peer is R'.
An existing HIP-created ESP SA may need updating during the lifetime of the HIP association. This document specifies rekeying an existing HIP-created ESP SA using the UPDATE message, and the ESP_INFO parameter introduced above is used for this purpose 🎯.
I' starts the ESP SA updating process when 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, local policy permitting 🕰️.
R', after receiving and processing the UPDATE (see Section 6.9), generates new SAs: SA-I'R' and SA-R'I'. It doesn't take the new outgoing SA into use, but still uses the old one, so there are temporarily two SA pairs toward the same peer host 👯. The SPI for the new outgoing SA, SPI-R'I', is specified in the ESP_INFO parameter received in the UPDATE packet. For the new incoming SA, R' generates the new SPI value, SPI-I'R', and includes it in the response UPDATE packet.
When I' receives a response UPDATE from R', it generates new SAs, as described in Section 6.9: SA-I'R' and SA-R'I'. It starts using the new outgoing SA immediately 🚀.
R' starts using the new outgoing SA when it receives traffic on the new incoming SA or when it receives the UPDATE ACK confirming completion of rekeying. After this, R' can remove the old SAs. Similarly, when I' receives traffic from the new incoming SA, it can safely remove the old SAs 🧹.
3.3.3. Security Association Management 🗂️
An SA pair is indexed by the 2 SPIs and 2 HITs (both local and remote HITs, since a system can have more than one HIT). An inactivity timer is RECOMMENDED for all SAs. If the state dictates the deletion of an SA, a timer is set to allow for any late arriving packets ⏰.
3.3.4. Security Parameter Index (SPI) 🍭
The SPIs in ESP provide 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 a decrease of policy granularity compared to other Key Management Protocols like IKE 🙃.
When a host updates the ESP SA, it provides a new inbound SPI to its partner and gets a new outbound SPI from its partner 🔁.
3.3.5. Supported Transforms 🛠️
All HIP implementations MUST support AES-CBC [RFC3602] and HMAC-SHA-1-96 [RFC2404]. If the Initiator does not support any of the transforms offered by the Responder, it should abandon the negotiation and inform the peer with a NOTIFY message about a non-supported transform 🙅.
In addition to AES-CBC, all implementations MUST implement the ESP NULL encryption algorithm. When the ESP NULL encryption is used, it MUST be used together with SHA1 or MD5 authentication, as specified in Section 5.1.2.
3.3.6. Sequence Number 🔢
The Sequence Number field is MANDATORY when ESP is used with HIP. Anti-replay protection MUST be used in an ESP SA established with HIP. When ESP is used with HIP, a 64-bit sequence number MUST be used. This means that each host MUST rekey before its sequence number reaches 2^64 💀.
When using a 64-bit sequence number, the higher 32 bits are NOT included in the ESP header, but are simply kept local to both peers. See [RFC4301] 🫣.
3.3.7. Lifetimes and Timers ⏳
HIP does not 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 using that SA. The default timeout value is 15 minutes. Implementations MAY support lifetimes for the various ESP transforms. Each implementation SHOULD implement per-HIT configuration of the inactivity timeout, allowing statically configured HIP associations to stay alive for days, even when inactive 🌸.
3.4. IPsec and HIP ESP Implementation Considerations 🧩
When HIP is run on a node where a standards compliant IPsec is used, some issues have 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, it may lead to a collision if not implemented properly. To avoid the possibility of a collision, the HIP implementation MUST ensure that the SPI values used for HIP SAs are not used for IPsec or other SAs, and vice versa 🚧.
For outbound traffic, the SPD or (coordinated) SPDs, if there are two (one for HIP and one for IPsec), MUST ensure that packets intended for HIP processing are given a HIP-enabled SA, and that packets intended for IPsec processing are given 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 originating from a socket that is not using HIP MUST NOT have checksum recalculated (as described in Section 3.2, paragraph 2), and data MUST NOT be passed to the SP or SA created by the HIP 🚫.
Incoming data packets using an SA that is not negotiated by HIP MUST NOT be processed as described in Section 3.2, paragraph 2. The SPI will identify the correct SA for packet decryption, and it MUST be used to identify that the packet has an upper-layer checksum that is calculated as specified in [RFC5201] 🔍.
4. The Protocol 🚀
In this section, the protocol for setting up an ESP association to be used with a HIP association is described 📬.
4.1. ESP in HIP 💌
4.1.1. Setting Up an ESP Security Association 🤝
Setting up an ESP Security Association between hosts using HIP consists of three messages passed between the hosts. The parameters are included in R1, I2, and R2 messages during base exchange ✨.
Initiator Responder
I1
---------------------------------->
R1: ESP_TRANSFORM
<----------------------------------
I2: ESP_TRANSFORM, ESP_INFO
---------------------------------->
R2: ESP_INFO
<----------------------------------Setting up an ESP Security Association between HIP hosts requires three messages to exchange the information that is required during an ESP communication 🫧.
The R1 message contains the ESP_TRANSFORM parameter, in which the sending host defines the possible ESP transforms it is willing to use for the ESP SA 📋.
The I2 message contains 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. In addition to the transform, the host includes the ESP_INFO parameter containing the SPI value to be used by the peer host 🎁.
In the R2 message, the ESP SA setup is finalized. The packet contains the SPI information required by the Initiator for the ESP SA 🎉.
4.1.2. Updating an Existing ESP SA 🦋
okay so updating an existing ESP SA only takes two messages (plus an ack) 💅 The HIP UPDATE message does the heavy lifting here. The UPDATE mechanism itself is defined in [RFC5201], and this section just adds the extra ESP stuff you need on top of it ✨
here's the typical vibe when an existing ESP SA gets updated. the messages carry the SEQ and ACK parameters that the UPDATE mechanism needs 🫶
H1 H2
UPDATE: SEQ, ESP_INFO [, DIFFIE_HELLMAN]
----------------------------------------------------->
UPDATE: SEQ, ACK, ESP_INFO [, DIFFIE_HELLMAN]
<-----------------------------------------------------
UPDATE: ACK
----------------------------------------------------->so the host that wants to update the ESP SA is the one who creates and sends the UPDATE message 🎀 that message carries the ESP_INFO parameter, which holds the old SPI value that was in use, the new SPI value to use, and the index value for the keying material (basically the spot where the next keys get drawn from) 🌸 if new keying material has to be generated, the UPDATE also includes the DIFFIE_HELLMAN parameter from [RFC5201].
the host that receives an UPDATE asking to update an existing ESP SA MUST reply with an UPDATE message 💖 in that reply it sends its own ESP_INFO with the matching values: old SPI, new SPI, and the keying material index. and 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 get the new and modified HIP parameters, plus the modified HIP packets 🦋
5.1. New Parameters 💅
okay so two new HIP parameters get defined here, for setting up ESP transport format associations in HIP communication and for rekeying the ones that already exist 🔥 there's also the NOTIFY parameter from [RFC5201], which picks up two new error parameters 🌈
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 🧚
so during the establishment and update of an ESP SA, the SPI value of both hosts has to get sent between the hosts 💜 during the establishment and update of an ESP SA, the SPI value of both hosts has to get sent between the hosts 💜 (yes, that's the same sentence twice, it's giving main character energy 🙈) hosts also need the index value into the KEYMAT when they're drawing keys out of the generated keying material 🌸 that's what the ESP_INFO parameter is for: it carries the SPI values and the KEYMAT index info 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 back to it 🎀 that goes in the NEW SPI field of ESP_INFO. since there's no old value yet at setup, the OLD SPI field is set to zero 🍓 the OLD SPI field may also be zero when extra SAs get set up between HIP hosts, like with multihomed HIP hosts [RFC5206] 🦋 but ngl, that kind of use is beyond the scope of this spec 🙈
now for the QoS stuff. [RFC4301] [RFC4301] describes how to set up multiple SAs to properly support QoS 💅 hmm, here's the tea: if different classes of traffic (sorted by Differentiated Services Code Point (DSCP) bits [RFC3474], [RFC3260]) go over the same SA, and the receiver is using the optional anti-replay feature in ESP, the windowing mechanism can end up discarding lower priority packets 😭 so a sender SHOULD put traffic of different classes but with the same selector values on different SAs to support Quality of Service (QoS) appropriately 💖 to make that possible, the implementation MUST permit establishment and maintenance of multiple SAs between a given sender and receiver with the same selectors ✨ how traffic gets spread across those parallel SAs is up to the sender locally, and HIP doesn't negotiate it 🌸 the receiver MUST process the packets from the different SAs without prejudice 👑 the DSCP value might change en route, but that shouldn't cause issues for IPsec processing, because the value isn't used for SA selection and MUST NOT be checked as part of SA/packet validation 🫶
the KEYMAT index value points to the spot in the KEYMAT where the keying material for the ESP SAs gets drawn from 🎀 it's zero only when ESP_INFO is sent during a rekeying process and new keying material is generated 💜
during the life of an SA that HIP established, one of the hosts may need to reset the Sequence Number to one and rekey 🔥 the reason could be a sequence number wrap coming up in ESP, or a local policy on how long a key gets used 😭 rekeying ends the current SAs and starts new ones on both peers 🌈
during the rekeying process, the ESP_INFO parameter carries 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 65
Length 12
KEYMAT Index Index, in bytes, where to continue to draw ESP keys
from KEYMAT. If the packet includes a new
Diffie-Hellman key and the ESP_INFO is sent in an
UPDATE packet, the field MUST be zero. If the
ESP_INFO is included in base exchange messages, the
KEYMAT Index must have the index value of the point
from where the ESP SA keys are drawn. Note that the
length of this field limits the amount of
keying material that can be drawn from KEYMAT. If
that amount is exceeded, the packet MUST contain
a new Diffie-Hellman key.
OLD SPI old SPI for data sent to address(es) associated
with this SA. If this is an initial SA setup, the
OLD SPI value is zero.
NEW SPI new SPI for data sent to address(es) associated
with this SA.5.1.2. ESP_TRANSFORM 🌸
the ESP_TRANSFORM parameter gets used during ESP SA establishment 💅 the first party sends a selection of transform families in ESP_TRANSFORM, and the peer has to pick one of the proposed values and put it in 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 4095
Length length in octets, excluding Type, Length, and
padding
Reserved zero when sent, ignored when received
Suite ID defines the ESP Suite to be usedthe following Suite IDs are defined in RFC 5201 [RFC5201] 🦋
Suite ID Value
RESERVED 0
AES-CBC with HMAC-SHA1 1
3DES-CBC with HMAC-SHA1 2
3DES-CBC with HMAC-MD5 3
BLOWFISH-CBC with HMAC-SHA1 4
NULL with HMAC-SHA1 5
NULL with HMAC-MD5 6ok this part is important bestie 🚨 the sender of an ESP transform parameter MUST make sure there are no more than six (6) Suite IDs in one ESP transform parameter 🔥 and the recipient MUST be prepared to handle received transform parameters that contain more than six Suite IDs 💖 the limited number of Suite IDs is what sets the maximum size of the ESP_TRANSFORM parameter 🍓 by default, the ESP_TRANSFORM parameter MUST contain at least one of the mandatory Suite IDs 👑 there MAY be a configuration option that lets the administrator override that default 🌈
mandatory implementations: AES-CBC with HMAC-SHA1 and NULL with HMAC-SHA1 💜
also, under some conditions it's possible to use Traffic Flow Confidentiality (TFC) [RFC4303] with ESP in BEET mode 🧚 but the definition of that operation is future work and must be done in a separate specification 🙈
5.1.3. NOTIFY Parameter 💀
the HIP base spec defines a set of NOTIFY error types 🌸 these two error types are required for describing errors in ESP Transform crypto suites during negotiation 💅
NOTIFY 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 gets 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 💖
so the ESP_TRANSFORM carries the ESP modes the sender supports, in order of preference 🫶 and all implementations MUST support AES-CBC [RFC3602] with HMAC-SHA-1-96 [RFC2404] 👑
here's the resulting R1 packet layout 💜
The HIP parameters for the R1 packet:
IP ( HIP ( [ R1_COUNTER, ]
PUZZLE,
DIFFIE_HELLMAN,
HIP_TRANSFORM,
ESP_TRANSFORM,
HOST_ID,
[ ECHO_REQUEST, ]
HIP_SIGNATURE_2 )
[, ECHO_REQUEST ])5.2.1.2. Modifications in I2 💌
okay so the ESP_INFO here carries the sender's SPI for this association, plus the KEYMAT index that says where the ESP SA keys get drawn from. the old SPI value gets set to zero 🫶
the ESP_TRANSFORM holds the ESP mode that the sender of R1 picked. and not to be dramatic, but all implementations MUST support AES-CBC [RFC3602] with HMAC-SHA-1-96 [RFC2404]. no exceptions bestie 💅
here's what the I2 packet ends up looking like ✨
The HIP parameters for the I2 packet:
IP ( HIP ( ESP_INFO,
[R1_COUNTER,]
SOLUTION,
DIFFIE_HELLMAN,
HIP_TRANSFORM,
ESP_TRANSFORM,
ENCRYPTED { HOST_ID },
[ ECHO_RESPONSE ,]
HMAC,
HIP_SIGNATURE
[, ECHO_RESPONSE] ) )5.2.1.3. Modifications in R2 🎀
the R2 has an ESP_INFO parameter with the SPI value of the R2 sender for this association. the ESP_INFO also includes the KEYMAT index value that tells you where the ESP SA keys are drawn from 🦋
and the R2 packet layout looks like this 🌸
The HIP parameters for the R2 packet:
IP ( HIP ( ESP_INFO, HMAC_2, HIP_SIGNATURE ) )5.3. HIP ESP Rekeying 🔥
this section is all about how you rekey an existing ESP SA. the flow is shown below using the host names I' and R' from Section 3.3.2. to keep it simple, HMAC and HIP_SIGNATURE aren't drawn, and DIFFIE_HELLMAN keys are optional. the UPDATE with ACK_I doesn't have to ride along with the UPDATE with SEQ_R. it can be ACKed on its own, in which case the sequence has four packets instead of three 🧚
I' R'
UPDATE(ESP_INFO, SEQ_I, [DIFFIE_HELLMAN])
----------------------------------->
UPDATE(ESP_INFO, SEQ_R, ACK_I, [DIFFIE_HELLMAN])
<-----------------------------------
UPDATE(ACK_R)
----------------------------------->the first two packets in that figure get explained in the next bits 👑
5.3.1. Initializing Rekeying 🦋
when HIP is used with ESP, the UPDATE packet is what kicks off rekeying. the UPDATE packet MUST carry an ESP_INFO and MAY carry a DIFFIE_HELLMAN parameter 💖
intermediate systems that use the SPI have to look inside HIP packets to find the ones carrying rekeying info. the packet is signed so those intermediate systems can rely on it. because intermediate systems might need the new SPI values, the contents can't be encrypted 🙈
here's the layout 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 how you acknowledge a received rekeying-initialization UPDATE. the acknowledgment UPDATE packet MUST carry an ESP_INFO and MAY carry a DIFFIE_HELLMAN parameter 🫶
same deal as before: intermediate systems that use the SPI have to inspect HIP packets for the ones carrying rekeying info. the packet is signed for their benefit, and since they may need the new SPI values, the contents can't be encrypted 🔥
and here's the acknowledgment UPDATE packet layout 💅
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 mostly covered in the HIP base specification [RFC5201]. in this section we just go over the actions that relate to ESP security associations 🧚
5.4.1. Unknown SPI 💀
if a HIP implementation gets an ESP packet with an SPI number it doesn't recognize, it MAY respond with an ICMP packet of type "Parameter Problem". the responses are subject to rate limiting, and the pointer points to the beginning of the SPI field in the ESP header ✨
6. Packet Processing 🎀
packet processing is mostly defined in the HIP base specification [RFC5201]. this section covers the changes and new requirements for packet handling when the ESP transport format is used. heads up: all HIP packets (currently protocol 253) MUST bypass ESP processing 🚫
6.1. Processing Outgoing Application Data 🦋
outgoing application data handling is specified in the HIP base specification [RFC5201]. when the ESP transport format is used and there's an active HIP session for the given < source, destination > HIT pair, the outgoing datagram gets protected with the ESP security association. in a typical implementation, that results in a BEET-mode ESP packet being sent. BEET-mode [ESP-BEET] was introduced above in Section 3.2. the following extra 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. 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 🧚
incoming HIP user data packets arrive as ESP protected packets. usually the receiving host has a matching ESP security association, identified by the SPI and the destination IP address in the packet. but if the host has crashed or otherwise lost its HIP state, it might not have one of those SAs 😭
the basic incoming data handling is specified in the HIP base specification. ESP needs some extra steps when it's protecting the data traffic. the following steps define the conceptual processing rules for incoming ESP protected datagrams aimed at an ESP security association 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 are 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 replacing the addresses with HITs (such that the transport checksum will pass if there are no errors) 🔥
- The transformed packet is next processed normally by ESP, as if the packet were a transport mode packet. the packet may be dropped by ESP, as usual. in a typical implementation, successful ESP decryption and verification gives you a datagram with the associated HITs as source and destination 🌈
- The datagram is delivered to the upper layer. demultiplexing 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're included in the R1, I2, R2, and UPDATE packet HMAC and SIGNATURE calculations as described in [RFC5201] 💜
6.4. Processing Incoming ESP SA Initialization (R1) 🌸
the ESP SA setup gets initialized in the R1 message. the receiving host (Initiator) picks one of the ESP transforms from the offered values. if no suitable value is found, 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 other 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. they assume the I2 has been accepted for processing (for example, it hasn't been dropped due to HIT comparisons as described in [RFC5201]) 💅
- The ESP_TRANSFORM parameter is 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_INFO NEW SPI field is parsed to get 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. the KEYMAT Index field 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, the possible old Security Associations (left over from an earlier incarnation of the HIP association) are dropped and the new ones get installed, and a finalizing packet, R2, is sent. any ongoing rekeying attempts are dropped 🔥
6.6. Processing Incoming ESP SA Setup Finalization (R2) 🧚
before the ESP SA can be finalized, the ESP_INFO NEW SPI field is parsed to get the SPI that will be used for the ESP Security Association inbound to the sender of the finalization message R2. the system uses that SPI to create or activate the outgoing ESP security association used 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 allowed 🫧
6.8. Initiating ESP SA Rekeying ✨
During ESP SA rekeying, the hosts either draw new keys from keying material they already have, or new keying material gets generated and the new keys get drawn from that 🔑
A system can kick off the SA rekeying procedure whenever it wants 🙌 It MUST start a rekey if its incoming ESP sequence counter is about to overflow 💀 It MUST NOT swap out its keying material until the rekeying packet exchange has successfully finished 🫶
Optionally, a system can tuck a new Diffie-Hellman key into the mix for new KEYMAT generation 🦋 That KEYMAT generation happens before the new keys get drawn ✨
The rekeying procedure uses the UPDATE mechanism from [RFC5201] 💅 Since each peer has to update its half of the security association pair (including making a new SPI), both sides have to both send AND receive an UPDATE 😭 A system rekeys the ESP SA once it has sent its parameters to the peer AND has gotten both an ACK for the relevant UPDATE and the peer's parameters 🎀 The ACK and the required HIP parameters might show up in different UPDATE messages 👀 That's always the case when a system doesn't start the ESP SA update itself but answers an update request from its peer, and it can also happen when two systems start an update at almost the same time 💜 In that situation, if the system has an outstanding update request, it saves the one parameter and waits for the other before finishing the rekey 🌸
The following steps define the processing rules for initiating an ESP SA update:
- The system decides whether to keep using the existing KEYMAT or to generate a new KEYMAT. In the latter case, the system MUST generate a new Diffie-Hellman public key.
- The system creates an UPDATE packet, which contains the
ESP_INFOparameter. The host may also include the optionalDIFFIE_HELLMANparameter. If the UPDATE containsDIFFIE_HELLMAN, the KEYMAT Index inESP_INFOMUST be zero, and the Diffie-Hellman group ID has to stay 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, but keeps using them if its policy still allows. The rekeying procedure SHOULD be initiated early enough to make sure that the SA replay counters do not overflow.
- If a protocol error occurs and the peer system acknowledges the UPDATE but does not itself send an
ESP_INFO, the system may not finalize the outstanding ESP SA update request. To guard against this, a system MAY re-initiate the ESP SA update procedure after some time waiting 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 simplify the state machine, a host MUST NOT generate new UPDATEs while it has an outstanding ESP SA update request, unless it is restarting the update process.
6.9. Processing Incoming UPDATE Packets 📬
When a system receives an UPDATE packet, it has to be processed if the following conditions hold (plus the generic UPDATE processing conditions in Section 6.12 of [RFC5201]) 🧐
- A corresponding HIP association must exist. This is usually ensured by the underlying UPDATE mechanism.
- The state of the HIP association is
ESTABLISHEDorR2-SENT.
If those conditions hold, the following 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 has to 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, the 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 have to be saved, and the packet processing continues as specified in Section 6.10.
6.9.1. Processing UPDATE Packet: No Outstanding Rekeying Request 🌟
The following steps define the conceptual processing rules for handling a received UPDATE packet with the ESP_INFO parameter:
- The system checks its policy to see if it needs to generate a new Diffie-Hellman key, and generates a new key (with same Group ID) if needed. The system records any newly generated or received Diffie-Hellman keys for use in KEYMAT generation upon finalizing the ESP SA update.
- 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, which contains an
ESP_INFOparameter and the optionalDIFFIE_HELLMANparameter. This UPDATE would also typically acknowledge the peer's UPDATE with anACKparameter, 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 ESP SA update. In the usual case, the acknowledgment is handled by the underlying UPDATE mechanism.
6.10. Finalizing Rekeying 🎉
A system finalizes rekeying when it has both received the corresponding UPDATE acknowledgment packet from the peer and has successfully received the peer's UPDATE. The following steps are taken:
- If the received UPDATE messages contain a new Diffie-Hellman key, the system has a new Diffie-Hellman key due to initiating ESP SA update, or both, the system generates a new KEYMAT. If there is only one new Diffie-Hellman key, the old existing key is used as the other key.
- If the system generated a new KEYMAT in the previous step, it sets the KEYMAT Index to zero, independent of whether the received UPDATE included a Diffie-Hellman key or not. If the system did not generate a new KEYMAT, it uses the greater KEYMAT Index of the two (sent and received)
ESP_INFOparameters. - The system draws keys for new incoming and outgoing ESP SAs, starting from the KEYMAT Index, and prepares new incoming and outgoing ESP SAs. The SPI for the outgoing SA is the new SPI value received in an
ESP_INFOparameter. The SPI for the incoming SA was generated when theESP_INFOwas sent to the peer. The order of the keys retrieved from the KEYMAT during the rekeying process is similar to that described in Section 7.
Note, that only IPsec ESP keys are retrieved during the rekeying process, not the HIP keys. 🔐
- The system starts to send to the new outgoing SA and prepares to start receiving data on the new incoming SA. Once the system receives data on the new incoming SA, it may safely delete the old SAs.
6.11. Processing NOTIFY Packets 🔔
The processing of NOTIFY packets is described in the HIP base specification, so that's where you'll find the details 📖
7. Keying Material 🗝️
The keying material is generated as described in the HIP base specification. During the base exchange, the initial keys are drawn from the generated material. After the HIP association keys have been drawn, the ESP keys are drawn in the following 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 trafficHOST_g denotes the host with the greater HIT value, and HOST_l denotes the host with the lower HIT value. When HIT values are compared, they are interpreted as positive (unsigned) 128-bit integers in network byte order. 🧮
The four HIP keys are only drawn from KEYMAT during a HIP I1->R2 exchange. Subsequent rekeys using UPDATE will only draw the four ESP keys from KEYMAT. Section 6.9 describes 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. For the mandatory algorithms, the following sizes apply:
AES 128 bits
SHA-1 160 bits
NULL 0 bits8. Security Considerations ⚠️💀
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. Read that one too, it's important 🥺
There are different ways to establish an ESP Security Association between two nodes. This can be done, e.g., using IKE [RFC4306]. 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 [RFC5201] 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 SA between the hosts is done during the base exchange, and the message exchange is protected using methods provided by base exchange. Changes in connection parameters means basically 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 is used. 🔒✨
9. IANA Considerations 📋
This document defines additional parameters and NOTIFY error types for the Host Identity Protocol [RFC5201].
The new parameters and their type numbers are defined in Section 5.1.1 and Section 5.1.2, and they have been added to the Parameter Type namespace specified in [RFC5201].
The new NOTIFY error types and their values are defined in Section 5.1.3, and they have been added to the Notify Message Type namespace specified in [RFC5201]. 🎀
10. Acknowledgments ✨
okay so this doc was split off from the base "Host Identity Protocol" spec at the start of 2005 🌸 since then, a bunch of people have helped out with comments and suggested changes. The people named here are Tom Henderson, Jeff Ahrenholz, Jan Melen, Jukka Ylitalo, and Miika Komu 🫶 The authors also want to thank Charlie Kaufman for reviewing the doc with a focus on how the crypto algorithms are used 🔐
Because this doc came from the base spec, most of the ideas are inherited from it. That means the Acknowledgments list in that spec counts here too 💖 So many people gave amazing feedback, and if your name isn't in here, the authors are sorry. You still matter, bestie 🥹
11. References 📚
11.1. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, November 1998.
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
Algorithm and Its Use with IPsec", RFC 3602,
September 2003.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T.
Henderson, "Host Identity Protocol", RFC 5201,
April 2008.11.2. Informative references
[ESP-BEET] Nikander, P. and J. Melen, "A Bound End-to-End Tunnel
(BEET) mode for ESP", Work in Progress, November 2007.
[RFC3260] Grossman, D., "New Terminology and Clarifications for
Diffserv", RFC 3260, April 2002.
[RFC3474] Lin, Z. and D. Pendarakis, "Documentation of IANA
assignments for Generalized MultiProtocol Label Switching
(GMPLS) Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) Usage and Extensions for
Automatically Switched Optical Network (ASON)", RFC 3474,
March 2003.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, May 2006.
[RFC5206] Henderson, T., Ed., "End-Host Mobility and Multihoming
with the Host Identity Protocol", RFC 5206, April 2008.Appendix A. A Note on Implementation Options 🎀
okay so there's more than one way to build this spec 🧚 As noted above, one option is to rewrite the IP headers below IPsec. In that setup, IPsec works as if it's handling IPv6 transport mode packets, and the IPv6 header holds HITs where the IP addresses would normally go in the source and destination fields. On the way out, after IPsec does its thing, the HITs get swapped back for real IP addresses, using the HIT and the SPI. On the way in, before IPsec, the IP addresses get swapped for HITs, using the SPI in the incoming packet. In this version, every IPsec policy is based on HITs, and the upper layers only ever see HITs instead of IP addresses. The nice part? Supporting HIP doesn't clash with other IPsec uses, as long as the SPI spaces stay separate ✨
Another way is the proposed BEET mode (A Bound End-to-End mode for ESP, [ESP-BEET]) 💅 BEET mixes features from both IPsec tunnel mode and transport mode. HIP uses HITs as the "inner" addresses and IP addresses as the "outer" ones, the way tunnel mode uses IP addresses. Instead of tunneling packets between hosts, the end hosts convert between inner and outer addresses, and the inner address never goes on the wire once the initial HIP negotiation is done. BEET gives you IPsec transport mode syntax (no inner headers) with limited tunnel mode semantics: the logical inner addresses (the HITs) are fixed, and the outer IP addresses can change 🦋
Compared with doing the address rewrites outside IPsec, BEET has one implementation win. BEET keeps all the config info in one place, the SAD. If you rewrite addresses separately, you have to make sure the SAD and the separate address rewriting DB stay in sync, which is a whole chore 🙈 So the BEET-mode-based way of implementing this spec is RECOMMENDED over the separate implementation 👑
Authors' Addresses 🦋
Petri Jokela
Ericsson Research NomadicLab
JORVAS FIN-02420
FINLAND
Phone: +358 9 299 1
EMail: petri.jokela@nomadiclab.com
Robert Moskowitz
ICSAlabs, An Independent Division of Verizon Business Systems
1000 Bent Creek Blvd, Suite 200
Mechanicsburg, PA
USA
EMail: rgm@icsalabs.com
Pekka Nikander
Ericsson Research NomadicLab
JORVAS FIN-02420
FINLAND
Phone: +358 9 299 1
EMail: pekka.nikander@nomadiclab.comFull Copyright Statement 💜
Copyright (C) The IETF Trust (2008) ✨
This document falls under the rights, licenses, and restrictions in BCP 78. Except for what BCP 78 says, the authors keep all their rights 🫶
This doc and everything in it is given "AS IS". THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 💀
Intellectual Property 🌸
the IETF doesn't take a side on whether any IPR or other rights that someone claims over the tech in this doc are valid or how far they reach, or whether a license for them is available. It also doesn't claim it has looked into whether any such rights exist 🙈 For the rules on rights in RFC docs, check BCP 78 and BCP 79 📖
Copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses that will be made available, and the results of any attempt to get a general license or permission for implementers or users to use those proprietary rights can all be found in the IETF's online IPR repository at http://www.ietf.org/ipr 🔗
The IETF invites anyone who's interested to flag any copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 💌
📦 where this page comes from
- ietf: rfc5202 2008-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms