[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-jokela-hip-rfc5202-bis) 00 01 02 03 04 05 06 07 RFC 7402

Network Working Group                                          P. Jokela
Internet-Draft                              Ericsson Research NomadicLab
Obsoletes: 5202 (if approved)                               R. Moskowitz
Intended status: Standards Track                                 Verizon
Expires: March 9, 2015                                          J. Melen
                                            Ericsson Research NomadicLab
                                                       September 5, 2014


Using the Encapsulating Security Payload (ESP) Transport Format with the
                      Host Identity Protocol (HIP)
                     draft-ietf-hip-rfc5202-bis-07

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).  This document obsoletes RFC 5202.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on March 9, 2015.

Copyright Notice

   Copyright (c) 2014 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



Jokela, et al.            Expires March 9, 2015                 [Page 1]


Internet-Draft   Using the ESP Transport Format with HIP  September 2014


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions Used in This Document . . . . . . . . . . . . . .   4
   3.  Using ESP with HIP  . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  ESP Packet Format . . . . . . . . . . . . . . . . . . . .   5
     3.2.  Conceptual ESP Packet Processing  . . . . . . . . . . . .   5
       3.2.1.  Semantics of the Security Parameter Index (SPI) . . .   6
     3.3.  Security Association Establishment and Maintenance  . . .   6
       3.3.1.  ESP Security Associations . . . . . . . . . . . . . .   6
       3.3.2.  Rekeying  . . . . . . . . . . . . . . . . . . . . . .   7
       3.3.3.  Security Association Management . . . . . . . . . . .   8
       3.3.4.  Security Parameter Index (SPI)  . . . . . . . . . . .   8
       3.3.5.  Supported Ciphers . . . . . . . . . . . . . . . . . .   8
       3.3.6.  Sequence Number . . . . . . . . . . . . . . . . . . .   9
       3.3.7.  Lifetimes and Timers  . . . . . . . . . . . . . . . .   9
     3.4.  IPsec and HIP ESP Implementation Considerations . . . . .   9
       3.4.1.  Data Packet Processing Considerations . . . . . . . .   9
       3.4.2.  HIP Signaling Packet Considerations . . . . . . . . .  10
   4.  The Protocol  . . . . . . . . . . . . . . . . . . . . . . . .  10
     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 . . . . . . . . . . . . . . . . . . . .  14
       5.1.3.  NOTIFICATION Parameter  . . . . . . . . . . . . . . .  16
     5.2.  HIP ESP Security Association Setup  . . . . . . . . . . .  16
       5.2.1.  Setup During Base Exchange  . . . . . . . . . . . . .  16
     5.3.  HIP ESP Rekeying  . . . . . . . . . . . . . . . . . . . .  18
       5.3.1.  Initializing Rekeying . . . . . . . . . . . . . . . .  18
       5.3.2.  Responding to the Rekeying Initialization . . . . . .  19
     5.4.  ICMP Messages . . . . . . . . . . . . . . . . . . . . . .  19
       5.4.1.  Unknown SPI . . . . . . . . . . . . . . . . . . . . .  19
   6.  Packet Processing . . . . . . . . . . . . . . . . . . . . . .  20
     6.1.  Processing Outgoing Application Data  . . . . . . . . . .  20
     6.2.  Processing Incoming Application Data  . . . . . . . . . .  20
     6.3.  HMAC and SIGNATURE Calculation and Verification . . . . .  21
     6.4.  Processing Incoming ESP SA Initialization (R1)  . . . . .  21
     6.5.  Processing Incoming Initialization Reply (I2) . . . . . .  22
     6.6.  Processing Incoming ESP SA Setup Finalization (R2)  . . .  22
     6.7.  Dropping HIP Associations . . . . . . . . . . . . . . . .  22
     6.8.  Initiating ESP SA Rekeying  . . . . . . . . . . . . . . .  22



Jokela, et al.            Expires March 9, 2015                 [Page 2]


Internet-Draft   Using the ESP Transport Format with HIP  September 2014


     6.9.  Processing Incoming UPDATE Packets  . . . . . . . . . . .  24
       6.9.1.  Processing UPDATE Packet: No           Outstanding
               Rekeying Request  . . . . . . . . . . . . . . . . . .  24
     6.10. Finalizing Rekeying . . . . . . . . . . . . . . . . . . .  25
     6.11. Processing NOTIFY Packets . . . . . . . . . . . . . . . .  26
   7.  Keying Material . . . . . . . . . . . . . . . . . . . . . . .  26
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  26
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  27
   10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  28
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  28
     11.1.  Normative references . . . . . . . . . . . . . . . . . .  28
     11.2.  Informative references . . . . . . . . . . . . . . . . .  29
   Appendix A.  A Note on Implementation Options . . . . . . . . . .  31
   Appendix B.  Bound End-to-End Tunnel mode for ESP . . . . . . . .  31
     B.1.  Protocol definition . . . . . . . . . . . . . . . . . . .  32
       B.1.1.  Changes to Security Association data structures . . .  32
       B.1.2.  Packet format . . . . . . . . . . . . . . . . . . . .  32
       B.1.3.  Cryptographic processing  . . . . . . . . . . . . . .  34
       B.1.4.  IP header           processing  . . . . . . . . . . .  34
       B.1.5.  Handling of outgoing packets  . . . . . . . . . . . .  35
       B.1.6.  Handling of incoming packets  . . . . . . . . . . . .  36
       B.1.7.  IPv4 options handling . . . . . . . . . . . . . . . .  36

