tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7402

Proposed STD
Pages: 40
Top     in Index     Prev     Next
in Group Index     Prev in Group     No Next: Highest Number in Group     Group: HIP

Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)

Part 1 of 2, p. 1 to 20
None       Next RFC Part

Obsoletes:    5202


Top       ToC       Page 1 
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.

Top       Page 2 
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

Top      ToC       Page 3 
      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

Top      ToC       Page 4 
   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.

Top      ToC       Page 5 
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.

Top      ToC       Page 6 
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

Top      ToC       Page 7 
   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.

Top      ToC       Page 8 
   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.

Top      ToC       Page 9 
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].

Top      ToC       Page 10 
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.

Top      ToC       Page 11 
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.

Top      ToC       Page 12 
   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.

Top      ToC       Page 13 
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.

Top      ToC       Page 14 
   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.

Top      ToC       Page 15 
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]

Top      ToC       Page 16 
   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.

Top      ToC       Page 17 
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].

Top      ToC       Page 18 
   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)
            ----------------------------------->

Top      ToC       Page 19 
   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 ) )

Top      ToC       Page 20 
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.



(page 20 continued on part 2)

Next RFC Part