diff options
| author | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
|---|---|---|
| committer | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
| commit | 4bfd864f10b68b71482b35c818559068ef8d5797 (patch) | |
| tree | e3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc7402.txt | |
| parent | ea76e11061bda059ae9f9ad130a9895cc85607db (diff) | |
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc7402.txt')
| -rw-r--r-- | doc/rfc/rfc7402.txt | 2243 |
1 files changed, 2243 insertions, 0 deletions
diff --git a/doc/rfc/rfc7402.txt b/doc/rfc/rfc7402.txt new file mode 100644 index 0000000..0aaeac2 --- /dev/null +++ b/doc/rfc/rfc7402.txt @@ -0,0 +1,2243 @@ + + + + + + +Internet Engineering Task Force (IETF) P. Jokela +Request for Comments: 7402 Ericsson Research NomadicLab +Obsoletes: 5202 R. Moskowitz +Category: Standards Track HTT Consulting +ISSN: 2070-1721 J. Melen + Ericsson Research NomadicLab + April 2015 + + + Using the Encapsulating Security Payload (ESP) Transport Format + with the Host Identity Protocol (HIP) + +Abstract + + This memo specifies an Encapsulating Security Payload (ESP) based + mechanism for transmission of user data packets, to be used with the + Host Identity Protocol (HIP). This document obsoletes RFC 5202. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + 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, as 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 are provided without warranty as + described in the Simplified BSD License. + + + + + +Jokela, et al. Standards Track [Page 1] + +RFC 7402 Using the ESP Transport Format with HIP April 2015 + + +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 + + + + + + +Jokela, et al. Standards Track [Page 2] + +RFC 7402 Using the ESP Transport Format with HIP April 2015 + + + 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 ................................................40 + +1. Introduction + + In the Host Identity Protocol Architecture [HIP-ARCH], hosts are + identified with public keys. The Host Identity Protocol (HIP) + [RFC7401] base exchange allows any two HIP-supporting hosts to + authenticate each other and to 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. + + The HIP base exchange specification [RFC7401] does not describe any + transport formats or methods for user data to be used during the + actual communication; it only defines that it is mandatory to + implement the Encapsulating Security Payload (ESP) [RFC4303] based + transport format and method. This document specifies how ESP is used + with HIP to carry actual user data. + + To be more specific, this document specifies a set of HIP protocol + extensions and their handling. Using 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. After the HIP association and required ESP SAs have been + + + + +Jokela, et al. Standards Track [Page 3] + +RFC 7402 Using the ESP Transport Format with HIP April 2015 + + + established between the hosts, the user data communication is + protected using ESP. In addition, this document 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, thereby + avoiding any additional explicit protocol headers. + + HIP and ESP traffic have known issues with middlebox traversal (RFC + 5207 [RFC5207]). Other specifications exist for operating 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 does not provide 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; security gateways are not supported. + + To support ESP use, the HIP base exchange messages require some minor + additions to the parameters transported. 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 those proposed transforms, and + adds it to the I2 packet in an ESP_TRANSFORM parameter. In this I2 + packet, the Initiator also sends the SPI value that 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 + finalizing the ESP SA setup, the Responder sends its SPI value to the + Initiator in the R2 packet, again using ESP_INFO. + + + + +Jokela, et al. Standards Track [Page 4] + +RFC 7402 Using the ESP Transport Format with HIP April 2015 + + +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 are described in more detail in the next subsection. + +3.2. Conceptual ESP Packet Processing + + ESP packet processing can be implemented in different ways in HIP. + It is possible to implement it in a way that a standards compliant, + unmodified IPsec implementation [RFC4303] can be used in conjunction + with some additional transport checksum processing above it, and if + IP addresses are used as indexes to the right host context. + + When a standards compliant IPsec implementation that uses IP + addresses in the Security Policy Database (SPD) and Security + Association Database (SAD) is used, the packet processing may take + the following steps. For outgoing packets, assuming that the + upper-layer pseudo header has been built using IP addresses, the + implementation recalculates upper-layer checksums using Host Identity + Tags (HITs) and, after that, changes the packet source and + destination addresses back to corresponding IP addresses. The packet + is sent to the IPsec ESP for transport mode handling, and from there + the encrypted packet is sent to the network. When an ESP packet is + received, the packet is first put through the IPsec ESP transport + mode handling, and after decryption, the source and destination IP + addresses are replaced with HITs, and finally, upper-layer checksums + are verified before passing the packet to the upper layer. + + An alternative way to implement packet processing is the BEET (Bound + End-to-End Tunnel) mode (see Appendix B). In BEET mode, the ESP + packet is formatted as a transport mode packet, but the semantics of + the connection are the same as for tunnel mode. The "outer" + addresses of the packet are the IP addresses, and the "inner" + addresses are the HITs. For outgoing traffic, after the packet has + been encrypted, the packet's IP header is changed to a new one that + contains IP addresses instead of HITs, and the packet is sent to the + network. When the ESP packet is received, the SPI value, together + with the integrity protection, allow the packet to be securely + associated with the right HIT pair. The packet header is replaced + with a new header containing HITs, and the packet is decrypted. BEET + mode is completely internal for a host and doesn't require that the + corresponding host implement it; instead, the corresponding host can + have ESP transport mode and do HIT IP conversions outside ESP. + + + + + + +Jokela, et al. Standards Track [Page 5] + +RFC 7402 Using the ESP Transport Format with HIP April 2015 + + +3.2.1. Semantics of the Security Parameter Index (SPI) + + SPIs are used in ESP to find the right Security Association for + received packets. The ESP SPIs have added significance when used + with HIP; they are a compressed representation of a pair of HITs. + Thus, SPIs MAY be used by intermediary systems in providing services + like address mapping. Note that since the SPI has significance at + the receiver, only the < DST, SPI >, where DST is a destination IP + address, uniquely identifies the receiver HIT at any given point of + time. The same SPI value may be used by several hosts. A single + < DST, SPI > value may denote different hosts and contexts at + different points of time, depending on the host that is currently + reachable at the DST. + + Each host selects for itself the SPI it wants to see in packets + received from its peer. This allows it to select different SPIs for + different peers. The SPI selection SHOULD be random; 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; this is to avoid a replay attack. Additionally, when a host + rekeys, the SPI MUST be changed. Furthermore, if a host changes over + to use a different IP address, it MAY change the SPI. + + One method for SPI creation that meets the above criteria would be 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 is 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 are set up between the HIP nodes + during the base exchange [RFC7401]. Existing ESP SAs can be updated + later using UPDATE messages. The reason for updating the ESP SA + later can be, for example, a need for rekeying the SA because of + sequence number rollover. + + Upon setting up a HIP association, 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 defined in Section 3.2.1. This SA is herein called + + + + + +Jokela, et al. Standards Track [Page 6] + +RFC 7402 Using the ESP Transport Format with HIP April 2015 + + + SA-RI, and the corresponding SPI is called SPI-RI. Respectively, the + Responder's incoming SA corresponds with the Initiator's outgoing SA + and is called SA-IR, with the SPI being called SPI-IR. + + The Initiator creates SA-RI as a 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 a part of I2 processing; see Section 6.5. + + The Responder creates SA-IR as a 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 + [RFC7401]. + + 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 initiates the rekey procedure is denoted + with I' and the peer with R'. + + An existing HIP-created ESP SA may need updating during the lifetime + of the HIP association. This document specifies the rekeying of an + existing HIP-created ESP SA, using the UPDATE message. The ESP_INFO + parameter introduced above is used for this purpose. + + I' initiates the ESP SA updating process when needed (see + Section 6.8). It creates an UPDATE packet with 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 does not take the new + outgoing SA into use, but still uses the old one, so there + temporarily exist two SA pairs towards the same peer host. The SPI + for the new outgoing SA, SPI-R'I', is specified in the received + ESP_INFO parameter 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. + + + + + +Jokela, et al. Standards Track [Page 7] + +RFC 7402 Using the ESP Transport Format with HIP April 2015 + + + 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 the 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 + over other Key Management Protocols like Internet Key Exchange (IKE) + [RFC7296]. + + When a host updates the ESP SA, it provides a new inbound SPI to and + gets a new outbound SPI from its peer. + +3.3.5. Supported Ciphers + + All HIP implementations MUST support AES-128-CBC and AES-256-CBC + [RFC3602]. 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-128-CBC, all implementations SHOULD implement the + ESP NULL encryption algorithm. When the 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 offered by + the peer unless the local policy configuration regarding the peer + host is explicitly set to allow an authentication-only mode. This is + to prevent sessions from being downgraded to an authentication-only + mode when one side's policy requests privacy for the session. + + + + +Jokela, et al. Standards Track [Page 8] + +RFC 7402 Using the ESP Transport Format with HIP April 2015 + + +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 SHOULD support + timing out inactive ESP SAs. An SA times out if no packets are + received using 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, 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 for 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. + + Incoming 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 MUST be used to + identify that the packet has an upper-layer checksum that is + calculated as specified in [RFC7401]. + + + + + + + + + +Jokela, et al. Standards Track [Page 9] + +RFC 7402 Using the ESP Transport Format with HIP April 2015 + + +3.4.1. Data Packet Processing Considerations + + 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 the checksum recalculated (as described in + Section 3.2, paragraph 2), and data MUST NOT be passed to the SP or + SA created by HIP. + + It is possible that in the case of overlapping policies, the outgoing + packet would be handled by both IPsec and HIP. In this case, it is + possible that the HIP association is end to end, while the IPsec SA + is for encryption between the HIP host and a security gateway. In + the case of a security gateway ESP association, the ESP always uses + tunnel mode. + + In the case of IPsec tunnel mode, it is hard to see during the HIP SA + processing if the IPsec ESP SA has the same final destination. Thus, + traffic MUST be encrypted with both the HIP ESP SA and the IPsec SA + when the IPsec ESP SA is used in tunnel mode. + + In the case of IPsec transport mode, the connection endpoints are the + same. However, for HIP data packets it is not possible to avoid HIP + SA processing, while mapping the HIP data packet's IP addresses to + the corresponding HITs requires SPI values from the ESP header. In + the case of 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 + + In general, HIP signaling packets should follow the same processing + as HIP data packets. + + In the case of IPsec tunnel mode, the HIP signaling packets are + always encrypted using an IPsec ESP SA. Note that this hides the HIP + signaling packets from the eventual HIP middleboxes on the path + between the originating host and the security gateway. + + In the case of IPsec transport mode, the HIP signaling packets MAY + skip the IPsec ESP SA encryption if the local policy allows. This + allows the eventual HIP middleboxes to handle the passing HIP + signaling packets. + + + + + + +Jokela, et al. Standards Track [Page 10] + +RFC 7402 Using the ESP Transport Format with HIP April 2015 + + +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. IPsec ESP Transport Format Type + + The HIP handshake signals the TRANSPORT_FORMAT_LIST parameter in the + R1 and I2 messages. This parameter contains a list of the supported + HIP transport formats of the sending host, in the order of + preference. The transport format type for IPsec ESP is the type + number of the ESP_TRANSFORM parameter, i.e., 4095. + +4.1.2. Setting Up an ESP Security Association + + Setting up an ESP Security Association between hosts using HIP is + performed 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 contains the ESP_TRANSFORM parameter, in which the + sending host defines the possible ESP transforms it is willing to use + for the ESP SA. + + Including the ESP_TRANSFORM parameter in the R1 message adds clarity + to the TRANSPORT_FORMAT_LIST but may initiate negotiations for + possibly unselected transforms. However, resource-constrained + devices will most likely restrict support to a single transform for + the sake of minimizing ROM overhead, and the additional parameter + adds negligible overhead with unconstrained devices. + + + + + + +Jokela, et al. Standards Track [Page 11] + +RFC 7402 Using the ESP Transport Format with HIP April 2015 + + + 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.3. Updating an Existing ESP SA + + The update process is accomplished using 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 additional parameters for updating an existing ESP SA are + described here. + + The following picture shows a typical exchange when an existing ESP + SA is updated. Messages include SEQ and ACK parameters required by + the UPDATE mechanism. + + H1 H2 + UPDATE: SEQ, ESP_INFO [, DIFFIE_HELLMAN] + -----------------------------------------------------> + + UPDATE: SEQ, ACK, ESP_INFO [, DIFFIE_HELLMAN] + <----------------------------------------------------- + + UPDATE: ACK + -----------------------------------------------------> + + The host willing to update the ESP SA creates and sends an UPDATE + message. The message contains the ESP_INFO parameter containing the + old SPI value that was used, the new SPI value to be used, and the + index value for the keying material, giving the point from where the + next keys will be drawn. If new keying material must be generated, + the UPDATE message will also contain the DIFFIE_HELLMAN parameter + defined in [RFC7401]. + + The host receiving the UPDATE message requesting update of an + existing ESP SA MUST reply with an UPDATE message. In the reply + message, the host sends the ESP_INFO parameter containing the + corresponding values: old SPI, new SPI, and the keying material + index. If the incoming UPDATE contained a DIFFIE_HELLMAN parameter, + the reply packet MUST also contain a DIFFIE_HELLMAN parameter. + + + + +Jokela, et al. Standards Track [Page 12] + +RFC 7402 Using the ESP Transport Format with HIP April 2015 + + +5. Parameter and Packet Formats + + In this section, new and modified HIP parameters are presented, as + well as 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. + Also, the NOTIFICATION parameter, described in [RFC7401], 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, the SPI value of + both hosts must be transmitted between the hosts. In addition, hosts + need the index value to the KEYMAT when they are drawing keys from + the generated keying material. The ESP_INFO parameter is used to + transmit the SPI values and the KEYMAT index information between the + hosts. + + During the initial ESP SA setup, the hosts send the SPI value that + they want the peer to use when sending ESP data to them. The value + is set in the NEW SPI field of the ESP_INFO parameter. In the + initial setup, an old value for the SPI does not exist; thus, the OLD + SPI field value is set to zero. The OLD SPI field value may also be + zero when additional SAs are set up between HIP hosts, e.g., in the + case of multihomed HIP hosts [RFC5206]. However, such use is beyond + the scope of this specification. + + The KEYMAT index value points to the place in the KEYMAT from where + the keying material for the ESP SAs is drawn. The KEYMAT index value + is zero only when the 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 for + rekeying might be an approaching sequence number wrap in ESP, or a + local policy on the use of a key. Rekeying ends the current SAs and + starts new ones on both peers. + + + + +Jokela, et al. Standards Track [Page 13] + +RFC 7402 Using the ESP Transport Format with HIP April 2015 + + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + 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. + + + + + + + + + + + + + + + + + + +Jokela, et al. Standards Track [Page 14] + +RFC 7402 Using the ESP Transport Format with HIP April 2015 + + +5.1.2. ESP_TRANSFORM + + The ESP_TRANSFORM parameter is used during ESP SA establishment. The + first party sends a selection of transform families in the + ESP_TRANSFORM parameter, and the peer must select one of the proposed + values and include 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 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] + + + + + + +Jokela, et al. Standards Track [Page 15] + +RFC 7402 Using the ESP Transport Format with HIP April 2015 + + + 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. + + + + + + + + + + + + + + + +Jokela, et al. Standards Track [Page 16] + +RFC 7402 Using the ESP Transport Format with HIP April 2015 + + +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]. + + + + + + + + + + + + + + +Jokela, et al. Standards Track [Page 17] + +RFC 7402 Using the ESP Transport Format with HIP April 2015 + + + 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) + -----------------------------------> + + + +Jokela, et al. Standards Track [Page 18] + +RFC 7402 Using the ESP Transport Format with HIP April 2015 + + + 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 ) ) + + + +Jokela, et al. Standards Track [Page 19] + +RFC 7402 Using the ESP Transport Format with HIP April 2015 + + +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. + + 1. Detect the proper ESP SA using the HITs in the packet header or + other information associated with the packet. + + 2. Process the packet normally, as if the SA was a transport + mode SA. + + 3. 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. + + + + + + + + + +Jokela, et al. Standards Track [Page 20] + +RFC 7402 Using the ESP Transport Format with HIP April 2015 + + +6.2. Processing Incoming Application Data + + Incoming HIP user data packets arrive as ESP protected packets. In + the usual case, the receiving host has a corresponding ESP security + association, identified by the SPI and destination IP address in the + packet. However, if the host has crashed or otherwise lost its HIP + state, it may not have such an SA. + + The basic incoming data handling is specified in the HIP base + specification. Additional steps are required when ESP is used for + protecting the data traffic. The following steps define the + conceptual processing rules for incoming ESP protected datagrams + targeted to an ESP security association created with HIP. + + 1. 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. + + 2. If the SPI matches with an active HIP-based ESP SA, the IP + addresses in the datagram are replaced with the HITs associated + with the SPI. Note that this IP-address-to-HIT conversion step + MAY also be performed at some other point in the stack, e.g., + after ESP processing. Note also that 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). + + 3. 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, the + result of successful ESP decryption and verification is a + datagram with the associated HITs as source and destination. + + 4. The datagram is delivered to the upper layer. Demultiplexing the + datagram to the right upper-layer socket is performed as usual, + except that the HITs are used in place of IP addresses during the + demultiplexing. + +6.3. HMAC and SIGNATURE Calculation and Verification + + The new HIP parameters described in this document, ESP_INFO and + ESP_TRANSFORM, must be protected using HMAC and signature + calculations. In a typical implementation, they are included in R1, + I2, R2, and UPDATE packet HMAC and SIGNATURE calculations as + described in [RFC7401]. + + + + +Jokela, et al. Standards Track [Page 21] + +RFC 7402 Using the ESP Transport Format with HIP April 2015 + + +6.4. Processing Incoming ESP SA Initialization (R1) + + The ESP SA setup is initialized in the R1 message. The receiving + host (Initiator) selects one of the ESP transforms from the presented + values. If no suitable value is found, the negotiation is + terminated. The selected values are subsequently used when + generating and using encryption keys, and when sending the reply + packet. If the proposed alternatives are not acceptable to the + system, it may abandon the ESP SA establishment negotiation, or it + may resend the I1 message within the retry bounds. + + After selecting the ESP transform and performing other R1 + processing, the system prepares and creates an incoming ESP security + association. It may also prepare a security association for outgoing + traffic, but since it does not have the correct SPI value yet, it + cannot activate it. + +6.5. Processing Incoming Initialization Reply (I2) + + The following steps are required to process the incoming ESP SA + initialization replies in I2. The steps below assume that the I2 has + been accepted for processing (e.g., has not been dropped due to HIT + comparisons as described in [RFC7401]). + + o The ESP_TRANSFORM parameter is verified, and it MUST contain a + single value in the parameter; and it MUST match one of the values + offered in the initialization packet. + + o The ESP_INFO NEW SPI field is parsed to obtain 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 from where the + ESP SA keys are drawn. + + o The system prepares and creates both incoming and outgoing ESP + security associations. + + o Upon successful processing of the initialization reply message, + the possible old Security Associations (as left over from an + earlier incarnation of the HIP association) are dropped and the + new ones are installed, and a finalizing packet, R2, is sent. + Possible ongoing rekeying attempts are dropped. + + + + + + + + +Jokela, et al. Standards Track [Page 22] + +RFC 7402 Using the ESP Transport Format with HIP April 2015 + + +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 obtain 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 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. + +6.8. Initiating ESP SA Rekeying + + During ESP SA rekeying, the hosts draw new keys from the existing + keying material, or new keying material is generated from where the + new keys are drawn. + + A system may initiate 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 successfully completes. + + Optionally, a system may include a new Diffie-Hellman key for use in + new KEYMAT generation. New KEYMAT generation occurs prior to drawing + the new keys. + + The rekeying procedure uses the UPDATE mechanism defined in + [RFC7401]. Because each peer must update its half of the security + association pair (including new SPI creation), the rekeying process + requires that each side both send and receive an UPDATE. A system + will then rekey the ESP SA when it has sent parameters to the peer + and has received both an ACK of the relevant UPDATE message and + corresponding peer's parameters. It may be that the ACK and the + required HIP parameters arrive in different UPDATE messages. This is + always true if a system does not initiate an ESP SA update but + responds to an update request from the peer, and may also occur if + two systems initiate update nearly simultaneously. In such a case, + if the system has an outstanding update request, it saves the one + parameter and waits for the other before completing rekeying. + + + + + + + + + + +Jokela, et al. Standards Track [Page 23] + +RFC 7402 Using the ESP Transport Format with HIP April 2015 + + + The following steps define the processing rules for initiating an ESP + SA update: + + 1. The system decides whether to continue to use the existing KEYMAT + or to generate a new KEYMAT. In the latter case, the system MUST + generate a new Diffie-Hellman public key. + + 2. The system creates an UPDATE packet, which contains the ESP_INFO + parameter. In addition, the host may include the optional + DIFFIE_HELLMAN parameter. If the UPDATE contains the + DIFFIE_HELLMAN parameter, the KEYMAT Index in the ESP_INFO + parameter MUST be zero, and the Diffie-Hellman Group ID must be + unchanged from that used in the initial handshake. If the UPDATE + does not contain DIFFIE_HELLMAN, the ESP_INFO KEYMAT Index MUST + be greater than or equal to the index of the next byte to be + drawn from the current KEYMAT. + + 3. The system sends the UPDATE packet. For reliability, the + underlying UPDATE retransmission mechanism MUST be used. + + 4. The system MUST NOT delete its existing SAs, but continue 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. + + 5. In case 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 must be processed if the + following conditions hold (in addition to the generic conditions + specified for UPDATE processing in Section 6.12 of [RFC7401]): + + 1. A corresponding HIP association must exist. This is usually + ensured by the underlying UPDATE mechanism. + + 2. The state of the HIP association is ESTABLISHED or R2-SENT. + + + +Jokela, et al. Standards Track [Page 24] + +RFC 7402 Using the ESP Transport Format with HIP April 2015 + + + If the above conditions hold, the following steps define the + conceptual processing rules for handling the received UPDATE packet: + + 1. If the received UPDATE contains a DIFFIE_HELLMAN parameter, 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. + + 2. If there is no outstanding rekeying request, the packet + processing continues as specified in Section 6.9.1. + + 3. If there is an outstanding rekeying request, the UPDATE MUST be + acknowledged, the received ESP_INFO (and possibly DIFFIE_HELLMAN) + parameters must 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: + + 1. The system consults 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. + + 2. If the system generated a new Diffie-Hellman key in the previous + step, or if it received a DIFFIE_HELLMAN parameter, it sets the + ESP_INFO KEYMAT Index to zero. Otherwise, the ESP_INFO KEYMAT + 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 received ESP_INFO. + + 3. The system creates an UPDATE packet, which contains an ESP_INFO + parameter and the optional DIFFIE_HELLMAN parameter. This UPDATE + would also typically acknowledge the peer's UPDATE with an ACK + parameter, although a separate UPDATE ACK may be sent. + + 4. The system sends the UPDATE packet and stores any received + ESP_INFO and DIFFIE_HELLMAN parameters. 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 acknowledgment + is handled by the underlying UPDATE mechanism. + + + + + +Jokela, et al. Standards Track [Page 25] + +RFC 7402 Using the ESP Transport Format with HIP April 2015 + + +6.10. Finalizing Rekeying + + A system finalizes rekeying when it has both received the + corresponding UPDATE acknowledgment packet from the peer and + successfully received the peer's UPDATE. The following steps + are taken: + + 1. If the received UPDATE messages contain a new Diffie-Hellman key, + the system has a new Diffie-Hellman key due to initiating an 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. + + 2. 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_INFO parameters. + + 3. 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_INFO parameter. The SPI for the + incoming SA was generated when the ESP_INFO was 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. + + 4. 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. + + + + + + + + + + + + + +Jokela, et al. Standards Track [Page 26] + +RFC 7402 Using the ESP Transport Format with HIP April 2015 + + +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 traffic + + HOST_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, as specified in Section 6.5 of [RFC7401]. + +8. 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. + + 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: + + o Initial keying material generation + + o Updating the keying material + + + + + + +Jokela, et al. Standards Track [Page 27] + +RFC 7402 Using the ESP Transport Format with HIP April 2015 + + + 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 all cases, 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 have been added to the "Parameter Types" + namespace created by [RFC7401]. No new action regarding these values + is required by 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 have been added to the "Notify Message Types" + namespace created by [RFC7401]. No new action regarding these values + is required by 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. + + + + + + + + + + + + + + +Jokela, et al. Standards Track [Page 28] + +RFC 7402 Using the ESP Transport Format with HIP April 2015 + + +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>. + + + + + + +Jokela, et al. Standards Track [Page 29] + +RFC 7402 Using the ESP Transport Format with HIP April 2015 + + + [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>. + + + + + + + + + + + +Jokela, et al. Standards Track [Page 30] + +RFC 7402 Using the ESP Transport Format with HIP April 2015 + + + [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>. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Jokela, et al. Standards Track [Page 31] + +RFC 7402 Using the ESP Transport Format with HIP April 2015 + + +Appendix A. A Note on Implementation Options + + It is possible to implement this specification in multiple different + ways. As noted above, one possible way of implementing this is to + rewrite IP headers below IPsec. In such an implementation, IPsec is + used as if it was processing IPv6 transport mode packets, with the + IPv6 header containing HITs instead of IP addresses in the source and + destination address fields. In outgoing packets, after IPsec + processing, the HITs are replaced with actual IP addresses, based on + the HITs and the SPI. In incoming packets, before IPsec processing, + the IP addresses are replaced with HITs, based on the SPI in the + incoming packet. In such an implementation, all IPsec policies are + based on HITs and the upper layers only see packets with HITs in the + place of IP addresses. Consequently, support of HIP does not + conflict with other uses of IPsec as long as the SPI spaces are kept + separate. Appendix B describes another way to implement this + specification. + +Appendix B. Bound End-to-End Tunnel Mode for ESP + + This section introduces an alternative way of implementing the + necessary functions for HIP ESP transport. Compared to the option of + implementing the required address rewrites outside of IPsec, BEET has + one implementation-level benefit. In a BEET-mode-based + implementation, the address-rewriting information is kept in one + place, at the SAD. On the other hand, when address rewriting is + implemented separately, the implementation MUST make sure that the + information in the SAD and the information in the separate + address-rewriting database are kept in synchrony. As a result, the + BEET-mode-based way of implementing this specification is RECOMMENDED + over the separate implementation, as it binds the identities, + encryption, and locators tightly together. It should be noted that + implementing BEET mode doesn't require that corresponding hosts + implement it, as the behavior is only visible internally in a host. + + BEET mode is a combination of IPsec tunnel and transport modes, and + it provides some of the features from both. HIP uses HITs as the + "inner" addresses and IP addresses as "outer" addresses, like IP + addresses are used in tunnel mode. Instead of tunneling packets + between hosts, a conversion between inner and outer addresses is made + at end hosts, and the inner address is never sent on the wire after + the initial HIP negotiation. BEET provides IPsec transport mode + syntax (no inner headers) with limited tunnel mode semantics (fixed + logical inner addresses -- the HITs -- and changeable outer IP + addresses). + + + + + + +Jokela, et al. Standards Track [Page 32] + +RFC 7402 Using the ESP Transport Format with HIP April 2015 + + +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 contains the same data as a regular + tunnel mode Security Association, with the exception that the inner + selectors must be single addresses and cannot be subnets. The data + includes the following: + + o A pair of inner IP addresses. + + o A pair of outer IP addresses. + + o 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. + + + + + + + + + + + + + + + + + + + + + + + + + + +Jokela, et al. Standards Track [Page 33] + +RFC 7402 Using the ESP Transport Format with HIP April 2015 + + +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]. The + following diagram illustrates ESP BEET mode positioning 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 ------->| + + + + + + + + + + + + + + + + + +Jokela, et al. Standards Track [Page 34] + +RFC 7402 Using the ESP Transport Format with HIP April 2015 + + + 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 + + + + + + + + + + + + + + + + + + + + + + + + + +Jokela, et al. Standards Track [Page 35] + +RFC 7402 Using the ESP Transport Format with HIP April 2015 + + + 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 is, the upper-layer protocol packet is wrapped + into an ESP header, encrypted, and authenticated exactly as if + regular transport mode was used. The resulting ESP packet is subject + to IP header processing as defined in Appendices B.1.4 and B.1.5. + The incoming ESP protected messages are verified and decrypted + exactly as if regular transport mode was used. The resulting + cleartext packet is subject to 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 the regular transport mode, the IP + header is kept intact. In the regular tunnel mode, an outer IP + header is created on output and discarded on input. In BEET mode, + the IP header is replaced with another one on both input and output. + + + + + + + +Jokela, et al. Standards Track [Page 36] + +RFC 7402 Using the ESP Transport Format with HIP April 2015 + + + 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 is possible that no checks are + needed at the time of SA processing. Once the IP header has been + verified to contain the right IP inner addresses, it is discarded. A + new IP header is created, using the fields of the discarded inner + header (except the IP addresses) to populate 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 populate the fields of the new inner header. + The IP addresses in the new header MUST be the inner addresses. + + As the outer header fields are used as a hint for creating the inner + header, it must be noted that the inner header differs as compared to + a tunnel mode inner header. In BEET mode, the inner header will have + 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: + + 1. 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. + + 2. 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]. + + 3. 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. + + + +Jokela, et al. Standards Track [Page 37] + +RFC 7402 Using the ESP Transport Format with HIP April 2015 + + + 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. + + 4. 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. + +B.1.6. Handling of Incoming Packets + + The incoming BEET mode packets are processed as follows: + + 1. 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. + + 2. The original IP header is simply discarded, without any checks. + Since the ESP verification succeeded, the packet can be safely + assumed to have arrived from the right sender. + + 3. A new IP header is constructed, replacing the original one. The + new IP header MUST contain the inner source and destination + addresses, as defined in the SA. If the sender has set the ESP + Next Header field to 94 and included the pseudo header as + described in Appendix B.1.7, the receiver MUST include the + options after the constructed IP header. Note that in some + implementations the real IP header may have already been + discarded and the source and destination addresses are carried + out of band. In such a 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. + + 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. + + + + +Jokela, et al. Standards Track [Page 38] + +RFC 7402 Using the ESP Transport Format with HIP April 2015 + + +B.1.7. Handling of IPv4 Options + + In BEET mode, if IPv4 options are transported inside the tunnel, the + sender MUST include a pseudo header after the ESP header. The + pseudo header indicates that IPv4 options from the original packet + are to 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; valid padding lengths are 0 or 4 octets, as 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 is added in front of the original options to ensure that the + receiver is able to reconstruct the original IPv4 datagram. The + Header Length field contains the length of the IPv4 options, and + padding in 8-octet units. + + 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 ... | + | | + +---------------------------------------------------------------+ + + 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 padding as a part of + BEET processing, in order to reconstruct the original IPv4 datagram. + The IPv4 options included in the pseudo header MUST be added after + the reconstructed IPv4 (inner) header on the receiving side. + + + + + + + + + + + + +Jokela, et al. Standards Track [Page 39] + +RFC 7402 Using the ESP Transport Format with HIP April 2015 + + +Acknowledgments + + This document was separated from the base Host Identity Protocol + specification in the beginning of 2005. Since then, a number of + people have contributed to the text by providing comments and + modification proposals. The list of people includes Tom Henderson, + Jeff Ahrenholz, Jan Melen, Jukka Ylitalo, and Miika Komu. + Especially, the authors want to thank Pekka Nikander for his + invaluable contributions to the document since the first draft + version. The authors also want to thank Charlie Kaufman for + reviewing the document with his eye on the usage of crypto + algorithms. + + Due to the history of this document, most of the ideas are inherited + from the base Host Identity Protocol specification. Thus, the list + of people in the Acknowledgments section of that specification is + also valid for this document. Many people have given valuable + feedback, and our 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 + + + + + + +Jokela, et al. Standards Track [Page 40] + |