1.  Introduction

   In the Host Identity Protocol Architecture
   [I-D.ietf-hip-rfc4423-bis], hosts are identified with public keys.
   The Host Identity Protocol [I-D.ietf-hip-rfc5201-bis] 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 [I-D.ietf-hip-rfc5201-bis] 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




Jokela, et al.            Expires March 9, 2015                 [Page 3]


Internet-Draft   Using the ESP Transport Format with HIP  September 2014


   protected using ESP.  In addition, this document specifies methods to
   update an existing ESP Security Association.

   It should be noted that representations of Host Identity are not
   carried explicitly in the headers of user data packets.  Instead, the
   ESP Security Parameter Index (SPI) is used to indicate the right host
   context.  The SPIs are selected during the HIP ESP setup exchange.
   For user data packets, ESP SPIs (in possible combination with IP
   addresses) are used indirectly to identify the host context, thereby
   avoiding any additional explicit protocol headers.

   HIP and ESP traffic have known issues with middlebox traversal RFC
   5207 [RFC5207].  Other specifications exist for operating HIP and ESP
   over UDP (RFC 5770 [RFC5770] is an experimental specification, and
   others are being developed).  Middlebox traversal is out of scope for
   this document.

   This document obsoletes RFC 5202.

2.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

3.  Using ESP with HIP

   The HIP base exchange is used to set up a HIP association between two
   hosts.  The base exchange provides two-way host authentication and
   key material generation, but it does not provide any means for
   protecting data communication between the hosts.  In this document,
   we specify the use of ESP for protecting user data traffic after the
   HIP base exchange.  Note that this use of ESP is intended only for
   host-to-host traffic; security gateways are not supported.

   To support ESP use, the HIP base exchange messages require some minor
   additions to the parameters transported.  In the R1 packet, the
   Responder adds the possible ESP transforms in an ESP_TRANSFORM
   parameter before sending it to the Initiator.  The Initiator gets the
   proposed transforms, selects one of those proposed transforms, and
   adds it to the I2 packet in an ESP_TRANSFORM parameter.  In this I2
   packet, the Initiator also sends the SPI value that it wants to be
   used for ESP traffic flowing from the Responder to the Initiator.
   This information is carried using the ESP_INFO parameter.  When
   finalizing the ESP SA setup, the Responder sends its SPI value to the
   Initiator in the R2 packet, again using ESP_INFO.





Jokela, et al.            Expires March 9, 2015                 [Page 4]


Internet-Draft   Using the ESP Transport Format with HIP  September 2014


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 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
   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 host and doesn't require that the
   corresponding host implements it, instead the corresponding host can
   have ESP transport mode and do HIT IP conversions outside ESP.






Jokela, et al.            Expires March 9, 2015                 [Page 5]


Internet-Draft   Using the ESP Transport Format with HIP  September 2014


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 setup between the HIP nodes
   during the base exchange [I-D.ietf-hip-rfc5201-bis].  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




Jokela, et al.            Expires March 9, 2015                 [Page 6]


Internet-Draft   Using the ESP Transport Format with HIP  September 2014


   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
   [I-D.ietf-hip-rfc5201-bis].

   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 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.






Jokela, et al.            Expires March 9, 2015                 [Page 7]


Internet-Draft   Using the ESP Transport Format with HIP  September 2014


   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)
   [RFC5996].

   When a host updates the ESP SA, it provides a new inbound SPI to and
   gets a new outbound SPI from its peer.

3.3.5.  Supported Ciphers

   All HIP implementations MUST support AES-128-CBC and AES-256-CBC
   [RFC3602].  If the Initiator does not support any of the transforms
   offered by the Responder, it should abandon the negotiation and
   inform the peer with a NOTIFY message about a non-supported
   transform.

   In addition to AES-128-CBC, all implementations SHOULD implement the
   ESP NULL encryption algorithm.  When the ESP NULL encryption is used,
   it MUST be used together with SHA-256 authentication as specified in
   Section 5.1.2

   When an authentication-only suite is used (NULL, AES-CMAC-96, and
   AES-GMAC are examples), the suite MUST NOT be accepted if offered by
   the peer unless the local policy configuration regarding the peer
   host is explicitly set to allow an authentication-only mode.  This is
   to prevent sessions from being downgraded to an authentication-only
   mode when one side's policy requests privacy for the session.




Jokela, et al.            Expires March 9, 2015                 [Page 8]


