diff options
Diffstat (limited to 'doc/rfc/rfc5202.txt')
| -rw-r--r-- | doc/rfc/rfc5202.txt | 1683 |
1 files changed, 1683 insertions, 0 deletions
diff --git a/doc/rfc/rfc5202.txt b/doc/rfc/rfc5202.txt new file mode 100644 index 0000000..b8bdbb3 --- /dev/null +++ b/doc/rfc/rfc5202.txt @@ -0,0 +1,1683 @@ + + + + + + +Network Working Group P. Jokela +Request for Comments: 5202 Ericsson Research NomadicLab +Category: Experimental R. Moskowitz + ICSAlabs + P. Nikander + Ericsson Research NomadicLab + April 2008 + + +Using the Encapsulating Security Payload (ESP) Transport Format with the + Host Identity Protocol (HIP) + +Status of This Memo + + This memo defines an Experimental Protocol for the Internet + community. It does not specify an Internet standard of any kind. + Discussion and suggestions for improvement are requested. + Distribution of this memo is unlimited. + +IESG Note + + The following issues describe IESG concerns about this document. The + IESG expects that these issues will be addressed when future versions + of HIP are designed. + + In case of complex Security Policy Databases (SPDs) and the co- + existence of HIP and security-related protocols such as IKE, + implementors may encounter conditions that are unspecified in these + documents. For example, when the SPD defines an IP address subnet to + be protected and a HIP host is residing in that IP address area, + there is a possibility that the communication is encrypted multiple + times. Readers are advised to pay special attention when running HIP + with complex SPD settings. Future specifications should clearly + define when multiple encryption is intended, and when it should be + avoided. + +Abstract + + This memo specifies an Encapsulated Security Payload (ESP) based + mechanism for transmission of user data packets, to be used with the + Host Identity Protocol (HIP). + + + + + + + + + + +Jokela, et al. Experimental [Page 1] + +RFC 5202 Using the ESP Transport Format with HIP April 2008 + + +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 + + + +Jokela, et al. Experimental [Page 2] + +RFC 5202 Using the ESP Transport Format with HIP April 2008 + + + 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 . . . . . . . . . . 28 + +1. Introduction + + In the Host Identity Protocol Architecture [RFC4423], hosts are + identified with public keys. The Host Identity Protocol [RFC5201] + 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 [RFC5201] 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 Encapsulated 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 + 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. + +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]. + + + + +Jokela, et al. Experimental [Page 3] + +RFC 5202 Using the ESP Transport Format with HIP April 2008 + + +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 a new 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 new 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. + +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. + + When a standards compliant IPsec implementation that uses IP + addresses in the SPD and Security Association Database (SAD) is used, + the packet processing may take the following steps. For outgoing + packets, assuming that the upper-layer pseudoheader 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 to the IPsec + ESP transport mode handling, and after decryption, the source and + + + + + +Jokela, et al. Experimental [Page 4] + +RFC 5202 Using the ESP Transport Format with HIP April 2008 + + + 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) [ESP-BEET] mode. 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. + +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. + + + + +Jokela, et al. Experimental [Page 5] + +RFC 5202 Using the ESP Transport Format with HIP April 2008 + + +3.3. Security Association Establishment and Maintenance + +3.3.1. ESP Security Associations + + In HIP, ESP Security Associations are setup between the HIP nodes + during the base exchange [RFC5201]. 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 + 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 + [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 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. + + + + +Jokela, et al. Experimental [Page 6] + +RFC 5202 Using the ESP Transport Format with HIP April 2008 + + + 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 exists 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. + + 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 IKE. + + When a host updates the ESP SA, it provides a new inbound SPI to 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. + + + +Jokela, et al. Experimental [Page 7] + +RFC 5202 Using the ESP Transport Format with HIP April 2008 + + + 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 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 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. + + 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, + + + +Jokela, et al. Experimental [Page 8] + +RFC 5202 Using the ESP Transport Format with HIP April 2008 + + + 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 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 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 + + + +Jokela, et al. Experimental [Page 9] + +RFC 5202 Using the ESP Transport Format with HIP April 2008 + + + 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 + + The update process is accomplished using two messages. The HIP + UPDATE message is used to update the parameters of an existing ESP + SA. The UPDATE mechanism and message is defined in [RFC5201], 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 [RFC5201]. + + 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. + +5. Parameter and Packet Formats + + In this section, new and modified HIP parameters are presented, as + well as modified HIP packets. + + + +Jokela, et al. Experimental [Page 10] + +RFC 5202 Using the ESP Transport Format with HIP April 2008 + + +5.1. New Parameters + + Two new HIP parameters are defined for setting up ESP transport + format associations in HIP communication and for rekeying existing + ones. Also, the NOTIFY parameter, described in [RFC5201], has 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 + + During the establishment and update of an ESP SA, the SPI value of + both hosts must be transmitted between the hosts. 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 value field 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 case + of multihomed HIP hosts [RFC5206]. However, such use is beyond the + scope of this specification. + + RFC 4301 [RFC4301] describes how to establish multiple SAs to + properly support QoS. If different classes of traffic (distinguished + by Differentiated Services Code Point (DSCP) bits [RFC3474], + [RFC3260]) are sent on the same SA, and if the receiver is employing + the optional anti-replay feature available in ESP, this could result + in inappropriate discarding of lower priority packets due to the + windowing mechanism used by this feature. Therefore, 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 + permit this, the implementation MUST permit establishment and + maintenance of multiple SAs between a given sender and receiver with + the same selectors. Distribution of traffic among these parallel SAs + to support QoS is locally determined by the sender and is not + negotiated by HIP. The receiver MUST process the packets from the + + + +Jokela, et al. Experimental [Page 11] + +RFC 5202 Using the ESP Transport Format with HIP April 2008 + + + different SAs without prejudice. It is possible that the DSCP value + changes en route, but this should not cause problems with respect to + IPsec processing since the value is not employed for SA selection and + MUST NOT be checked as part of SA/packet validation. + + 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 use of a key. Rekeying ends the current SAs and + starts new ones on both peers. + + During the rekeying process, the ESP_INFO parameter is used to + transmit the changed SPI values and the keying material index. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | KEYMAT Index | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | OLD SPI | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | NEW SPI | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + 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. + + + + +Jokela, et al. Experimental [Page 12] + +RFC 5202 Using the ESP Transport Format with HIP April 2008 + + + NEW SPI new SPI for data sent to address(es) associated + with this SA. + +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 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 6 + + 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 transport + 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 + + + + + +Jokela, et al. Experimental [Page 13] + +RFC 5202 Using the ESP Transport Format with HIP April 2008 + + + 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-CBC with HMAC-SHA1 and NULL with HMAC- + SHA1. + + Under some conditions, it is possible to use Traffic Flow + Confidentiality (TFC) [RFC4303] with ESP in BEET mode. However, the + definition of such operation is future work and must be done in a + separate specification. + +5.1.3. NOTIFY Parameter + + The HIP base specification defines a set of NOTIFY error types. The + following 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 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-CBC + [RFC3602] with HMAC-SHA-1-96 [RFC2404]. + + + + + + +Jokela, et al. Experimental [Page 14] + +RFC 5202 Using the ESP Transport Format with HIP April 2008 + + + The following figure shows 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 + + 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-CBC [RFC3602] with HMAC-SHA-1-96 + [RFC2404]. + + 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_TRANSFORM, + 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. + + + + + + +Jokela, et al. Experimental [Page 15] + +RFC 5202 Using the ESP Transport Format with HIP April 2008 + + + The following figure shows the resulting R2 packet layout. + + The HIP parameters for the R2 packet: + + IP ( HIP ( ESP_INFO, HMAC_2, HIP_SIGNATURE ) ) + +5.3. HIP ESP Rekeying + + In this section, the procedure for rekeying an existing ESP SA is + presented. + + Conceptually, the process can be represented by the following message + sequence using the host names I' and R' defined in Section 3.3.2. + For simplicity, HMAC and HIP_SIGNATURE are not depicted, and + DIFFIE_HELLMAN keys are optional. The UPDATE with ACK_I need not be + piggybacked with the UPDATE with SEQ_R; it may be ACKed separately + (in which case the sequence would include four packets). + + I' R' + + UPDATE(ESP_INFO, SEQ_I, [DIFFIE_HELLMAN]) + -----------------------------------> + UPDATE(ESP_INFO, SEQ_R, ACK_I, [DIFFIE_HELLMAN]) + <----------------------------------- + UPDATE(ACK_R) + -----------------------------------> + + Below, the first two packets in this figure are explained. + +5.3.1. Initializing Rekeying + + When HIP is used with ESP, the UPDATE packet is used to initiate + rekeying. The UPDATE packet MUST carry an ESP_INFO and MAY carry a + DIFFIE_HELLMAN parameter. + + Intermediate systems that use the SPI will have to inspect HIP + packets for those that carry rekeying information. The packet is + signed for the benefit of the intermediate systems. Since + intermediate systems may need the new SPI values, the contents cannot + be encrypted. + + + + + + + + + + + +Jokela, et al. Experimental [Page 16] + +RFC 5202 Using the ESP Transport Format with HIP April 2008 + + + The following figure shows the contents of a rekeying initialization + UPDATE packet. + + The HIP parameters for the UPDATE packet initiating rekeying: + + IP ( HIP ( ESP_INFO, + SEQ, + [DIFFIE_HELLMAN, ] + HMAC, + HIP_SIGNATURE ) ) + +5.3.2. Responding to the Rekeying Initialization + + The UPDATE ACK is used to acknowledge the received UPDATE rekeying + initialization. The acknowledgment UPDATE packet MUST carry an + ESP_INFO and MAY carry a DIFFIE_HELLMAN parameter. + + Intermediate systems that use the SPI will have to inspect HIP + packets for packets carrying rekeying information. The packet is + signed for the benefit of the intermediate systems. Since + intermediate systems may need the new SPI values, the contents cannot + be encrypted. + + The following figure shows the contents of a rekeying acknowledgment + UPDATE packet. + + The HIP parameters for the UPDATE packet: + + IP ( HIP ( ESP_INFO, + SEQ, + ACK, + [ DIFFIE_HELLMAN, ] + HMAC, + HIP_SIGNATURE ) ) + +5.4. ICMP Messages + + ICMP message handling is mainly described in the HIP base + specification [RFC5201]. 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 SPI field in the ESP header. + + + + +Jokela, et al. Experimental [Page 17] + +RFC 5202 Using the ESP Transport Format with HIP April 2008 + + +6. Packet Processing + + Packet processing is mainly defined in the HIP base specification + [RFC5201]. 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 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 is an active HIP session for the given < source, destination > + HIT pair, the outgoing datagram is protected using the ESP security + association. In a typical implementation, this will result in a + BEET-mode ESP packet being sent. BEET-mode [ESP-BEET] was introduced + above in Section 3.2. 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. + +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 + + + +Jokela, et al. Experimental [Page 18] + +RFC 5202 Using the ESP Transport Format with HIP April 2008 + + + 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 [RFC5201]. + +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. + + + + +Jokela, et al. Experimental [Page 19] + +RFC 5202 Using the ESP Transport Format with HIP April 2008 + + +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 [RFC5201]). + + 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. + +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 + + + +Jokela, et al. Experimental [Page 20] + +RFC 5202 Using the ESP Transport Format with HIP April 2008 + + + 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 + [RFC5201]. 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 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. + + 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 + + + +Jokela, et al. Experimental [Page 21] + +RFC 5202 Using the ESP Transport Format with HIP April 2008 + + + 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 [RFC5201]): + + 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. + + 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 + + + + +Jokela, et al. Experimental [Page 22] + +RFC 5202 Using the ESP Transport Format with HIP April 2008 + + + 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 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 it has + 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 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. + + + +Jokela, et al. Experimental [Page 23] + +RFC 5202 Using the ESP Transport Format with HIP April 2008 + + + 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. + +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. For the mandatory algorithms, the following sizes + apply: + + AES 128 bits + + SHA-1 160 bits + + NULL 0 bits + + + + +Jokela, et al. Experimental [Page 24] + +RFC 5202 Using the ESP Transport Format with HIP April 2008 + + +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 [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: + + o Initial keying material generation + + o 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]. + + + + + + + + +Jokela, et al. Experimental [Page 25] + +RFC 5202 Using the ESP Transport Format with HIP April 2008 + + +10. 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 include Tom Henderson, + Jeff Ahrenholz, Jan Melen, Jukka Ylitalo, and Miika Komu. 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. + +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. + + + + + + + +Jokela, et al. Experimental [Page 26] + +RFC 5202 Using the ESP Transport Format with HIP April 2008 + + + [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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Jokela, et al. Experimental [Page 27] + +RFC 5202 Using the ESP Transport Format with HIP April 2008 + + +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. + + Another way to implement this specification is to use the proposed + BEET mode (A Bound End-to-End mode for ESP, [ESP-BEET]). The BEET + mode provides some features from both IPsec tunnel and transport + modes. The HIP uses HITs as the "inner" addresses and IP addresses + as "outer" addresses, like IP addresses are used in the 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). + + Compared to the option of implementing the required address rewrites + outside of IPsec, BEET has one implementation level benefit. The + BEET-way of implementing the address rewriting keeps all the + configuration information 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 + separate address rewriting DB are kept in synchrony. As a result, + the BEET-mode-based way of implementing this specification is + RECOMMENDED over the separate implementation. + + + + + + + + + + + + + +Jokela, et al. Experimental [Page 28] + +RFC 5202 Using the ESP Transport Format with HIP April 2008 + + +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.com + + + + + + + + + + + + + + + + + + + + + + + + +Jokela, et al. Experimental [Page 29] + +RFC 5202 Using the ESP Transport Format with HIP April 2008 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and 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 takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + + + + + + + + + + + +Jokela, et al. Experimental [Page 30] + |