doc: Add RFC documents

1 files changed, 1683 insertions, 0 deletions

diff --git a/doc/rfc/rfc5202.txt b/doc/rfc/rfc5202.txt
new file mode 100644
index 0000000..b8bdbb3
--- /dev/null
+++ b/doc/rfc/rfc5202.txt
@@ -0,0 +1,1683 @@
+
+
+
+
+
+
+Network Working Group                                          P. Jokela
+Request for Comments: 5202                  Ericsson Research NomadicLab
+Category: Experimental                                      R. Moskowitz
+                                                                ICSAlabs
+                                                             P. Nikander
+                                            Ericsson Research NomadicLab
+                                                              April 2008
+
+
+Using the Encapsulating Security Payload (ESP) Transport Format with the
+                      Host Identity Protocol (HIP)
+
+Status of This Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  It does not specify an Internet standard of any kind.
+   Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+IESG Note
+
+   The following issues describe IESG concerns about this document.  The
+   IESG expects that these issues will be addressed when future versions
+   of HIP are designed.
+
+   In case of complex Security Policy Databases (SPDs) and the co-
+   existence of HIP and security-related protocols such as IKE,
+   implementors may encounter conditions that are unspecified in these
+   documents.  For example, when the SPD defines an IP address subnet to
+   be protected and a HIP host is residing in that IP address area,
+   there is a possibility that the communication is encrypted multiple
+   times.  Readers are advised to pay special attention when running HIP
+   with complex SPD settings.  Future specifications should clearly
+   define when multiple encryption is intended, and when it should be
+   avoided.
+
+Abstract
+
+   This memo specifies an Encapsulated Security Payload (ESP) based
+   mechanism for transmission of user data packets, to be used with the
+   Host Identity Protocol (HIP).
+
+
+
+
+
+
+
+
+
+
+Jokela, et al.                Experimental                      [Page 1]
+
+RFC 5202        Using the ESP Transport Format with HIP       April 2008
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
+   3.  Using ESP with HIP . . . . . . . . . . . . . . . . . . . . . .  4
+     3.1.  ESP Packet Format  . . . . . . . . . . . . . . . . . . . .  4
+     3.2.  Conceptual ESP Packet Processing . . . . . . . . . . . . .  4
+       3.2.1.  Semantics of the Security Parameter Index (SPI)  . . .  5
+     3.3.  Security Association Establishment and Maintenance . . . .  6
+       3.3.1.  ESP Security Associations  . . . . . . . . . . . . . .  6
+       3.3.2.  Rekeying . . . . . . . . . . . . . . . . . . . . . . .  6
+       3.3.3.  Security Association Management  . . . . . . . . . . .  7
+       3.3.4.  Security Parameter Index (SPI) . . . . . . . . . . . .  7
+       3.3.5.  Supported Transforms . . . . . . . . . . . . . . . . .  7
+       3.3.6.  Sequence Number  . . . . . . . . . . . . . . . . . . .  8
+       3.3.7.  Lifetimes and Timers . . . . . . . . . . . . . . . . .  8
+     3.4.  IPsec and HIP ESP Implementation Considerations  . . . . .  8
+   4.  The Protocol  . . . . . . . . . . . . . . . . . . . . . . . . . 9
+     4.1.  ESP in HIP  . . . . . . . . . . . . . . . . . . . . . . . . 9
+       4.1.1.  Setting Up an ESP Security Association  . . . . . . . . 9
+       4.1.2.  Updating an Existing ESP SA  . . . . . . . . . . . . . 10
+   5.  Parameter and Packet Formats . . . . . . . . . . . . . . . . . 10
+     5.1.  New Parameters . . . . . . . . . . . . . . . . . . . . . . 11
+       5.1.1.  ESP_INFO . . . . . . . . . . . . . . . . . . . . . . . 11
+       5.1.2.  ESP_TRANSFORM  . . . . . . . . . . . . . . . . . . . . 13
+       5.1.3.  NOTIFY Parameter . . . . . . . . . . . . . . . . . . . 14
+     5.2.  HIP ESP Security Association Setup . . . . . . . . . . . . 14
+       5.2.1.  Setup During Base Exchange . . . . . . . . . . . . . . 14
+     5.3.  HIP ESP Rekeying . . . . . . . . . . . . . . . . . . . . . 16
+       5.3.1.  Initializing Rekeying  . . . . . . . . . . . . . . . . 16
+       5.3.2.  Responding to the Rekeying Initialization  . . . . . . 17
+     5.4.  ICMP Messages  . . . . . . . . . . . . . . . . . . . . . . 17
+       5.4.1.  Unknown SPI  . . . . . . . . . . . . . . . . . . . . . 17
+   6.  Packet Processing  . . . . . . . . . . . . . . . . . . . . . . 18
+     6.1.  Processing Outgoing Application Data . . . . . . . . . . . 18
+     6.2.  Processing Incoming Application Data . . . . . . . . . . . 19
+     6.3.  HMAC and SIGNATURE Calculation and Verification  . . . . . 19
+     6.4.  Processing Incoming ESP SA Initialization (R1) . . . . . . 19
+     6.5.  Processing Incoming Initialization Reply (I2)  . . . . . . 20
+     6.6.  Processing Incoming ESP SA Setup Finalization (R2) . . . . 20
+     6.7.  Dropping HIP Associations  . . . . . . . . . . . . . . . . 20
+     6.8.  Initiating ESP SA Rekeying . . . . . . . . . . . . . . . . 20
+     6.9.  Processing Incoming UPDATE Packets . . . . . . . . . . . . 22
+       6.9.1.  Processing UPDATE Packet: No Outstanding Rekeying
+               Request  . . . . . . . . . . . . . . . . . . . . . . . 22
+     6.10. Finalizing Rekeying  . . . . . . . . . . . . . . . . . . . 23
+     6.11. Processing NOTIFY Packets  . . . . . . . . . . . . . . . . 24
+   7.  Keying Material  . . . . . . . . . . . . . . . . . . . . . . . 24
+
+
+
+Jokela, et al.                Experimental                      [Page 2]
+
+RFC 5202        Using the ESP Transport Format with HIP       April 2008
+
+
+   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 25
+   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 25
+   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 26
+   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
+     11.1. Normative references . . . . . . . . . . . . . . . . . . . 26
+     11.2. Informative references . . . . . . . . . . . . . . . . . . 26
+   Appendix A.  A Note on Implementation Options  . . . . . . . . . . 28
+
+1.  Introduction
+
+   In the Host Identity Protocol Architecture [RFC4423], hosts are
+   identified with public keys.  The Host Identity Protocol [RFC5201]
+   base exchange allows any two HIP-supporting hosts to authenticate
+   each other and to create a HIP association between themselves.
+   During the base exchange, the hosts generate a piece of shared keying
+   material using an authenticated Diffie-Hellman exchange.
+
+   The HIP base exchange specification [RFC5201] does not describe any
+   transport formats or methods for user data to be used during the
+   actual communication; it only defines that it is mandatory to
+   implement the Encapsulated Security Payload (ESP) [RFC4303] based
+   transport format and method.  This document specifies how ESP is used
+   with HIP to carry actual user data.
+
+   To be more specific, this document specifies a set of HIP protocol
+   extensions and their handling.  Using these extensions, a pair of ESP
+   Security Associations (SAs) is created between the hosts during the
+   base exchange.  The resulting ESP Security Associations use keys
+   drawn from the keying material (KEYMAT) generated during the base
+   exchange.  After the HIP association and required ESP SAs have been
+   established between the hosts, the user data communication is
+   protected using ESP.  In addition, this document specifies methods to
+   update an existing ESP Security Association.
+
+   It should be noted that representations of Host Identity are not
+   carried explicitly in the headers of user data packets.  Instead, the
+   ESP Security Parameter Index (SPI) is used to indicate the right host
+   context.  The SPIs are selected during the HIP ESP setup exchange.
+   For user data packets, ESP SPIs (in possible combination with IP
+   addresses) are used indirectly to identify the host context, thereby
+   avoiding any additional explicit protocol headers.
+
+2.  Conventions Used in This Document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+
+
+
+Jokela, et al.                Experimental                      [Page 3]
+
+RFC 5202        Using the ESP Transport Format with HIP       April 2008
+
+
+3.  Using ESP with HIP
+
+   The HIP base exchange is used to set up a HIP association between two
+   hosts.  The base exchange provides two-way host authentication and
+   key material generation, but it does not provide any means for
+   protecting data communication between the hosts.  In this document,
+   we specify the use of ESP for protecting user data traffic after the
+   HIP base exchange.  Note that this use of ESP is intended only for
+   host-to-host traffic; security gateways are not supported.
+
+   To support ESP use, the HIP base exchange messages require some minor
+   additions to the parameters transported.  In the R1 packet, the
+   Responder adds the possible ESP transforms in a new ESP_TRANSFORM
+   parameter before sending it to the Initiator.  The Initiator gets the
+   proposed transforms, selects one of those proposed transforms, and
+   adds it to the I2 packet in an ESP_TRANSFORM parameter.  In this I2
+   packet, the Initiator also sends the SPI value that it wants to be
+   used for ESP traffic flowing from the Responder to the Initiator.
+   This information is carried using the new ESP_INFO parameter.  When
+   finalizing the ESP SA setup, the Responder sends its SPI value to the
+   Initiator in the R2 packet, again using ESP_INFO.
+
+3.1.  ESP Packet Format
+
+   The ESP specification [RFC4303] defines the ESP packet format for
+   IPsec.  The HIP ESP packet looks exactly the same as the IPsec ESP
+   transport format packet.  The semantics, however, are a bit different
+   and are described in more detail in the next subsection.
+
+3.2.  Conceptual ESP Packet Processing
+
+   ESP packet processing can be implemented in different ways in HIP.
+   It is possible to implement it in a way that a standards compliant,
+   unmodified IPsec implementation [RFC4303] can be used.
+
+   When a standards compliant IPsec implementation that uses IP
+   addresses in the SPD and Security Association Database (SAD) is used,
+   the packet processing may take the following steps.  For outgoing
+   packets, assuming that the upper-layer pseudoheader has been built
+   using IP addresses, the implementation recalculates upper-layer
+   checksums using Host Identity Tags (HITs) and, after that, changes
+   the packet source and destination addresses back to corresponding IP
+   addresses.  The packet is sent to the IPsec ESP for transport mode
+   handling and from there the encrypted packet is sent to the network.
+   When an ESP packet is received, the packet is first put to the IPsec
+   ESP transport mode handling, and after decryption, the source and
+
+
+
+
+
+Jokela, et al.                Experimental                      [Page 4]
+
+RFC 5202        Using the ESP Transport Format with HIP       April 2008
+
+
+   destination IP addresses are replaced with HITs and finally, upper-
+   layer checksums are verified before passing the packet to the upper
+   layer.
+
+   An alternative way to implement packet processing is the BEET (Bound
+   End-to-End Tunnel) [ESP-BEET] mode.  In BEET mode, the ESP packet is
+   formatted as a transport mode packet, but the semantics of the
+   connection are the same as for tunnel mode.  The "outer" addresses of
+   the packet are the IP addresses and the "inner" addresses are the
+   HITs.  For outgoing traffic, after the packet has been encrypted, the
+   packet's IP header is changed to a new one that contains IP addresses
+   instead of HITs, and the packet is sent to the network.  When the ESP
+   packet is received, the SPI value, together with the integrity
+   protection, allow the packet to be securely associated with the right
+   HIT pair.  The packet header is replaced with a new header containing
+   HITs, and the packet is decrypted.
+
+3.2.1.  Semantics of the Security Parameter Index (SPI)
+
+   SPIs are used in ESP to find the right Security Association for
+   received packets.  The ESP SPIs have added significance when used
+   with HIP; they are a compressed representation of a pair of HITs.
+   Thus, SPIs MAY be used by intermediary systems in providing services
+   like address mapping.  Note that since the SPI has significance at
+   the receiver, only the < DST, SPI >, where DST is a destination IP
+   address, uniquely identifies the receiver HIT at any given point of
+   time.  The same SPI value may be used by several hosts.  A single
+   < DST, SPI > value may denote different hosts and contexts at
+   different points of time, depending on the host that is currently
+   reachable at the DST.
+
+   Each host selects for itself the SPI it wants to see in packets
+   received from its peer.  This allows it to select different SPIs for
+   different peers.  The SPI selection SHOULD be random; the rules of
+   Section 2.1 of the ESP specification [RFC4303] must be followed.  A
+   different SPI SHOULD be used for each HIP exchange with a particular
+   host; this is to avoid a replay attack.  Additionally, when a host
+   rekeys, the SPI MUST be changed.  Furthermore, if a host changes over
+   to use a different IP address, it MAY change the SPI.
+
+   One method for SPI creation that meets the above criteria would be to
+   concatenate the HIT with a 32-bit random or sequential number, hash
+   this (using SHA1), and then use the high-order 32 bits as the SPI.
+
+   The selected SPI is communicated to the peer in the third (I2) and
+   fourth (R2) packets of the base HIP exchange.  Changes in SPI are
+   signaled with ESP_INFO parameters.
+
+
+
+
+Jokela, et al.                Experimental                      [Page 5]
+
+RFC 5202        Using the ESP Transport Format with HIP       April 2008
+
+
+3.3.  Security Association Establishment and Maintenance
+
+3.3.1.  ESP Security Associations
+
+   In HIP, ESP Security Associations are setup between the HIP nodes
+   during the base exchange [RFC5201].  Existing ESP SAs can be updated
+   later using UPDATE messages.  The reason for updating the ESP SA
+   later can be, for example, a need for rekeying the SA because of
+   sequence number rollover.
+
+   Upon setting up a HIP association, each association is linked to two
+   ESP SAs, one for incoming packets and one for outgoing packets.  The
+   Initiator's incoming SA corresponds with the Responder's outgoing
+   one, and vice versa.  The Initiator defines the SPI for its incoming
+   association, as defined in Section 3.2.1.  This SA is herein called
+   SA-RI, and the corresponding SPI is called SPI-RI.  Respectively, the
+   Responder's incoming SA corresponds with the Initiator's outgoing SA
+   and is called SA-IR, with the SPI being called SPI-IR.
+
+   The Initiator creates SA-RI as a part of R1 processing, before
+   sending out the I2, as explained in Section 6.4.  The keys are
+   derived from KEYMAT, as defined in Section 7.  The Responder creates
+   SA-RI as a part of I2 processing; see Section 6.5.
+
+   The Responder creates SA-IR as a part of I2 processing, before
+   sending out R2; see Section 6.5.  The Initiator creates SA-IR when
+   processing R2; see Section 6.6.
+
+   The initial session keys are drawn from the generated keying
+   material, KEYMAT, after the HIP keys have been drawn as specified in
+   [RFC5201].
+
+   When the HIP association is removed, the related ESP SAs MUST also be
+   removed.
+
+3.3.2.  Rekeying
+
+   After the initial HIP base exchange and SA establishment, both hosts
+   are in the ESTABLISHED state.  There are no longer Initiator and
+   Responder roles and the association is symmetric.  In this
+   subsection, the party that initiates the rekey procedure is denoted
+   with I' and the peer with R'.
+
+   An existing HIP-created ESP SA may need updating during the lifetime
+   of the HIP association.  This document specifies the rekeying of an
+   existing HIP-created ESP SA, using the UPDATE message.  The ESP_INFO
+   parameter introduced above is used for this purpose.
+
+
+
+
+Jokela, et al.                Experimental                      [Page 6]
+
+RFC 5202        Using the ESP Transport Format with HIP       April 2008
+
+
+   I' initiates the ESP SA updating process when needed (see
+   Section 6.8).  It creates an UPDATE packet with required information
+   and sends it to the peer node.  The old SAs are still in use, local
+   policy permitting.
+
+   R', after receiving and processing the UPDATE (see Section 6.9),
+   generates new SAs: SA-I'R' and SA-R'I'.  It does not take the new
+   outgoing SA into use, but still uses the old one, so there
+   temporarily exists two SA pairs towards the same peer host.  The SPI
+   for the new outgoing SA, SPI-R'I', is specified in the received
+   ESP_INFO parameter in the UPDATE packet.  For the new incoming SA, R'
+   generates the new SPI value, SPI-I'R', and includes it in the
+   response UPDATE packet.
+
+   When I' receives a response UPDATE from R', it generates new SAs, as
+   described in Section 6.9: SA-I'R' and SA-R'I'.  It starts using the
+   new outgoing SA immediately.
+
+   R' starts using the new outgoing SA when it receives traffic on the
+   new incoming SA or when it receives the UPDATE ACK confirming
+   completion of rekeying.  After this, R' can remove the old SAs.
+   Similarly, when the I' receives traffic from the new incoming SA, it
+   can safely remove the old SAs.
+
+3.3.3.  Security Association Management
+
+   An SA pair is indexed by the 2 SPIs and 2 HITs (both local and remote
+   HITs since a system can have more than one HIT).  An inactivity timer
+   is RECOMMENDED for all SAs.  If the state dictates the deletion of an
+   SA, a timer is set to allow for any late arriving packets.
+
+3.3.4.  Security Parameter Index (SPI)
+
+   The SPIs in ESP provide a simple compression of the HIP data from all
+   packets after the HIP exchange.  This does require a per HIT-pair
+   Security Association (and SPI), and a decrease of policy granularity
+   over other Key Management Protocols like IKE.
+
+   When a host updates the ESP SA, it provides a new inbound SPI to and
+   gets a new outbound SPI from its partner.
+
+3.3.5.  Supported Transforms
+
+   All HIP implementations MUST support AES-CBC [RFC3602] and HMAC-SHA-
+   1-96 [RFC2404].  If the Initiator does not support any of the
+   transforms offered by the Responder, it should abandon the
+   negotiation and inform the peer with a NOTIFY message about a non-
+   supported transform.
+
+
+
+Jokela, et al.                Experimental                      [Page 7]
+
+RFC 5202        Using the ESP Transport Format with HIP       April 2008
+
+
+   In addition to AES-CBC, all implementations MUST implement the ESP
+   NULL encryption algorithm.  When the ESP NULL encryption is used, it
+   MUST be used together with SHA1 or MD5 authentication as specified in
+   Section 5.1.2
+
+3.3.6.  Sequence Number
+
+   The Sequence Number field is MANDATORY when ESP is used with HIP.
+   Anti-replay protection MUST be used in an ESP SA established with
+   HIP.  When ESP is used with HIP, a 64-bit sequence number MUST be
+   used.  This means that each host MUST rekey before its sequence
+   number reaches 2^64.
+
+   When using a 64-bit sequence number, the higher 32 bits are NOT
+   included in the ESP header, but are simply kept local to both peers.
+   See [RFC4301].
+
+3.3.7.  Lifetimes and Timers
+
+   HIP does not negotiate any lifetimes.  All ESP lifetimes are local
+   policy.  The only lifetimes a HIP implementation MUST support are
+   sequence number rollover (for replay protection), and SHOULD support
+   timing out inactive ESP SAs.  An SA times out if no packets are
+   received using that SA.  The default timeout value is 15 minutes.
+   Implementations MAY support lifetimes for the various ESP transforms.
+   Each implementation SHOULD implement per-HIT configuration of the
+   inactivity timeout, allowing statically configured HIP associations
+   to stay alive for days, even when inactive.
+
+3.4.  IPsec and HIP ESP Implementation Considerations
+
+   When HIP is run on a node where a standards compliant IPsec is used,
+   some issues have to be considered.
+
+   The HIP implementation must be able to co-exist with other IPsec
+   keying protocols.  When the HIP implementation selects the SPI value,
+   it may lead to a collision if not implemented properly.  To avoid the
+   possibility for a collision, the HIP implementation MUST ensure that
+   the SPI values used for HIP SAs are not used for IPsec or other SAs,
+   and vice versa.
+
+   For outbound traffic, the SPD or (coordinated) SPDs if there are two
+   (one for HIP and one for IPsec) MUST ensure that packets intended for
+   HIP processing are given a HIP-enabled SA and that packets intended
+   for IPsec processing are given an IPsec-enabled SA.  The SP then MUST
+   be bound to the matching SA and non-HIP packets will not be processed
+   by this SA.  Data originating from a socket that is not using HIP
+   MUST NOT have checksum recalculated (as described in Section 3.2,
+
+
+
+Jokela, et al.                Experimental                      [Page 8]
+
+RFC 5202        Using the ESP Transport Format with HIP       April 2008
+
+
+   paragraph 2) and data MUST NOT be passed to the SP or SA created by
+   the HIP.
+
+   Incoming data packets using an SA that is not negotiated by HIP MUST
+   NOT be processed as described in Section 3.2, paragraph 2.  The SPI
+   will identify the correct SA for packet decryption and MUST be used
+   to identify that the packet has an upper-layer checksum that is
+   calculated as specified in [RFC5201].
+
+4.  The Protocol
+
+   In this section, the protocol for setting up an ESP association to be
+   used with HIP association is described.
+
+4.1.  ESP in HIP
+
+4.1.1.  Setting Up an ESP Security Association
+
+   Setting up an ESP Security Association between hosts using HIP
+   consists of three messages passed between the hosts.  The parameters
+   are included in R1, I2, and R2 messages during base exchange.
+
+                 Initiator                             Responder
+
+                                   I1
+                   ---------------------------------->
+
+                             R1: ESP_TRANSFORM
+                   <----------------------------------
+
+                       I2: ESP_TRANSFORM, ESP_INFO
+                   ---------------------------------->
+
+                               R2: ESP_INFO
+                   <----------------------------------
+
+   Setting up an ESP Security Association between HIP hosts requires
+   three messages to exchange the information that is required during an
+   ESP communication.
+
+   The R1 message contains the ESP_TRANSFORM parameter, in which the
+   sending host defines the possible ESP transforms it is willing to use
+   for the ESP SA.
+
+   The I2 message contains the response to an ESP_TRANSFORM received in
+   the R1 message.  The sender must select one of the proposed ESP
+   transforms from the ESP_TRANSFORM parameter in the R1 message and
+   include the selected one in the ESP_TRANSFORM parameter in the I2
+
+
+
+Jokela, et al.                Experimental                      [Page 9]
+
+RFC 5202        Using the ESP Transport Format with HIP       April 2008
+
+
+   packet.  In addition to the transform, the host includes the ESP_INFO
+   parameter containing the SPI value to be used by the peer host.
+
+   In the R2 message, the ESP SA setup is finalized.  The packet
+   contains the SPI information required by the Initiator for the ESP
+   SA.
+
+4.1.2.  Updating an Existing ESP SA
+
+   The update process is accomplished using two messages.  The HIP
+   UPDATE message is used to update the parameters of an existing ESP
+   SA.  The UPDATE mechanism and message is defined in [RFC5201], and
+   the additional parameters for updating an existing ESP SA are
+   described here.
+
+   The following picture shows a typical exchange when an existing ESP
+   SA is updated.  Messages include SEQ and ACK parameters required by
+   the UPDATE mechanism.
+
+       H1                                                          H2
+            UPDATE: SEQ, ESP_INFO [, DIFFIE_HELLMAN]
+          ----------------------------------------------------->
+
+            UPDATE: SEQ, ACK, ESP_INFO [, DIFFIE_HELLMAN]
+          <-----------------------------------------------------
+
+            UPDATE: ACK
+          ----------------------------------------------------->
+
+   The host willing to update the ESP SA creates and sends an UPDATE
+   message.  The message contains the ESP_INFO parameter containing the
+   old SPI value that was used, the new SPI value to be used, and the
+   index value for the keying material, giving the point from where the
+   next keys will be drawn.  If new keying material must be generated,
+   the UPDATE message will also contain the DIFFIE_HELLMAN parameter
+   defined in [RFC5201].
+
+   The host receiving the UPDATE message requesting update of an
+   existing ESP SA MUST reply with an UPDATE message.  In the reply
+   message, the host sends the ESP_INFO parameter containing the
+   corresponding values: old SPI, new SPI, and the keying material
+   index.  If the incoming UPDATE contained a DIFFIE_HELLMAN parameter,
+   the reply packet MUST also contain a DIFFIE_HELLMAN parameter.
+
+5.  Parameter and Packet Formats
+
+   In this section, new and modified HIP parameters are presented, as
+   well as modified HIP packets.
+
+
+
+Jokela, et al.                Experimental                     [Page 10]
+
+RFC 5202        Using the ESP Transport Format with HIP       April 2008
+
+
+5.1.  New Parameters
+
+   Two new HIP parameters are defined for setting up ESP transport
+   format associations in HIP communication and for rekeying existing
+   ones.  Also, the NOTIFY parameter, described in [RFC5201], has two
+   new error parameters.
+
+      Parameter         Type  Length     Data
+
+      ESP_INFO          65    12         Remote's old SPI,
+                                         new SPI, and other info
+      ESP_TRANSFORM     4095  variable   ESP Encryption and
+                                         Authentication Transform(s)
+
+5.1.1.  ESP_INFO
+
+   During the establishment and update of an ESP SA, the SPI value of
+   both hosts must be transmitted between the hosts.  During the
+   establishment and update of an ESP SA, the SPI value of both hosts
+   must be transmitted between the hosts.  In addition, hosts need the
+   index value to the KEYMAT when they are drawing keys from the
+   generated keying material.  The ESP_INFO parameter is used to
+   transmit the SPI values and the KEYMAT index information between the
+   hosts.
+
+   During the initial ESP SA setup, the hosts send the SPI value that
+   they want the peer to use when sending ESP data to them.  The value
+   is set in the NEW SPI field of the ESP_INFO parameter.  In the
+   initial setup, an old value for the SPI does not exist, thus the OLD
+   SPI value field is set to zero.  The OLD SPI field value may also be
+   zero when additional SAs are set up between HIP hosts, e.g., in case
+   of multihomed HIP hosts [RFC5206].  However, such use is beyond the
+   scope of this specification.
+
+   RFC 4301 [RFC4301] describes how to establish multiple SAs to
+   properly support QoS.  If different classes of traffic (distinguished
+   by Differentiated Services Code Point (DSCP) bits [RFC3474],
+   [RFC3260]) are sent on the same SA, and if the receiver is employing
+   the optional anti-replay feature available in ESP, this could result
+   in inappropriate discarding of lower priority packets due to the
+   windowing mechanism used by this feature.  Therefore, a sender SHOULD
+   put traffic of different classes but with the same selector values on
+   different SAs to support Quality of Service (QoS) appropriately.  To
+   permit this, the implementation MUST permit establishment and
+   maintenance of multiple SAs between a given sender and receiver with
+   the same selectors.  Distribution of traffic among these parallel SAs
+   to support QoS is locally determined by the sender and is not
+   negotiated by HIP.  The receiver MUST process the packets from the
+
+
+
+Jokela, et al.                Experimental                     [Page 11]
+
+RFC 5202        Using the ESP Transport Format with HIP       April 2008
+
+
+   different SAs without prejudice.  It is possible that the DSCP value
+   changes en route, but this should not cause problems with respect to
+   IPsec processing since the value is not employed for SA selection and
+   MUST NOT be checked as part of SA/packet validation.
+
+   The KEYMAT index value points to the place in the KEYMAT from where
+   the keying material for the ESP SAs is drawn.  The KEYMAT index value
+   is zero only when the ESP_INFO is sent during a rekeying process and
+   new keying material is generated.
+
+   During the life of an SA established by HIP, one of the hosts may
+   need to reset the Sequence Number to one and rekey.  The reason for
+   rekeying might be an approaching sequence number wrap in ESP, or a
+   local policy on use of a key.  Rekeying ends the current SAs and
+   starts new ones on both peers.
+
+   During the rekeying process, the ESP_INFO parameter is used to
+   transmit the changed SPI values and the keying material index.
+
+      0                   1                   2                   3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |             Type              |             Length            |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |           Reserved            |         KEYMAT Index          |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                            OLD SPI                            |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                            NEW SPI                            |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+     Type           65
+     Length         12
+     KEYMAT Index   Index, in bytes, where to continue to draw ESP keys
+                    from KEYMAT.  If the packet includes a new
+                    Diffie-Hellman key and the ESP_INFO is sent in an
+                    UPDATE packet, the field MUST be zero.  If the
+                    ESP_INFO is included in base exchange messages, the
+                    KEYMAT Index must have the index value of the point
+                    from where the ESP SA keys are drawn.  Note that the
+                    length of this field limits the amount of
+                    keying material that can be drawn from KEYMAT.  If
+                    that amount is exceeded, the packet MUST contain
+                    a new Diffie-Hellman key.
+     OLD SPI        old SPI for data sent to address(es) associated
+                    with this SA.  If this is an initial SA setup, the
+                    OLD SPI value is zero.
+
+
+
+
+Jokela, et al.                Experimental                     [Page 12]
+
+RFC 5202        Using the ESP Transport Format with HIP       April 2008
+
+
+     NEW SPI        new SPI for data sent to address(es) associated
+                    with this SA.
+
+5.1.2.  ESP_TRANSFORM
+
+   The ESP_TRANSFORM parameter is used during ESP SA establishment.  The
+   first party sends a selection of transform families in the
+   ESP_TRANSFORM parameter, and the peer must select one of the proposed
+   values and include it in the response ESP_TRANSFORM parameter.
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |             Type              |             Length            |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |          Reserved             |           Suite ID #1         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |          Suite ID #2          |           Suite ID #3         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |          Suite ID #n          |             Padding           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+         Type           4095
+         Length         length in octets, excluding Type, Length, and
+                        padding
+         Reserved       zero when sent, ignored when received
+         Suite ID       defines the ESP Suite to be used
+
+   The following Suite IDs are defined in RFC 5201 [RFC5201]:
+
+            Suite ID                          Value
+
+            RESERVED                          0
+            AES-CBC with HMAC-SHA1            1
+            3DES-CBC with HMAC-SHA1           2
+            3DES-CBC with HMAC-MD5            3
+            BLOWFISH-CBC with HMAC-SHA1       4
+            NULL with HMAC-SHA1               5
+            NULL with HMAC-MD5                6
+
+   The sender of an ESP transform parameter MUST make sure that there
+   are no more than six (6) Suite IDs in one ESP transform parameter.
+   Conversely, a recipient MUST be prepared to handle received transport
+   parameters that contain more than six Suite IDs.  The limited number
+   of Suite IDs sets the maximum size of the ESP_TRANSFORM parameter.
+   As the default configuration, the ESP_TRANSFORM parameter MUST
+
+
+
+
+
+Jokela, et al.                Experimental                     [Page 13]
+
+RFC 5202        Using the ESP Transport Format with HIP       April 2008
+
+
+   contain at least one of the mandatory Suite IDs.  There MAY be a
+   configuration option that allows the administrator to override this
+   default.
+
+   Mandatory implementations: AES-CBC with HMAC-SHA1 and NULL with HMAC-
+   SHA1.
+
+   Under some conditions, it is possible to use Traffic Flow
+   Confidentiality (TFC) [RFC4303] with ESP in BEET mode.  However, the
+   definition of such operation is future work and must be done in a
+   separate specification.
+
+5.1.3.  NOTIFY Parameter
+
+   The HIP base specification defines a set of NOTIFY error types.  The
+   following error types are required for describing errors in ESP
+   Transform crypto suites during negotiation.
+
+         NOTIFY PARAMETER - ERROR TYPES           Value
+         ------------------------------           -----
+
+         NO_ESP_PROPOSAL_CHOSEN                    18
+
+            None of the proposed ESP Transform crypto suites was
+            acceptable.
+
+         INVALID_ESP_TRANSFORM_CHOSEN              19
+
+            The ESP Transform crypto suite does not correspond to
+            one offered by the Responder.
+
+
+5.2.  HIP ESP Security Association Setup
+
+   The ESP Security Association is set up during the base exchange.  The
+   following subsections define the ESP SA setup procedure using both
+   base exchange messages (R1, I2, R2) and UPDATE messages.
+
+5.2.1.  Setup During Base Exchange
+
+5.2.1.1.  Modifications in R1
+
+   The ESP_TRANSFORM contains the ESP modes supported by the sender, in
+   the order of preference.  All implementations MUST support AES-CBC
+   [RFC3602] with HMAC-SHA-1-96 [RFC2404].
+
+
+
+
+
+
+Jokela, et al.                Experimental                     [Page 14]
+
+RFC 5202        Using the ESP Transport Format with HIP       April 2008
+
+
+   The following figure shows the resulting R1 packet layout.
+
+      The HIP parameters for the R1 packet:
+
+      IP ( HIP ( [ R1_COUNTER, ]
+                 PUZZLE,
+                 DIFFIE_HELLMAN,
+                 HIP_TRANSFORM,
+                 ESP_TRANSFORM,
+                 HOST_ID,
+                 [ ECHO_REQUEST, ]
+                 HIP_SIGNATURE_2 )
+                 [, ECHO_REQUEST ])
+
+5.2.1.2.  Modifications in I2
+
+   The ESP_INFO contains the sender's SPI for this association as well
+   as the KEYMAT index from where the ESP SA keys will be drawn.  The
+   old SPI value is set to zero.
+
+   The ESP_TRANSFORM contains the ESP mode selected by the sender of R1.
+   All implementations MUST support AES-CBC [RFC3602] with HMAC-SHA-1-96
+   [RFC2404].
+
+   The following figure shows the resulting I2 packet layout.
+
+      The HIP parameters for the I2 packet:
+
+      IP ( HIP ( ESP_INFO,
+                 [R1_COUNTER,]
+                 SOLUTION,
+                 DIFFIE_HELLMAN,
+                 HIP_TRANSFORM,
+                 ESP_TRANSFORM,
+                 ENCRYPTED { HOST_ID },
+                 [ ECHO_RESPONSE ,]
+                 HMAC,
+                 HIP_SIGNATURE
+                 [, ECHO_RESPONSE] ) )
+
+5.2.1.3.  Modifications in R2
+
+   The R2 contains an ESP_INFO parameter, which has the SPI value of the
+   sender of the R2 for this association.  The ESP_INFO also has the
+   KEYMAT index value specifying where the ESP SA keys are drawn.
+
+
+
+
+
+
+Jokela, et al.                Experimental                     [Page 15]
+
+RFC 5202        Using the ESP Transport Format with HIP       April 2008
+
+
+   The following figure shows the resulting R2 packet layout.
+
+      The HIP parameters for the R2 packet:
+
+      IP ( HIP ( ESP_INFO, HMAC_2, HIP_SIGNATURE ) )
+
+5.3.  HIP ESP Rekeying
+
+   In this section, the procedure for rekeying an existing ESP SA is
+   presented.
+
+   Conceptually, the process can be represented by the following message
+   sequence using the host names I' and R' defined in Section 3.3.2.
+   For simplicity, HMAC and HIP_SIGNATURE are not depicted, and
+   DIFFIE_HELLMAN keys are optional.  The UPDATE with ACK_I need not be
+   piggybacked with the UPDATE with SEQ_R; it may be ACKed separately
+   (in which case the sequence would include four packets).
+
+           I'                                  R'
+
+                 UPDATE(ESP_INFO, SEQ_I, [DIFFIE_HELLMAN])
+            ----------------------------------->
+                 UPDATE(ESP_INFO, SEQ_R, ACK_I, [DIFFIE_HELLMAN])
+            <-----------------------------------
+                 UPDATE(ACK_R)
+            ----------------------------------->
+
+   Below, the first two packets in this figure are explained.
+
+5.3.1.  Initializing Rekeying
+
+   When HIP is used with ESP, the UPDATE packet is used to initiate
+   rekeying.  The UPDATE packet MUST carry an ESP_INFO and MAY carry a
+   DIFFIE_HELLMAN parameter.
+
+   Intermediate systems that use the SPI will have to inspect HIP
+   packets for those that carry rekeying information.  The packet is
+   signed for the benefit of the intermediate systems.  Since
+   intermediate systems may need the new SPI values, the contents cannot
+   be encrypted.
+
+
+
+
+
+
+
+
+
+
+
+Jokela, et al.                Experimental                     [Page 16]
+
+RFC 5202        Using the ESP Transport Format with HIP       April 2008
+
+
+   The following figure shows the contents of a rekeying initialization
+   UPDATE packet.
+
+      The HIP parameters for the UPDATE packet initiating rekeying:
+
+      IP ( HIP ( ESP_INFO,
+                 SEQ,
+                 [DIFFIE_HELLMAN, ]
+                 HMAC,
+                 HIP_SIGNATURE ) )
+
+5.3.2.  Responding to the Rekeying Initialization
+
+   The UPDATE ACK is used to acknowledge the received UPDATE rekeying
+   initialization.  The acknowledgment UPDATE packet MUST carry an
+   ESP_INFO and MAY carry a DIFFIE_HELLMAN parameter.
+
+   Intermediate systems that use the SPI will have to inspect HIP
+   packets for packets carrying rekeying information.  The packet is
+   signed for the benefit of the intermediate systems.  Since
+   intermediate systems may need the new SPI values, the contents cannot
+   be encrypted.
+
+   The following figure shows the contents of a rekeying acknowledgment
+   UPDATE packet.
+
+      The HIP parameters for the UPDATE packet:
+
+      IP ( HIP ( ESP_INFO,
+                 SEQ,
+                 ACK,
+                 [ DIFFIE_HELLMAN, ]
+                 HMAC,
+                 HIP_SIGNATURE ) )
+
+5.4.  ICMP Messages
+
+   ICMP message handling is mainly described in the HIP base
+   specification [RFC5201].  In this section, we describe the actions
+   related to ESP security associations.
+
+5.4.1.  Unknown SPI
+
+   If a HIP implementation receives an ESP packet that has an
+   unrecognized SPI number, it MAY respond (subject to rate limiting the
+   responses) with an ICMP packet with type "Parameter Problem", with
+   the pointer pointing to the beginning of SPI field in the ESP header.
+
+
+
+
+Jokela, et al.                Experimental                     [Page 17]
+
+RFC 5202        Using the ESP Transport Format with HIP       April 2008
+
+
+6.  Packet Processing
+
+   Packet processing is mainly defined in the HIP base specification
+   [RFC5201].  This section describes the changes and new requirements
+   for packet handling when the ESP transport format is used.  Note that
+   all HIP packets (currently protocol 253) MUST bypass ESP processing.
+
+6.1.  Processing Outgoing Application Data
+
+   Outgoing application data handling is specified in the HIP base
+   specification [RFC5201].  When the ESP transport format is used, and
+   there is an active HIP session for the given < source, destination >
+   HIT pair, the outgoing datagram is protected using the ESP security
+   association.  In a typical implementation, this will result in a
+   BEET-mode ESP packet being sent.  BEET-mode [ESP-BEET] was introduced
+   above in Section 3.2.  The following additional steps define the
+   conceptual processing rules for outgoing ESP protected datagrams.
+
+   1.  Detect the proper ESP SA using the HITs in the packet header or
+       other information associated with the packet
+
+   2.  Process the packet normally, as if the SA was a transport mode
+       SA.
+
+   3.  Ensure that the outgoing ESP protected packet has proper IP
+       header format depending on the used IP address family, and proper
+       IP addresses in its IP header, e.g., by replacing HITs left by
+       the ESP processing.  Note that this placement of proper IP
+       addresses MAY also be performed at some other point in the stack,
+       e.g., before ESP processing.
+
+6.2.  Processing Incoming Application Data
+
+   Incoming HIP user data packets arrive as ESP protected packets.  In
+   the usual case, the receiving host has a corresponding ESP security
+   association, identified by the SPI and destination IP address in the
+   packet.  However, if the host has crashed or otherwise lost its HIP
+   state, it may not have such an SA.
+
+   The basic incoming data handling is specified in the HIP base
+   specification.  Additional steps are required when ESP is used for
+   protecting the data traffic.  The following steps define the
+   conceptual processing rules for incoming ESP protected datagrams
+   targeted to an ESP security association created with HIP.
+
+   1.  Detect the proper ESP SA using the SPI.  If the resulting SA is a
+       non-HIP ESP SA, process the packet according to standard IPsec
+       rules.  If there are no SAs identified with the SPI, the host MAY
+
+
+
+Jokela, et al.                Experimental                     [Page 18]
+
+RFC 5202        Using the ESP Transport Format with HIP       April 2008
+
+
+       send an ICMP packet as defined in Section 5.4.  How to handle
+       lost state is an implementation issue.
+
+   2.  If the SPI matches with an active HIP-based ESP SA, the IP
+       addresses in the datagram are replaced with the HITs associated
+       with the SPI.  Note that this IP-address-to-HIT conversion step
+       MAY also be performed at some other point in the stack, e.g.,
+       after ESP processing.  Note also that if the incoming packet has
+       IPv4 addresses, the packet must be converted to IPv6 format
+       before replacing the addresses with HITs (such that the transport
+       checksum will pass if there are no errors).
+
+   3.  The transformed packet is next processed normally by ESP, as if
+       the packet were a transport mode packet.  The packet may be
+       dropped by ESP, as usual.  In a typical implementation, the
+       result of successful ESP decryption and verification is a
+       datagram with the associated HITs as source and destination.
+
+   4.  The datagram is delivered to the upper layer.  Demultiplexing the
+       datagram to the right upper layer socket is performed as usual,
+       except that the HITs are used in place of IP addresses during the
+       demultiplexing.
+
+6.3.  HMAC and SIGNATURE Calculation and Verification
+
+   The new HIP parameters described in this document, ESP_INFO and
+   ESP_TRANSFORM, must be protected using HMAC and signature
+   calculations.  In a typical implementation, they are included in R1,
+   I2, R2, and UPDATE packet HMAC and SIGNATURE calculations as
+   described in [RFC5201].
+
+6.4.  Processing Incoming ESP SA Initialization (R1)
+
+   The ESP SA setup is initialized in the R1 message.  The receiving
+   host (Initiator) selects one of the ESP transforms from the presented
+   values.  If no suitable value is found, the negotiation is
+   terminated.  The selected values are subsequently used when
+   generating and using encryption keys, and when sending the reply
+   packet.  If the proposed alternatives are not acceptable to the
+   system, it may abandon the ESP SA establishment negotiation, or it
+   may resend the I1 message within the retry bounds.
+
+   After selecting the ESP transform and performing other R1 processing,
+   the system prepares and creates an incoming ESP security association.
+   It may also prepare a security association for outgoing traffic, but
+   since it does not have the correct SPI value yet, it cannot activate
+   it.
+
+
+
+
+Jokela, et al.                Experimental                     [Page 19]
+
+RFC 5202        Using the ESP Transport Format with HIP       April 2008
+
+
+6.5.  Processing Incoming Initialization Reply (I2)
+
+   The following steps are required to process the incoming ESP SA
+   initialization replies in I2.  The steps below assume that the I2 has
+   been accepted for processing (e.g., has not been dropped due to HIT
+   comparisons as described in [RFC5201]).
+
+   o  The ESP_TRANSFORM parameter is verified and it MUST contain a
+      single value in the parameter, and it MUST match one of the values
+      offered in the initialization packet.
+
+   o  The ESP_INFO NEW SPI field is parsed to obtain the SPI that will
+      be used for the Security Association outbound from the Responder
+      and inbound to the Initiator.  For this initial ESP SA
+      establishment, the old SPI value MUST be zero.  The KEYMAT Index
+      field MUST contain the index value to the KEYMAT from where the
+      ESP SA keys are drawn.
+
+   o  The system prepares and creates both incoming and outgoing ESP
+      security associations.
+
+   o  Upon successful processing of the initialization reply message,
+      the possible old Security Associations (as left over from an
+      earlier incarnation of the HIP association) are dropped and the
+      new ones are installed, and a finalizing packet, R2, is sent.
+      Possible ongoing rekeying attempts are dropped.
+
+6.6.  Processing Incoming ESP SA Setup Finalization (R2)
+
+   Before the ESP SA can be finalized, the ESP_INFO NEW SPI field is
+   parsed to obtain the SPI that will be used for the ESP Security
+   Association inbound to the sender of the finalization message R2.
+   The system uses this SPI to create or activate the outgoing ESP
+   security association used for sending packets to the peer.
+
+6.7.  Dropping HIP Associations
+
+   When the system drops a HIP association, as described in the HIP base
+   specification, the associated ESP SAs MUST also be dropped.
+
+6.8.  Initiating ESP SA Rekeying
+
+   During ESP SA rekeying, the hosts draw new keys from the existing
+   keying material, or new keying material is generated from where the
+   new keys are drawn.
+
+   A system may initiate the SA rekeying procedure at any time.  It MUST
+   initiate a rekey if its incoming ESP sequence counter is about to
+
+
+
+Jokela, et al.                Experimental                     [Page 20]
+
+RFC 5202        Using the ESP Transport Format with HIP       April 2008
+
+
+   overflow.  The system MUST NOT replace its keying material until the
+   rekeying packet exchange successfully completes.
+
+   Optionally, a system may include a new Diffie-Hellman key for use in
+   new KEYMAT generation.  New KEYMAT generation occurs prior to drawing
+   the new keys.
+
+   The rekeying procedure uses the UPDATE mechanism defined in
+   [RFC5201].  Because each peer must update its half of the security
+   association pair (including new SPI creation), the rekeying process
+   requires that each side both send and receive an UPDATE.  A system
+   will then rekey the ESP SA when it has sent parameters to the peer
+   and has received both an ACK of the relevant UPDATE message and
+   corresponding peer's parameters.  It may be that the ACK and the
+   required HIP parameters arrive in different UPDATE messages.  This is
+   always true if a system does not initiate ESP SA update but responds
+   to an update request from the peer, and may also occur if two systems
+   initiate update nearly simultaneously.  In such a case, if the system
+   has an outstanding update request, it saves the one parameter and
+   waits for the other before completing rekeying.
+
+   The following steps define the processing rules for initiating an ESP
+   SA update:
+
+   1.  The system decides whether to continue to use the existing KEYMAT
+       or to generate a new KEYMAT.  In the latter case, the system MUST
+       generate a new Diffie-Hellman public key.
+
+   2.  The system creates an UPDATE packet, which contains the ESP_INFO
+       parameter.  In addition, the host may include the optional
+       DIFFIE_HELLMAN parameter.  If the UPDATE contains the
+       DIFFIE_HELLMAN parameter, the KEYMAT Index in the ESP_INFO
+       parameter MUST be zero, and the Diffie-Hellman group ID must be
+       unchanged from that used in the initial handshake.  If the UPDATE
+       does not contain DIFFIE_HELLMAN, the ESP_INFO KEYMAT Index MUST
+       be greater than or equal to the index of the next byte to be
+       drawn from the current KEYMAT.
+
+   3.  The system sends the UPDATE packet.  For reliability, the
+       underlying UPDATE retransmission mechanism MUST be used.
+
+   4.  The system MUST NOT delete its existing SAs, but continue using
+       them if its policy still allows.  The rekeying procedure SHOULD
+       be initiated early enough to make sure that the SA replay
+       counters do not overflow.
+
+   5.  In case a protocol error occurs and the peer system acknowledges
+       the UPDATE but does not itself send an ESP_INFO, the system may
+
+
+
+Jokela, et al.                Experimental                     [Page 21]
+
+RFC 5202        Using the ESP Transport Format with HIP       April 2008
+
+
+       not finalize the outstanding ESP SA update request.  To guard
+       against this, a system MAY re-initiate the ESP SA update
+       procedure after some time waiting for the peer to respond, or it
+       MAY decide to abort the ESP SA after waiting for an
+       implementation-dependent time.  The system MUST NOT keep an
+       outstanding ESP SA update request for an indefinite time.
+
+   To simplify the state machine, a host MUST NOT generate new UPDATEs
+   while it has an outstanding ESP SA update request, unless it is
+   restarting the update process.
+
+6.9.  Processing Incoming UPDATE Packets
+
+   When a system receives an UPDATE packet, it must be processed if the
+   following conditions hold (in addition to the generic conditions
+   specified for UPDATE processing in Section 6.12 of [RFC5201]):
+
+   1.  A corresponding HIP association must exist.  This is usually
+       ensured by the underlying UPDATE mechanism.
+
+   2.  The state of the HIP association is ESTABLISHED or R2-SENT.
+
+   If the above conditions hold, the following steps define the
+   conceptual processing rules for handling the received UPDATE packet:
+
+   1.  If the received UPDATE contains a DIFFIE_HELLMAN parameter, the
+       received KEYMAT Index MUST be zero and the Group ID must match
+       the Group ID in use on the association.  If this test fails, the
+       packet SHOULD be dropped and the system SHOULD log an error
+       message.
+
+   2.  If there is no outstanding rekeying request, the packet
+       processing continues as specified in Section 6.9.1.
+
+   3.  If there is an outstanding rekeying request, the UPDATE MUST be
+       acknowledged, the received ESP_INFO (and possibly DIFFIE_HELLMAN)
+       parameters must be saved, and the packet processing continues as
+       specified in Section 6.10.
+
+6.9.1.  Processing UPDATE Packet: No Outstanding Rekeying Request
+
+   The following steps define the conceptual processing rules for
+   handling a received UPDATE packet with the ESP_INFO parameter:
+
+   1.  The system consults its policy to see if it needs to generate a
+       new Diffie-Hellman key, and generates a new key (with same Group
+       ID) if needed.  The system records any newly generated or
+
+
+
+
+Jokela, et al.                Experimental                     [Page 22]
+
+RFC 5202        Using the ESP Transport Format with HIP       April 2008
+
+
+       received Diffie-Hellman keys for use in KEYMAT generation upon
+       finalizing the ESP SA update.
+
+   2.  If the system generated a new Diffie-Hellman key in the previous
+       step, or if it received a DIFFIE_HELLMAN parameter, it sets the
+       ESP_INFO KEYMAT Index to zero.  Otherwise, the ESP_INFO KEYMAT
+       Index MUST be greater than or equal to the index of the next byte
+       to be drawn from the current KEYMAT.  In this case, it is
+       RECOMMENDED that the host use the KEYMAT Index requested by the
+       peer in the received ESP_INFO.
+
+   3.  The system creates an UPDATE packet, which contains an ESP_INFO
+       parameter and the optional DIFFIE_HELLMAN parameter.  This UPDATE
+       would also typically acknowledge the peer's UPDATE with an ACK
+       parameter, although a separate UPDATE ACK may be sent.
+
+   4.  The system sends the UPDATE packet and stores any received
+       ESP_INFO and DIFFIE_HELLMAN parameters.  At this point, it only
+       needs to receive an acknowledgment for the newly sent UPDATE to
+       finish ESP SA update.  In the usual case, the acknowledgment is
+       handled by the underlying UPDATE mechanism.
+
+6.10.  Finalizing Rekeying
+
+   A system finalizes rekeying when it has both received the
+   corresponding UPDATE acknowledgment packet from the peer and it has
+   successfully received the peer's UPDATE.  The following steps are
+   taken:
+
+   1.  If the received UPDATE messages contain a new Diffie-Hellman key,
+       the system has a new Diffie-Hellman key due to initiating ESP SA
+       update, or both, the system generates a new KEYMAT.  If there is
+       only one new Diffie-Hellman key, the old existing key is used as
+       the other key.
+
+   2.  If the system generated a new KEYMAT in the previous step, it
+       sets the KEYMAT Index to zero, independent of whether the
+       received UPDATE included a Diffie-Hellman key or not.  If the
+       system did not generate a new KEYMAT, it uses the greater KEYMAT
+       Index of the two (sent and received) ESP_INFO parameters.
+
+   3.  The system draws keys for new incoming and outgoing ESP SAs,
+       starting from the KEYMAT Index, and prepares new incoming and
+       outgoing ESP SAs.  The SPI for the outgoing SA is the new SPI
+       value received in an ESP_INFO parameter.  The SPI for the
+       incoming SA was generated when the ESP_INFO was sent to the peer.
+       The order of the keys retrieved from the KEYMAT during the
+       rekeying process is similar to that described in Section 7.
+
+
+
+Jokela, et al.                Experimental                     [Page 23]
+
+RFC 5202        Using the ESP Transport Format with HIP       April 2008
+
+
+       Note, that only IPsec ESP keys are retrieved during the rekeying
+       process, not the HIP keys.
+
+   4.  The system starts to send to the new outgoing SA and prepares to
+       start receiving data on the new incoming SA.  Once the system
+       receives data on the new incoming SA, it may safely delete the
+       old SAs.
+
+6.11.  Processing NOTIFY Packets
+
+   The processing of NOTIFY packets is described in the HIP base
+   specification.
+
+7.  Keying Material
+
+   The keying material is generated as described in the HIP base
+   specification.  During the base exchange, the initial keys are drawn
+   from the generated material.  After the HIP association keys have
+   been drawn, the ESP keys are drawn in the following order:
+
+      SA-gl ESP encryption key for HOST_g's outgoing traffic
+
+      SA-gl ESP authentication key for HOST_g's outgoing traffic
+
+      SA-lg ESP encryption key for HOST_l's outgoing traffic
+
+      SA-lg ESP authentication key for HOST_l's outgoing traffic
+
+   HOST_g denotes the host with the greater HIT value, and HOST_l
+   denotes the host with the lower HIT value.  When HIT values are
+   compared, they are interpreted as positive (unsigned) 128-bit
+   integers in network byte order.
+
+   The four HIP keys are only drawn from KEYMAT during a HIP I1->R2
+   exchange.  Subsequent rekeys using UPDATE will only draw the four ESP
+   keys from KEYMAT.  Section 6.9 describes the rules for reusing or
+   regenerating KEYMAT based on the rekeying.
+
+   The number of bits drawn for a given algorithm is the "natural" size
+   of the keys.  For the mandatory algorithms, the following sizes
+   apply:
+
+   AES  128 bits
+
+   SHA-1  160 bits
+
+   NULL  0 bits
+
+
+
+
+Jokela, et al.                Experimental                     [Page 24]
+
+RFC 5202        Using the ESP Transport Format with HIP       April 2008
+
+
+8.  Security Considerations
+
+   In this document, the usage of ESP [RFC4303] between HIP hosts to
+   protect data traffic is introduced.  The Security Considerations for
+   ESP are discussed in the ESP specification.
+
+   There are different ways to establish an ESP Security Association
+   between two nodes.  This can be done, e.g., using IKE [RFC4306].
+   This document specifies how the Host Identity Protocol is used to
+   establish ESP Security Associations.
+
+   The following issues are new or have changed from the standard ESP
+   usage:
+
+   o  Initial keying material generation
+
+   o  Updating the keying material
+
+   The initial keying material is generated using the Host Identity
+   Protocol [RFC5201] using the Diffie-Hellman procedure.  This document
+   extends the usage of the UPDATE packet, defined in the base
+   specification, to modify existing ESP SAs.  The hosts may rekey,
+   i.e., force the generation of new keying material using the Diffie-
+   Hellman procedure.  The initial setup of ESP SA between the hosts is
+   done during the base exchange, and the message exchange is protected
+   using methods provided by base exchange.  Changes in connection
+   parameters means basically that the old ESP SA is removed and a new
+   one is generated once the UPDATE message exchange has been completed.
+   The message exchange is protected using the HIP association keys.
+   Both HMAC and signing of packets is used.
+
+9.  IANA Considerations
+
+   This document defines additional parameters and NOTIFY error types
+   for the Host Identity Protocol [RFC5201].
+
+   The new parameters and their type numbers are defined in
+   Section 5.1.1 and Section 5.1.2, and they have been added to the
+   Parameter Type namespace specified in [RFC5201].
+
+   The new NOTIFY error types and their values are defined in
+   Section 5.1.3, and they have been added to the Notify Message Type
+   namespace specified in [RFC5201].
+
+
+
+
+
+
+
+
+Jokela, et al.                Experimental                     [Page 25]
+
+RFC 5202        Using the ESP Transport Format with HIP       April 2008
+
+
+10.  Acknowledgments
+
+   This document was separated from the base "Host Identity Protocol"
+   specification in the beginning of 2005.  Since then, a number of
+   people have contributed to the text by providing comments and
+   modification proposals.  The list of people include Tom Henderson,
+   Jeff Ahrenholz, Jan Melen, Jukka Ylitalo, and Miika Komu.  The
+   authors also want to thank Charlie Kaufman for reviewing the document
+   with his eye on the usage of crypto algorithms.
+
+   Due to the history of this document, most of the ideas are inherited
+   from the base "Host Identity Protocol" specification.  Thus, the list
+   of people in the Acknowledgments section of that specification is
+   also valid for this document.  Many people have given valuable
+   feedback, and our apologies to anyone whose name is missing.
+
+11.  References
+
+11.1.  Normative references
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2404]   Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
+               ESP and AH", RFC 2404, November 1998.
+
+   [RFC3602]   Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
+               Algorithm and Its Use with IPsec", RFC 3602,
+               September 2003.
+
+   [RFC4303]   Kent, S., "IP Encapsulating Security Payload (ESP)",
+               RFC 4303, December 2005.
+
+   [RFC5201]   Moskowitz, R., Nikander, P., Jokela, P., Ed., and T.
+               Henderson, "Host Identity Protocol", RFC 5201,
+               April 2008.
+
+11.2.  Informative references
+
+   [ESP-BEET]  Nikander, P. and J. Melen, "A Bound End-to-End Tunnel
+               (BEET) mode for ESP", Work in Progress, November 2007.
+
+   [RFC3260]   Grossman, D., "New Terminology and Clarifications for
+               Diffserv", RFC 3260, April 2002.
+
+
+
+
+
+
+
+Jokela, et al.                Experimental                     [Page 26]
+
+RFC 5202        Using the ESP Transport Format with HIP       April 2008
+
+
+   [RFC3474]   Lin, Z. and D. Pendarakis, "Documentation of IANA
+               assignments for Generalized MultiProtocol Label Switching
+               (GMPLS) Resource Reservation Protocol - Traffic
+               Engineering (RSVP-TE) Usage and Extensions for
+               Automatically Switched Optical Network (ASON)", RFC 3474,
+               March 2003.
+
+   [RFC4301]   Kent, S. and K. Seo, "Security Architecture for the
+               Internet Protocol", RFC 4301, December 2005.
+
+   [RFC4306]   Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
+               RFC 4306, December 2005.
+
+   [RFC4423]   Moskowitz, R. and P. Nikander, "Host Identity Protocol
+               (HIP) Architecture", RFC 4423, May 2006.
+
+   [RFC5206]   Henderson, T., Ed., "End-Host Mobility and Multihoming
+               with the Host Identity Protocol", RFC 5206, April 2008.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jokela, et al.                Experimental                     [Page 27]
+
+RFC 5202        Using the ESP Transport Format with HIP       April 2008
+
+
+Appendix A.  A Note on Implementation Options
+
+   It is possible to implement this specification in multiple different
+   ways.  As noted above, one possible way of implementing this is to
+   rewrite IP headers below IPsec.  In such an implementation, IPsec is
+   used as if it was processing IPv6 transport mode packets, with the
+   IPv6 header containing HITs instead of IP addresses in the source and
+   destination address fields.  In outgoing packets, after IPsec
+   processing, the HITs are replaced with actual IP addresses, based on
+   the HITs and the SPI.  In incoming packets, before IPsec processing,
+   the IP addresses are replaced with HITs, based on the SPI in the
+   incoming packet.  In such an implementation, all IPsec policies are
+   based on HITs and the upper layers only see packets with HITs in the
+   place of IP addresses.  Consequently, support of HIP does not
+   conflict with other uses of IPsec as long as the SPI spaces are kept
+   separate.
+
+   Another way to implement this specification is to use the proposed
+   BEET mode (A Bound End-to-End mode for ESP, [ESP-BEET]).  The BEET
+   mode provides some features from both IPsec tunnel and transport
+   modes.  The HIP uses HITs as the "inner" addresses and IP addresses
+   as "outer" addresses, like IP addresses are used in the tunnel mode.
+   Instead of tunneling packets between hosts, a conversion between
+   inner and outer addresses is made at end-hosts and the inner address
+   is never sent on the wire after the initial HIP negotiation.  BEET
+   provides IPsec transport mode syntax (no inner headers) with limited
+   tunnel mode semantics (fixed logical inner addresses - the HITs - and
+   changeable outer IP addresses).
+
+   Compared to the option of implementing the required address rewrites
+   outside of IPsec, BEET has one implementation level benefit.  The
+   BEET-way of implementing the address rewriting keeps all the
+   configuration information in one place, at the SAD.  On the other
+   hand, when address rewriting is implemented separately, the
+   implementation must make sure that the information in the SAD and the
+   separate address rewriting DB are kept in synchrony.  As a result,
+   the BEET-mode-based way of implementing this specification is
+   RECOMMENDED over the separate implementation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jokela, et al.                Experimental                     [Page 28]
+
+RFC 5202        Using the ESP Transport Format with HIP       April 2008
+
+
+Authors' Addresses
+
+   Petri Jokela
+   Ericsson Research NomadicLab
+   JORVAS  FIN-02420
+   FINLAND
+
+   Phone: +358 9 299 1
+   EMail: petri.jokela@nomadiclab.com
+
+
+   Robert Moskowitz
+   ICSAlabs, An Independent Division of Verizon Business Systems
+   1000 Bent Creek Blvd, Suite 200
+   Mechanicsburg, PA
+   USA
+
+   EMail: rgm@icsalabs.com
+
+
+   Pekka Nikander
+   Ericsson Research NomadicLab
+   JORVAS  FIN-02420
+   FINLAND
+
+   Phone: +358 9 299 1
+   EMail: pekka.nikander@nomadiclab.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jokela, et al.                Experimental                     [Page 29]
+
+RFC 5202        Using the ESP Transport Format with HIP       April 2008
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2008).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Jokela, et al.                Experimental                     [Page 30]
+