Internet-Draft   Using the ESP Transport Format with HIP  September 2014


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 [I-D.ietf-hip-rfc5201-bis].

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



Jokela, et al.            Expires March 9, 2015                 [Page 9]


Internet-Draft   Using the ESP Transport Format with HIP  September 2014


   for IPsec processing are given an IPsec-enabled SA.  The SP then MUST
   be bound to the matching SA and non-HIP packets will not be processed
   by this SA.  Data originating from a socket that is not using HIP
   MUST NOT have checksum recalculated (as described in Section 3.2,
   paragraph 2) and data MUST NOT be passed to the SP or SA created by
   the HIP.

   It is possible that in case of overlapping policies, the outgoing
   packet would be handled both by the 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
   case of a Security Gateway ESP association, the ESP uses always
   tunnel mode.

   In 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 both with the HIP ESP SA and with the IPsec
   SA when the IPsec ESP SA is used in tunnel mode.

   In case of IPsec transport mode, the connection end-points 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
   case of 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 case of IPsec tunnel mode, the HIP signaling packets are always
   encrypted using IPsec ESP SA.  Note, that this hides the HIP
   signaling packets from the eventual HIP middle boxes on the path
   between the originating host and the Security Gateway.

   In 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 middle boxes to handle the passing HIP signaling
   packets.

4.  The Protocol

   In this section, the protocol for setting up an ESP association to be
   used with HIP association is described.






Jokela, et al.            Expires March 9, 2015                [Page 10]


Internet-Draft   Using the ESP Transport Format with HIP  September 2014


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
   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.

   Including the ESP_TRANSFORM parameter in the R1 message adds clarity
   to the TRANSPORT_FORMAT_LIST, but may initiate negotiations for
   possibly unselected transforms.  However, resource-constrained
   devices will most likely restrict support to a single transform for
   the sake of minimizing ROM overhead and the additional parameter adds
   negligible overhead with unconstrained devices.





Jokela, et al.            Expires March 9, 2015                [Page 11]


Internet-Draft   Using the ESP Transport Format with HIP  September 2014


   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 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
   [I-D.ietf-hip-rfc5201-bis], 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 [I-D.ietf-hip-rfc5201-bis].

   The host receiving the UPDATE message requesting update of an
   existing ESP SA MUST reply with an UPDATE message.  In the reply
   message, the host sends the ESP_INFO parameter containing the
   corresponding values: old SPI, new SPI, and the keying material
   index.  If the incoming UPDATE contained a DIFFIE_HELLMAN parameter,
   the reply packet MUST also contain a DIFFIE_HELLMAN parameter.



Jokela, et al.            Expires March 9, 2015                [Page 12]


Internet-Draft   Using the ESP Transport Format with HIP  September 2014


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 new 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
   [I-D.ietf-hip-rfc5201-bis], 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.  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.

   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.




Jokela, et al.            Expires March 9, 2015                [Page 13]


Internet-Draft   Using the ESP Transport Format with HIP  September 2014


   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.

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.









Jokela, et al.            Expires March 9, 2015                [Page 14]


Internet-Draft   Using the ESP Transport Format with HIP  September 2014


       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
            AES-128-CBC with HMAC-SHA1        1   [RFC3602], [RFC2404]
            DEPRECATED                        2
            DEPRECATED                        3
            DEPRECATED                        4
            DEPRECATED                        5
            DEPRECATED                        6
            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 a 8 octet ICV        12  [RFC4106]
            AES-GCM with a 16 octet ICV       13  [RFC4106]
            AES-CMAC-96                       14  [RFC4493], [RFC4494]
            AES-GMAC                          15  [RFC4543]

   The sender of an ESP transform parameter MUST make sure that there
   are no more than six (6) Suite IDs in one ESP transform parameter.
   Conversely, a recipient MUST be prepared to handle received transform
   parameters that contain more than six Suite IDs.  The limited number
   of Suite IDs sets the maximum size of the ESP_TRANSFORM parameter.
   As the default configuration, the ESP_TRANSFORM parameter MUST
   contain at least one of the mandatory Suite IDs.  There MAY be a
   configuration option that allows the administrator to override this
   default.



Jokela, et al.            Expires March 9, 2015                [Page 15]


Internet-Draft   Using the ESP Transport Format with HIP  September 2014


   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 operation is future work and must be done in a
   separate specification.

5.1.3.  NOTIFICATION Parameter

   The HIP base specification defines a set of NOTIFICATION error types.
   The following error types are required for describing errors in ESP
   Transform crypto suites during negotiation.

         NOTIFICATION PARAMETER - ERROR TYPES     Value
         ------------------------------------     -----

         NO_ESP_PROPOSAL_CHOSEN                    18

            None of the proposed ESP Transform crypto suites was
            acceptable.

         INVALID_ESP_TRANSFORM_CHOSEN              19

            The ESP Transform crypto suite does not correspond to
            one offered by the Responder.


5.2.  HIP ESP Security Association Setup

   The ESP Security Association is set up during the base exchange.  The
   following subsections define the ESP SA setup procedure using both
   base exchange messages (R1, I2, R2) and UPDATE messages.

5.2.1.  Setup During Base Exchange

5.2.1.1.  Modifications in R1

   The ESP_TRANSFORM contains the ESP modes supported by the sender, in
   the order of preference.  All implementations MUST support AES-
   128-CBC [RFC3602] with HMAC-SHA-256 [RFC4868].

   The following figure shows the resulting R1 packet layout.








Jokela, et al.            Expires March 9, 2015                [Page 16]


Internet-Draft   Using the ESP Transport Format with HIP  September 2014


      The HIP parameters for the R1 packet:

      IP ( HIP ( [ R1_COUNTER, ]
                 PUZZLE,
                 DIFFIE_HELLMAN,
                 HIP_CIPHER,
                 ESP_TRANSFORM,
                 HOST_ID,
                 [ ECHO_REQUEST, ]
                 HIP_SIGNATURE_2 )
                 [, ECHO_REQUEST ])

5.2.1.2.  Modifications in I2

   The ESP_INFO contains the sender's SPI for this association as well
   as the KEYMAT index from where the ESP SA keys will be drawn.  The
   old SPI value is set to zero.

   The ESP_TRANSFORM contains the ESP mode selected by the sender of R1.
   All implementations MUST support AES-128-CBC [RFC3602] with HMAC-
   SHA-256 [RFC4868].

   The following figure shows the resulting I2 packet layout.

      The HIP parameters for the I2 packet:

      IP ( HIP ( ESP_INFO,
                 [R1_COUNTER,]
                 SOLUTION,
                 DIFFIE_HELLMAN,
                 HIP_CIPHER,
                 ESP_TRANSFORM,
                 ENCRYPTED { HOST_ID },
                 [ ECHO_RESPONSE ,]
                 HMAC,
                 HIP_SIGNATURE
                 [, ECHO_RESPONSE] ) )

5.2.1.3.  Modifications in R2

   The R2 contains an ESP_INFO parameter, which has the SPI value of the
   sender of the R2 for this association.  The ESP_INFO also has the
   KEYMAT index value specifying where the ESP SA keys are drawn.

   The following figure shows the resulting R2 packet layout.






Jokela, et al.            Expires March 9, 2015                [Page 17]


Internet-Draft   Using the ESP Transport Format with HIP  September 2014


      The HIP parameters for the R2 packet:

      IP ( HIP ( ESP_INFO, HMAC_2, HIP_SIGNATURE ) )

5.3.  HIP ESP Rekeying

   In this section, the procedure for rekeying an existing ESP SA is
   presented.

   Conceptually, the process can be represented by the following message
   sequence using the host names I' and R' defined in Section 3.3.2.
   For simplicity, HMAC and HIP_SIGNATURE are not depicted, and
   DIFFIE_HELLMAN keys are optional.  The UPDATE with ACK_I need not be
   piggybacked with the UPDATE with SEQ_R; it may be ACKed separately
   (in which case the sequence would include four packets).

           I'                                  R'

                 UPDATE(ESP_INFO, SEQ_I, [DIFFIE_HELLMAN])
            ----------------------------------->
                 UPDATE(ESP_INFO, SEQ_R, ACK_I, [DIFFIE_HELLMAN])
            <-----------------------------------
                 UPDATE(ACK_R)
            ----------------------------------->

   Below, the first two packets in this figure are explained.

5.3.1.  Initializing Rekeying

   When HIP is used with ESP, the UPDATE packet is used to initiate
   rekeying.  The UPDATE packet MUST carry an ESP_INFO and MAY carry a
   DIFFIE_HELLMAN parameter.

   Intermediate systems that use the SPI will have to inspect HIP
   packets for those that carry rekeying information.  The packet is
   signed for the benefit of the intermediate systems.  Since
   intermediate systems may need the new SPI values, the contents cannot
   be encrypted.

   The following figure shows the contents of a rekeying initialization
   UPDATE packet.










Jokela, et al.            Expires March 9, 2015                [Page 18]


Internet-Draft   Using the ESP Transport Format with HIP  September 2014


      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 [I-D.ietf-hip-rfc5201-bis].  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.            Expires March 9, 2015                [Page 19]


Internet-Draft   Using the ESP Transport Format with HIP  September 2014


6.  Packet Processing

   Packet processing is mainly defined in the HIP base specification
   [I-D.ietf-hip-rfc5201-bis].  This section describes the changes and
   new requirements for packet handling when the ESP transport format is
   used.  Note that all HIP packets (currently protocol 139) MUST bypass
   ESP processing.

6.1.  Processing Outgoing Application Data

   Outgoing application data handling is specified in the HIP base
   specification [I-D.ietf-hip-rfc5201-bis].  When the ESP transport
   format is used, and there is an active HIP session for the given <
   source, destination > HIT pair, the outgoing datagram is protected
   using the ESP security association.  The following additional steps
   define the conceptual processing rules for outgoing ESP protected
   datagrams.

   1.  Detect the proper ESP SA using the HITs in the packet header or
       other information associated with the packet

   2.  Process the packet normally, as if the SA was a transport mode
       SA.

   3.  Ensure that the outgoing ESP protected packet has proper IP
       header format depending on the used IP address family, and proper
       IP addresses in its IP header, e.g., by replacing HITs left by
       the ESP processing.  Note that this placement of proper IP
       addresses MAY also be performed at some other point in the stack,
       e.g., before ESP processing.

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.            Expires March 9, 2015                [Page 20]


Internet-Draft   Using the ESP Transport Format with HIP  September 2014


       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 [I-D.ietf-hip-rfc5201-bis].

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.            Expires March 9, 2015                [Page 21]


Internet-Draft   Using the ESP Transport Format with HIP  September 2014


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 [I-D.ietf-hip-rfc5201-bis]).

   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.            Expires March 9, 2015                [Page 22]


Internet-Draft   Using the ESP Transport Format with HIP  September 2014


   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
   [I-D.ietf-hip-rfc5201-bis].  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.            Expires March 9, 2015                [Page 23]


Internet-Draft   Using the ESP Transport Format with HIP  September 2014


       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
   [I-D.ietf-hip-rfc5201-bis]):

   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.            Expires March 9, 2015                [Page 24]


Internet-Draft   Using the ESP Transport Format with HIP  September 2014


       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.            Expires March 9, 2015                [Page 25]


Internet-Draft   Using the ESP Transport Format with HIP  September 2014


       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, as specified in Section 6.5 of
   [I-D.ietf-hip-rfc5201-bis].

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.




Jokela, et al.            Expires March 9, 2015                [Page 26]


Internet-Draft   Using the ESP Transport Format with HIP  September 2014


   There are different ways to establish an ESP Security Association
   between two nodes.  This can be done, e.g., using IKE [RFC5996].
   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 [I-D.ietf-hip-rfc5201-bis] 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

   The following changes to the "Host Identity Protocol (HIP)
   Parameters" registries are requested.  In all cases, the changes
   required are to update the reference from [RFC5202] to this
   specification.

   This document defines two Parameter Types and two NOTIFY Message
   Types for the Host Identity Protocol [I-D.ietf-hip-rfc5201-bis].

   The 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 created by [I-D.ietf-hip-rfc5201-bis].  No new action
   regarding these values are required by this specification, other than
   updating the reference from [RFC5202] to this specification.

   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 created by [I-D.ietf-hip-rfc5201-bis].  No new action
   regarding these values are required by this specification, other than
   updating the reference from [RFC5202] to this specification.





Jokela, et al.            Expires March 9, 2015                [Page 27]


Internet-Draft   Using the ESP Transport Format with HIP  September 2014


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.
   Especially, the authors want to thank Pekka Nikander for his
   invaluable contributions to the document since the first draft
   version.  The authors want to thank also 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

   [I-D.ietf-hip-rfc5201-bis]
              Moskowitz, R., Heer, T., Jokela, P., and T. Henderson,
              "Host Identity Protocol Version 2 (HIPv2)", draft-ietf-
              hip-rfc5201-bis-14 (work in progress), October 2013.

   [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.

   [RFC2410]  Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
              Its Use With IPsec", RFC 2410, November 1998.

   [RFC3602]  Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
              Algorithm and Its Use with IPsec", RFC 3602, September
              2003.

   [RFC4106]  Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
              (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC
              4106, June 2005.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
              4303, December 2005.




Jokela, et al.            Expires March 9, 2015                [Page 28]


Internet-Draft   Using the ESP Transport Format with HIP  September 2014


   [RFC4309]  Housley, R., "Using Advanced Encryption Standard (AES) CCM
              Mode with IPsec Encapsulating Security Payload (ESP)", RFC
              4309, December 2005.

   [RFC4493]  Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The
              AES-CMAC Algorithm", RFC 4493, June 2006.

   [RFC4494]  Song, JH., Poovendran, R., and J. Lee, "The AES-CMAC-96
              Algorithm and Its Use with IPsec", RFC 4494, June 2006.

   [RFC4543]  McGrew, D. and J. Viega, "The Use of Galois Message
              Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543,
              May 2006.

   [RFC4868]  Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
              384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007.

11.2.  Informative references

   [I-D.ietf-hip-rfc4423-bis]
              Moskowitz, R. and M. Komu, "Host Identity Protocol
              Architecture", draft-ietf-hip-rfc4423-bis-08 (work in
              progress), April 2014.

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
              1981.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [RFC5202]  Jokela, P., Moskowitz, R., and P. Nikander, "Using the
              Encapsulating Security Payload (ESP) Transport Format with
              the Host Identity Protocol (HIP)", RFC 5202, April 2008.

   [RFC5206]  Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End-
              Host Mobility and Multihoming with the Host Identity
              Protocol", RFC 5206, April 2008.

   [RFC5207]  Stiemerling, M., Quittek, J., and L. Eggert, "NAT and
              Firewall Traversal Issues of Host Identity Protocol (HIP)
              Communication", RFC 5207, April 2008.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.






Jokela, et al.            Expires March 9, 2015                [Page 29]


Internet-Draft   Using the ESP Transport Format with HIP  September 2014


   [RFC5770]  Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A.
              Keranen, "Basic Host Identity Protocol (HIP) Extensions
              for Traversal of Network Address Translators", RFC 5770,
              April 2010.

   [RFC5996]  Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
              "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC
              5996, September 2010.











































Jokela, et al.            Expires March 9, 2015                [Page 30]


Internet-Draft   Using the ESP Transport Format with HIP  September 2014


Appendix A.  A Note on Implementation Options

   It is possible to implement this specification in multiple different
   ways.  As noted above, one possible way of implementing this is to
   rewrite IP headers below IPsec.  In such an implementation, IPsec is
   used as if it was processing IPv6 transport mode packets, with the
   IPv6 header containing HITs instead of IP addresses in the source and
   destination address fields.  In outgoing packets, after IPsec
   processing, the HITs are replaced with actual IP addresses, based on
   the HITs and the SPI.  In incoming packets, before IPsec processing,
   the IP addresses are replaced with HITs, based on the SPI in the
   incoming packet.  In such an implementation, all IPsec policies are
   based on HITs and the upper layers only see packets with HITs in the
   place of IP addresses.  Consequently, support of HIP does not
   conflict with other uses of IPsec as long as the SPI spaces are kept
   separate.  Appendix B describes another way to implement this
   specification.

Appendix B.  Bound End-to-End Tunnel mode for ESP

   This section introduces an alternative way of implementing the
   necessary functions for HIP ESP transport.  Compared to the option of
   implementing the required address rewrites outside of IPsec, BEET has
   one implementation level benefit.  In BEET-way of implementing, the
   address rewriting information is kept in one place, at the SAD.  On
   the other hand, when address rewriting is implemented separately, the
   implementation MUST make sure that the information in the SAD and the
   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 as it keeps the binds
   the identities, encryption and locators tightly together.  It should
   be noted that implementing BEET mode doesn't require that
   corresponding hosts implement it as the behavior is only visible
   internally in a host.

   The BEET mode is a combination of IPsec tunnel and transport modes
   and provides some of the features from both.  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).






Jokela, et al.            Expires March 9, 2015                [Page 31]


Internet-Draft   Using the ESP Transport Format with HIP  September 2014


B.1.  Protocol definition

   In this section we define the exact protocol formats and operations.

B.1.1.  Changes to Security Association data structures

   A BEET mode Security Association contains the same data as a regular
   tunnel mode Security Association, with the exception that the inner
   selectors must be single addresses and cannot be subnets.  The data
   includes the following:

      A pair of inner IP addresses.

      A pair of outer IP addresses.

      Cryptographic keys and other data as defined in RFC4301 [RFC4301]
      Section 4.4.2.

   A conforming implementation MAY store the data in a way similar to a
   regular tunnel mode Security Association.

   Note that in a conforming implementation the inner and outer
   addresses MAY belong to different address families.  All
   implementations that support both IPv4 and IPv6 SHOULD support both
   IPv4-over-IPv6 and IPv6-over-IPv4 tunneling.

B.1.2.  Packet format

   The wire packet format is identical to the ESP transport mode wire
   format as defined in [RFC4303] Section 3.1.1.  However, the resulting
   packet contains outer IP addresses instead of the inner IP addresses
   received from the upper layer.  The construction of the outer headers
   is defined in RFC4301 [RFC4301] Section 5.1.2.  The following diagram
   illustrates ESP BEET mode positioning for typical IPv4 and IPv6
   packets.


   IPv4 INNER ADDRESSES
   --------------------

         BEFORE APPLYING ESP
    ------------------------------
    | inner IP hdr  |     |      |
    |               | TCP | Data |
    ------------------------------

         AFTER APPLYING ESP, OUTER v4 ADDRESSES
    ----------------------------------------------------



Jokela, et al.            Expires March 9, 2015                [Page 32]


Internet-Draft   Using the ESP Transport Format with HIP  September 2014


    | outer IP hdr  |     |     |      |   ESP   | ESP |
    | (any options) | ESP | TCP | Data | Trailer | ICV |
    ----------------------------------------------------
                          |<---- encryption ---->|
                    |<-------- integrity ------->|

         AFTER APPLYING ESP, OUTER v6 ADDRESSES
    ------------------------------------------------------
    | outer  | new ext |     |     |      |  ESP   | ESP |
    | IP hdr | hdrs.   | ESP | TCP | Data | Trailer| ICV |
    ------------------------------------------------------
                             |<--- encryption ---->|
                       |<------- integrity ------->|

   IPv4 INNER ADDRESSES with options
   ---------------------------------

         BEFORE APPLYING ESP
    ------------------------------
    | inner IP hdr  |     |      |
    |  + options    | TCP | Data |
    ------------------------------

         AFTER APPLYING ESP, OUTER v4 ADDRESSES
    ----------------------------------------------------------
    | outer IP hdr  |     |     |     |      |   ESP   | ESP |
    | (any options) | ESP | PH  | TCP | Data | Trailer | ICV |
    ----------------------------------------------------------
                          |<------- encryption ------->|
                    |<----------- integrity ---------->|

         AFTER APPLYING ESP, OUTER v6 ADDRESSES
    ------------------------------------------------------------
    | outer  | new ext |     |     |     |      |  ESP   | ESP |
    | IP hdr | hdrs.   | ESP | PH  | TCP | Data | Trailer| ICV |
    ------------------------------------------------------------
                             |<------ encryption ------->|
                       |<---------- integrity ---------->|

                               PH    Pseudo Header for IPv4 options

   IPv6 INNER ADDRESSES
   --------------------

         BEFORE APPLYING ESP
    ------------------------------------------
    |              |  ext hdrs  |     |      |
    | inner IP hdr | if present | TCP | Data |



Jokela, et al.            Expires March 9, 2015                [Page 33]


Internet-Draft   Using the ESP Transport Format with HIP  September 2014


    ------------------------------------------

         AFTER APPLYING ESP, OUTER v6 ADDRESSES
    --------------------------------------------------------------
    | outer  | new ext |     | dest |     |      |  ESP    | ESP |
    | IP hdr | hdrs.   | ESP | opts.| TCP | Data | Trailer | ICV |
    --------------------------------------------------------------
                                    |<---- encryption ---->|
                                |<------- integrity ------>|

         AFTER APPLYING ESP, OUTER v4 ADDRESSES
    ----------------------------------------------------
    | outer  |     | dest |     |      |  ESP    | ESP |
    | IP hdr | ESP | opts.| TCP | Data | Trailer | ICV |
    ----------------------------------------------------
                   |<------- encryption -------->|
             |<----------- integrity ----------->|

B.1.3.  Cryptographic processing

   The outgoing packets MUST be protected exactly as in ESP transport
   mode [RFC4303].  That is, the upper layer protocol packet is wrapped
   into an ESP header, encrypted, and authenticated exactly as if
   regular transport mode was used.  The resulting ESP packet is subject
   to IP header processing as defined in Appendix B.1.4 and
   Appendix B.1.5.  The incoming ESP protected messages are verified and
   decrypted exactly as if regular transport mode was used.  The
   resulting clear text packet is subject to IP header processing as
   defined in Appendix B.1.4 and Appendix B.1.6.

B.1.4.  IP header processing

   The biggest difference between the BEET mode and the other two modes
   is in IP header processing.  In the regular transport mode the IP
   header is kept intact.  In the regular tunnel mode an outer IP header
   is created on output and discarded on input.  In the BEET mode the IP
   header is replaced with another one on both input and output.

   On the BEET mode output side, the IP header processing MUST first
   ensure that the IP addresses in the original IP header contain the
   inner addresses as specified in the SA.  This MAY be ensured by
   proper policy processing, and it is possible that no checks are
   needed at the SA processing time.  Once the IP header has been
   verified to contain the right IP inner addresses, it is discarded.  A
   new IP header is created, using the discarded inner header as a hint
   for other fields but the IP addresses.  The IP addresses in the new
   header MUST be the outer tunnel addresses.




Jokela, et al.            Expires March 9, 2015                [Page 34]


Internet-Draft   Using the ESP Transport Format with HIP  September 2014


   On input side, the received IP header is simply discarded.  Since the
   packet has been decrypted and verified, no further checks are
   necessary.  A new IP header, corresponding to a tunnel mode inner
   header, is created, using the discarded outer header as a hint for
   other fields but the IP addresses.  The IP addresses in the new
   header MUST be the inner addresses.

   As the outer header fields are used as hint for creating inner
   header, it must be noted that inner header differs as compared to
   tunnel-mode inner header.  In BEET mode the inner header will have
   the TTL, DF-bit and other option values from the outer header.  The
   TTL, DF-bit and other option values of the inner header MUST be
   processed by the stack.

B.1.5.  Handling of outgoing packets

   The outgoing BEET mode packets are processed as follows:

   1.  The system MUST verify that the IP header contains the inner
       source and destination addresses, exactly as defined in the SA.
       This verification MAY be explicit, or it MAY be implicit, for
       example, as a result of prior policy processing.  Note that in
       some implementations there may be no real IP header at this time
       but the source and destination addresses may be carried out-of-
       band.  In case the source address is still unassigned, it SHOULD
       be ensured that the designated inner source address would be
       selected at a later stage.

   2.  The IP payload (the contents of the packet beyond the IP header)
       is wrapped into an ESP header as defined in [RFC4303]
       Section 3.3.

   3.  A new IP header is constructed, replacing the original one.  The
       new IP header MUST contain the outer source and destination
       addresses, as defined in the SA.  Note that in some
       implementations there may be no real IP header at this time but
       the source and destination addresses may be carried out-of-band.
       In the case where the source address must be left unassigned, it
       SHOULD be made sure that the right source address is selected at
       a later stage.  Other than the addresses, it is RECOMMENDED that
       the new IP header copies the fields from the original IP header.

   4.  If there are any IPv4 options in the original packet, it is
       RECOMMENDED that they are discarded.  If the inner header
       contains one or more options that need to be transported between
       the tunnel end-points, sender MUST encapsulate the options as
       defined in Appendix B.1.7




Jokela, et al.            Expires March 9, 2015                [Page 35]


Internet-Draft   Using the ESP Transport Format with HIP  September 2014


   Instead of literally discarding the IP header and constructing a new
   one, a conforming implementation MAY simply replace the addresses in
   an existing header.  However, if the RECOMMENDED feature of allowing
   the inner and outer addresses from different address families is
   used, this simple strategy does not work.

B.1.6.  Handling of incoming packets

   The incoming BEET mode packets are processed as follows:

   1.  The system MUST verify and decrypt the incoming packet
       successfully, as defined in [RFC4303] section 3.4.  If the
       verification or decryption fails, the packet MUST be discarded.

   2.  The original IP header is simply discarded, without any checks.
       Since the ESP verification succeeded, the packet can be safely
       assumed to have arrived from the right sender.

   3.  A new IP header is constructed, replacing the original one.  The
       new IP header MUST contain the inner source and destination
       addresses, as defined in the SA.  If the sender has set the ESP
       next protocol field to 94 and included the pseudo header as
       described in Appendix B.1.7, the receiver MUST include the
       options after the constructed IP header.  Note, that in some
       implementations the real IP header may have already been
       discarded and the source and destination addresses are carried
       out-of-band.  In such case the out-of-band addresses MUST be the
       inner addresses.  Other than the addresses, it is RECOMMENDED
       that the new IP header copies the fields from the original IP
       header.

   Instead of literally discarding the IP header and constructing a new
   one a conforming implementation MAY simply replace the addresses in
   an existing header.  However, if the RECOMMENDED feature of allowing
   the inner and outer addresses from different address families is
   used, this simple strategy does not work.

B.1.7.  IPv4 options handling

   In BEET mode, if IPv4 options are transported inside the tunnel, the
   sender MUST include a pseudo-header after ESP header.  The pseudo-
   header identifies that IPv4 options from the original packet are to
   be applied on the packet on input side.

   The sender MUST set the next protocol field on the ESP header as 94.
   The resulting pseudo header including the IPv4 options MUST be padded
   to 8 octet boundary.  The padding length is expressed in octets,
   valid padding lengths are 0 or 4 octets as the original IPv4 options



Jokela, et al.            Expires March 9, 2015                [Page 36]


Internet-Draft   Using the ESP Transport Format with HIP  September 2014


   are already padded to 4 octet boundary.  The padding MUST be filled
   with NOP options as defined in Internet Protocol [RFC0791] section
   3.1 Internet header format.  The padding is added in front of the
   original options to ensure that the receiver is able to reconstruct
   the original IPv4 datagram.  The Header Length field contains the
   length of the IPv4 options, and padding in 8 octets units.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Header  |   Header Len  |    Pad Len    |   Reserved    |
   +---------------+---------------+-------------------------------+
   |                       Padding (if needed)                     |
   +---------------------------------------------------------------+
   |                            IPv4 options ...                   |
   |                                                               |
   +---------------------------------------------------------------+

      Next Header          Identifies the data following this header
      Length in octets     8-bit unsigned integer.  Length of the
                           pseudo header in 8-octet units, not
                           including the first 8 octets.

   The receiver MUST remove this pseudo-header and padding as a part of
   BEET processing, in order reconstruct the original IPv4 datagram.
   The IPv4 options included into the pseudo-header MUST be added after
   the reconstructed IPv4 (inner) header on the receiving side.

Authors' Addresses

   Petri Jokela
   Ericsson Research NomadicLab
   JORVAS  FIN-02420
   FINLAND

   Phone: +358 9 299 1
   EMail: petri.jokela@nomadiclab.com


   Robert Moskowitz
   Verizon Telcom and Business
   1000 Bent Creek Blvd, Suite 200
   Mechanicsburg, PA
   USA

   EMail: rgm@icsalabs.com





Jokela, et al.            Expires March 9, 2015                [Page 37]


Internet-Draft   Using the ESP Transport Format with HIP  September 2014


   Jan Melen
   Ericsson Research NomadicLab
   JORVAS  FIN-02420
   FINLAND

   Phone: +358 9 299 1
   EMail: jan.melen@nomadiclab.com












































Jokela, et al.            Expires March 9, 2015                [Page 38]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/