draft-ietf-hip-esp-04.txt   draft-ietf-hip-esp-05.txt 
Network Working Group P. Jokela Network Working Group P. Jokela
Internet-Draft Ericsson Research NomadicLab Internet-Draft Ericsson Research NomadicLab
Expires: April 4, 2007 R. Moskowitz Expires: August 18, 2007 R. Moskowitz
ICSAlabs, a Division of TruSecure ICSAlabs, a Division of TruSecure
Corporation Corporation
P. Nikander P. Nikander
Ericsson Research NomadicLab Ericsson Research NomadicLab
February 14, 2007
Using ESP transport format with HIP Using ESP transport format with HIP
draft-ietf-hip-esp-04 draft-ietf-hip-esp-05
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 38
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 4, 2007. This Internet-Draft will expire on August 18, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This memo specifies an Encapsulated Security Payload (ESP) based This memo specifies an Encapsulated Security Payload (ESP) based
mechanism for transmission of user data packets, to be used with the mechanism for transmission of user data packets, to be used with the
Host Identity Protocol (HIP). Host Identity Protocol (HIP).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
skipping to change at page 2, line 29 skipping to change at page 2, line 35
3.3.6. Sequence Number . . . . . . . . . . . . . . . . . . . 10 3.3.6. Sequence Number . . . . . . . . . . . . . . . . . . . 10
3.3.7. Lifetimes and Timers . . . . . . . . . . . . . . . . . 10 3.3.7. Lifetimes and Timers . . . . . . . . . . . . . . . . . 10
3.4. IPsec and HIP ESP Implementation Considerations . . . . . 10 3.4. IPsec and HIP ESP Implementation Considerations . . . . . 10
4. The Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 12 4. The Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. ESP in HIP . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. ESP in HIP . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1.1. Setting up an ESP Security Association . . . . . . . . 12 4.1.1. Setting up an ESP Security Association . . . . . . . . 12
4.1.2. Updating an Existing ESP SA . . . . . . . . . . . . . 13 4.1.2. Updating an Existing ESP SA . . . . . . . . . . . . . 13
5. Parameter and Packet Formats . . . . . . . . . . . . . . . . . 14 5. Parameter and Packet Formats . . . . . . . . . . . . . . . . . 14
5.1. New Parameters . . . . . . . . . . . . . . . . . . . . . . 14 5.1. New Parameters . . . . . . . . . . . . . . . . . . . . . . 14
5.1.1. ESP_INFO . . . . . . . . . . . . . . . . . . . . . . . 14 5.1.1. ESP_INFO . . . . . . . . . . . . . . . . . . . . . . . 14
5.1.2. ESP_TRANSFORM . . . . . . . . . . . . . . . . . . . . 15 5.1.2. ESP_TRANSFORM . . . . . . . . . . . . . . . . . . . . 16
5.1.3. NOTIFY Parameter . . . . . . . . . . . . . . . . . . . 16 5.1.3. NOTIFY Parameter . . . . . . . . . . . . . . . . . . . 18
5.2. HIP ESP Security Association Setup . . . . . . . . . . . . 17 5.2. HIP ESP Security Association Setup . . . . . . . . . . . . 18
5.2.1. Setup During Base Exchange . . . . . . . . . . . . . . 17 5.2.1. Setup During Base Exchange . . . . . . . . . . . . . . 18
5.3. HIP ESP Rekeying . . . . . . . . . . . . . . . . . . . . . 18 5.3. HIP ESP Rekeying . . . . . . . . . . . . . . . . . . . . . 19
5.3.1. Initializing Rekeying . . . . . . . . . . . . . . . . 19 5.3.1. Initializing Rekeying . . . . . . . . . . . . . . . . 20
5.3.2. Responding to the Rekeying Initialization . . . . . . 19 5.3.2. Responding to the Rekeying Initialization . . . . . . 20
5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 20 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 21
5.4.1. Unknown SPI . . . . . . . . . . . . . . . . . . . . . 20 5.4.1. Unknown SPI . . . . . . . . . . . . . . . . . . . . . 21
6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 21 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 22
6.1. Processing Outgoing Application Data . . . . . . . . . . . 21 6.1. Processing Outgoing Application Data . . . . . . . . . . . 22
6.2. Processing Incoming Application Data . . . . . . . . . . . 21 6.2. Processing Incoming Application Data . . . . . . . . . . . 22
6.3. HMAC and SIGNATURE Calculation and Verification . . . . . 22 6.3. HMAC and SIGNATURE Calculation and Verification . . . . . 23
6.4. Processing Incoming ESP SA Initialization (R1) . . . . . . 22 6.4. Processing Incoming ESP SA Initialization (R1) . . . . . . 23
6.5. Processing Incoming Initialization Reply (I2) . . . . . . 23 6.5. Processing Incoming Initialization Reply (I2) . . . . . . 24
6.6. Processing Incoming ESP SA Setup Finalization (R2) . . . . 23 6.6. Processing Incoming ESP SA Setup Finalization (R2) . . . . 24
6.7. Dropping HIP Associations . . . . . . . . . . . . . . . . 23 6.7. Dropping HIP Associations . . . . . . . . . . . . . . . . 24
6.8. Initiating ESP SA Rekeying . . . . . . . . . . . . . . . . 23 6.8. Initiating ESP SA Rekeying . . . . . . . . . . . . . . . . 24
6.9. Processing Incoming UPDATE Packets . . . . . . . . . . . . 25 6.9. Processing Incoming UPDATE Packets . . . . . . . . . . . . 26
6.9.1. Processing UPDATE Packet: No Outstanding Rekeying 6.9.1. Processing UPDATE Packet: No Outstanding Rekeying
Request . . . . . . . . . . . . . . . . . . . . . . . 25 Request . . . . . . . . . . . . . . . . . . . . . . . 26
6.10. Finalizing Rekeying . . . . . . . . . . . . . . . . . . . 26 6.10. Finalizing Rekeying . . . . . . . . . . . . . . . . . . . 27
6.11. Processing NOTIFY Packets . . . . . . . . . . . . . . . . 27 6.11. Processing NOTIFY Packets . . . . . . . . . . . . . . . . 28
7. Keying Material . . . . . . . . . . . . . . . . . . . . . . . 28 7. Keying Material . . . . . . . . . . . . . . . . . . . . . . . 29
8. Security Considerations . . . . . . . . . . . . . . . . . . . 29 8. Security Considerations . . . . . . . . . . . . . . . . . . . 30
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
11.1. Normative references . . . . . . . . . . . . . . . . . . . 32 11.1. Normative references . . . . . . . . . . . . . . . . . . . 33
11.2. Informative references . . . . . . . . . . . . . . . . . . 32 11.2. Informative references . . . . . . . . . . . . . . . . . . 33
Appendix A. A Note on Implementation Options . . . . . . . . . . 33 Appendix A. A Note on Implementation Options . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
Intellectual Property and Copyright Statements . . . . . . . . . . 35 Intellectual Property and Copyright Statements . . . . . . . . . . 37
1. Introduction 1. Introduction
In the Host Identity Protocol Architecture [7], hosts are identified In the Host Identity Protocol Architecture [RFC4423], hosts are
with public keys. The Host Identity Protocol [5] base exchange identified with public keys. The Host Identity Protocol
allows any two HIP-supporting hosts to authenticate each other and to [I-D.ietf-hip-base] base exchange allows any two HIP-supporting hosts
create a HIP association between themselves. During the base to authenticate each other and to create a HIP association between
exchange, the hosts generate a piece of shared keying material using themselves. During the base exchange, the hosts generate a piece of
an authenticated Diffie-Hellman exchange. shared keying material using an authenticated Diffie-Hellman
exchange.
The HIP base exchange specification [5] does not describe any The HIP base exchange specification [I-D.ietf-hip-base] does not
transport formats, or methods for user data, to be used during the describe any transport formats, or methods for user data, to be used
actual communication; it only defines that it is mandatory to during the actual communication; it only defines that it is mandatory
implement the Encapsulated Security Payload (ESP) [4] based transport to implement the Encapsulated Security Payload (ESP) [RFC4303] based
format and method. This document specifies how ESP is used with HIP transport format and method. This document specifies how ESP is used
to carry actual user data. with HIP to carry actual user data.
To be more specific, this document specifies a set of HIP protocol To be more specific, this document specifies a set of HIP protocol
extensions and their handling. Using these extensions, a pair of ESP extensions and their handling. Using these extensions, a pair of ESP
Security Associations (SAs) is created between the hosts during the Security Associations (SAs) is created between the hosts during the
base exchange. The resulting ESP Security Associations use keys base exchange. The resulting ESP Security Associations use keys
drawn from the keying material (KEYMAT) generated during the base drawn from the keying material (KEYMAT) generated during the base
exchange. After the HIP association and required ESP SAs have been exchange. After the HIP association and required ESP SAs have been
established between the hosts, the user data communication is established between the hosts, the user data communication is
protected using ESP. In addition, this document specifies methods to protected using ESP. In addition, this document specifies methods to
update an existing ESP Security Association. update an existing ESP Security Association.
skipping to change at page 5, line 9 skipping to change at page 5, line 9
ESP Security Parameter Index (SPI) is used to indicate the right host ESP Security Parameter Index (SPI) is used to indicate the right host
context. The SPIs are selected during the HIP ESP setup exchange. context. The SPIs are selected during the HIP ESP setup exchange.
For user data packets, ESP SPIs (in possible combination with IP For user data packets, ESP SPIs (in possible combination with IP
addresses) are used indirectly to identify the host context, thereby addresses) are used indirectly to identify the host context, thereby
avoiding any additional explicit protocol headers. avoiding any additional explicit protocol headers.
2. Conventions used in this document 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [1]. document are to be interpreted as described in RFC2119 [RFC2119].
3. Using ESP with HIP 3. Using ESP with HIP
The HIP base exchange is used to set up a HIP association between two The HIP base exchange is used to set up a HIP association between two
hosts. The base exchange provides two-way host authentication and hosts. The base exchange provides two-way host authentication and
key material generation, but it does not provide any means for key material generation, but it does not provide any means for
protecting data communication between the hosts. In this document we protecting data communication between the hosts. In this document we
specify the use of ESP for protecting user data traffic after the HIP 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- base exchange. Note that this use of ESP is intended only for host-
to-host traffic; security gateways are not supported. to-host traffic; security gateways are not supported.
skipping to change at page 6, line 29 skipping to change at page 6, line 29
proposed transforms, selects one of those proposed transforms, and proposed transforms, selects one of those proposed transforms, and
adds it to the I2 packet in an ESP_TRANSFORM parameter. In this I2 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 packet, the Initiator also sends the SPI value that it wants to be
used for ESP traffic flowing from the Responder to the Initiator. used for ESP traffic flowing from the Responder to the Initiator.
This information is carried using the new ESP_INFO parameter. When This information is carried using the new ESP_INFO parameter. When
finalizing the ESP SA setup, the Responder sends its SPI value to the finalizing the ESP SA setup, the Responder sends its SPI value to the
Initiator in the R2 packet, again using ESP_INFO. Initiator in the R2 packet, again using ESP_INFO.
3.1. ESP Packet Format 3.1. ESP Packet Format
The ESP specification [4] defines the ESP packet format for IPsec. The ESP specification [RFC4303] defines the ESP packet format for
The HIP ESP packet looks exactly the same as the IPsec ESP transport IPsec. The HIP ESP packet looks exactly the same as the IPsec ESP
format packet. The semantics, however, are a bit different and are transport format packet. The semantics, however, are a bit different
described in more detail in the next subsection. and are described in more detail in the next subsection.
3.2. Conceptual ESP Packet Processing 3.2. Conceptual ESP Packet Processing
ESP packet processing can be implemented in different ways in HIP. ESP packet processing can be implemented in different ways in HIP.
It is possible to implement it in a way that a standards compliant, It is possible to implement it in a way that a standards compliant,
unmodified IPsec implementation [4] can be used. unmodified IPsec implementation [RFC4303] can be used.
When a standards compliant IPsec implementation that uses IP When a standards compliant IPsec implementation that uses IP
addresses in the SPD and SAD is used, the packet processing may take addresses in the SPD and SAD is used, the packet processing may take
the following steps. For outgoing packets, assuming that the upper the following steps. For outgoing packets, assuming that the upper
layer pseudoheader has been built using IP addresses, the layer pseudoheader has been built using IP addresses, the
implementation recalculates upper layer checksums using HITs and, implementation recalculates upper layer checksums using HITs and,
after that, changes the packet source and destination addresses back after that, changes the packet source and destination addresses back
to corresponding IP addresses. The packet is sent to the IPsec ESP to corresponding IP addresses. The packet is sent to the IPsec ESP
for transport mode handling and from there the encrypted packet is for transport mode handling and from there the encrypted packet is
sent to the network. When an ESP packet is received, the 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 first put to the IPsec ESP transport mode handling, and after
decryption, the source and destination IP addresses are replaced with decryption, the source and destination IP addresses are replaced with
HITs and finally, upper layer checksums are verified before passing HITs and finally, upper layer checksums are verified before passing
the packet to the upper layer. the packet to the upper layer.
An alternative way to implement the packet processing is the BEET An alternative way to implement the packet processing is the BEET
(Bound End-to-End Tunnel) [11] mode. In BEET mode, the ESP packet is (Bound End-to-End Tunnel) [I-D.nikander-esp-beet-mode] mode. In BEET
formatted as a transport mode packet, but the semantics of the mode, the ESP packet is formatted as a transport mode packet, but the
connection are the same as for tunnel mode. The "outer" addresses of semantics of the connection are the same as for tunnel mode. The
the packet are the IP addresses and the "inner" addresses are the "outer" addresses of the packet are the IP addresses and the "inner"
HITs. For outgoing traffic, after the packet has been encrypted, the addresses are the HITs. For outgoing traffic, after the packet has
packet's IP header is changed to a new one, containing IP addresses been encrypted, the packet's IP header is changed to a new one,
instead of HITs and the packet is sent to the network. When ESP containing IP addresses instead of HITs and the packet is sent to the
packet is received, the SPI value, together with the integrity network. When ESP packet is received, the SPI value, together with
protection, allow the packet to be securely associated with the right the integrity protection, allow the packet to be securely associated
HIT pair. The packet header is replaces with a new header, with the right HIT pair. The packet header is replaces with a new
containing HITs and the packet is decrypted. header, containing HITs and the packet is decrypted.
3.2.1. Semantics of the Security Parameter Index (SPI) 3.2.1. Semantics of the Security Parameter Index (SPI)
SPIs are used in ESP to find the right Security Association for SPIs are used in ESP to find the right Security Association for
received packets. The ESP SPIs have added significance when used received packets. The ESP SPIs have added significance when used
with HIP; they are a compressed representation of a pair of HITs. with HIP; they are a compressed representation of a pair of HITs.
Thus, SPIs MAY be used by intermediary systems in providing services Thus, SPIs MAY be used by intermediary systems in providing services
like address mapping. Note that since the SPI has significance at like address mapping. Note that since the SPI has significance at
the receiver, only the < DST, SPI >, where DST is a destination IP the receiver, only the < DST, SPI >, where DST is a destination IP
address, uniquely identifies the receiver HIT at any given point of address, uniquely identifies the receiver HIT at any given point of
time. The same SPI value may be used by several hosts. A single < time. The same SPI value may be used by several hosts. A single <
DST, SPI > value may denote different hosts and contexts at different DST, SPI > value may denote different hosts and contexts at different
points of time, depending on the host that is currently reachable at points of time, depending on the host that is currently reachable at
the DST. the DST.
Each host selects for itself the SPI it wants to see in packets 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 received from its peer. This allows it to select different SPIs for
different peers. The SPI selection SHOULD be random; the rules of different peers. The SPI selection SHOULD be random; the rules of
Section 2.1 of the ESP specification [4] must be followed. A Section 2.1 of the ESP specification [RFC4303] must be followed. A
different SPI SHOULD be used for each HIP exchange with a particular different SPI SHOULD be used for each HIP exchange with a particular
host; this is to avoid a replay attack. Additionally, when a host host; this is to avoid a replay attack. Additionally, when a host
rekeys, the SPI MUST be changed. Furthermore, if a host changes over rekeys, the SPI MUST be changed. Furthermore, if a host changes over
to use a different IP address, it MAY change the SPI. to use a different IP address, it MAY change the SPI.
One method for SPI creation that meets the above criteria would be to 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 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. 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 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 fourth (R2) packets of the base HIP exchange. Changes in SPI are
signaled with ESP_INFO parameters. signaled with ESP_INFO parameters.
3.3. Security Association Establishment and Maintenance 3.3. Security Association Establishment and Maintenance
3.3.1. ESP Security Associations 3.3.1. ESP Security Associations
In HIP, ESP Security Associations are setup between the HIP nodes In HIP, ESP Security Associations are setup between the HIP nodes
during the base exchange [5]. Existing ESP SAs can be updated later during the base exchange [I-D.ietf-hip-base]. Existing ESP SAs can
using UPDATE messages. The reason for updating the ESP SA later can be updated later using UPDATE messages. The reason for updating the
be e.g. need for rekeying the SA because of sequence number rollover. ESP SA later can be e.g. need for rekeying the SA because of sequence
number rollover.
Upon setting up a HIP association, each association is linked to two Upon setting up a HIP association, each association is linked to two
ESP SAs, one for incoming packets and one for outgoing packets. The ESP SAs, one for incoming packets and one for outgoing packets. The
Initiator's incoming SA corresponds with the Responder's outgoing Initiator's incoming SA corresponds with the Responder's outgoing
one, and vice versa. The Initiator defines the SPI for its incoming 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 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 SA-RI, and the corresponding SPI is called SPI-RI. Respectively, the
Responder's incoming SA corresponds with the Initiator's outgoing SA Responder's incoming SA corresponds with the Initiator's outgoing SA
and is called SA-IR, with the SPI being called SPI-IR. and is called SA-IR, with the SPI being called SPI-IR.
skipping to change at page 8, line 32 skipping to change at page 8, line 33
sending out the I2, as explained in Section 6.4. The keys are sending out the I2, as explained in Section 6.4. The keys are
derived from KEYMAT, as defined in Section 7. The Responder creates derived from KEYMAT, as defined in Section 7. The Responder creates
SA-RI as a part of I2 processing, see Section 6.5. SA-RI as a part of I2 processing, see Section 6.5.
The Responder creates SA-IR as a part of I2 processing, before 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 sending out R2; see Section 6.5. The Initiator creates SA-IR when
processing R2; see Section 6.6. processing R2; see Section 6.6.
The initial session keys are drawn from the generated keying The initial session keys are drawn from the generated keying
material, KEYMAT, after the HIP keys have been drawn as specified in material, KEYMAT, after the HIP keys have been drawn as specified in
[5]. [I-D.ietf-hip-base].
When the HIP association is removed, the related ESP SAs MUST also be When the HIP association is removed, the related ESP SAs MUST also be
removed. removed.
3.3.2. Rekeying 3.3.2. Rekeying
After the initial HIP base exchange and SA establishment, both hosts After the initial HIP base exchange and SA establishment, both hosts
are in the ESTABLISHED state. There are no longer Initiator and are in the ESTABLISHED state. There are no longer Initiator and
Responder roles and the association is symmetric. In this Responder roles and the association is symmetric. In this
subsection, the party that initiates the rekey procedure is denoted subsection, the party that initiates the rekey procedure is denoted
skipping to change at page 9, line 44 skipping to change at page 9, line 45
The SPIs in ESP provide a simple compression of the HIP data from all 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 packets after the HIP exchange. This does require a per HIT-pair
Security Association (and SPI), and a decrease of policy granularity Security Association (and SPI), and a decrease of policy granularity
over other Key Management Protocols like IKE. over other Key Management Protocols like IKE.
When a host updates the ESP SA, it provides a new inbound SPI to and When a host updates the ESP SA, it provides a new inbound SPI to and
gets a new outbound SPI from its partner. gets a new outbound SPI from its partner.
3.3.5. Supported Transforms 3.3.5. Supported Transforms
All HIP implementations MUST support AES [3] and HMAC-SHA-1-96 [2]. All HIP implementations MUST support AES-CBC [RFC3602] and HMAC-SHA-
If the Initiator does not support any of the transforms offered by 1-96 [RFC2404]. If the Initiator does not support any of the
the Responder, it should abandon the negotiation and inform the peer transforms offered by the Responder, it should abandon the
with a NOTIFY message about a non-supported transform. negotiation and inform the peer with a NOTIFY message about a non-
supported transform.
In addition to AES, all implementations MUST implement the ESP NULL In addition to AES-CBC, all implementations MUST implement the ESP
encryption algorithm. When the ESP NULL encryption is used, it MUST NULL encryption algorithm. When the ESP NULL encryption is used, it
be used together with SHA1 or MD5 authentication as specified in MUST be used together with SHA1 or MD5 authentication as specified in
Section 5.1.2 Section 5.1.2
3.3.6. Sequence Number 3.3.6. Sequence Number
The Sequence Number field is MANDATORY when ESP is used with HIP. The Sequence Number field is MANDATORY when ESP is used with HIP.
Anti-replay protection MUST be used in an ESP SA established with 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 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 used. This means that each host MUST rekey before its sequence
number reaches 2^64. number reaches 2^64.
When using a 64-bit sequence number, the higher 32 bits are NOT 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. included in the ESP header, but are simply kept local to both peers.
See [9]. See [I-D.ietf-ipsec-rfc2401bis].
3.3.7. Lifetimes and Timers 3.3.7. Lifetimes and Timers
HIP does not negotiate any lifetimes. All ESP lifetimes are local HIP does not negotiate any lifetimes. All ESP lifetimes are local
policy. The only lifetimes a HIP implementation MUST support are policy. The only lifetimes a HIP implementation MUST support are
sequence number rollover (for replay protection), and SHOULD support sequence number rollover (for replay protection), and SHOULD support
timing out inactive ESP SAs. An SA times out if no packets are timing out inactive ESP SAs. An SA times out if no packets are
received using that SA. The default timeout value is 15 minutes. received using that SA. The default timeout value is 15 minutes.
Implementations MAY support lifetimes for the various ESP transforms. Implementations MAY support lifetimes for the various ESP transforms.
Each implementation SHOULD implement per-HIT configuration of the Each implementation SHOULD implement per-HIT configuration of the
skipping to change at page 11, line 7 skipping to change at page 11, line 9
IPsec processing are given an IPsec-enabled SA. The SP then MUST be 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 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 this SA. Data originating from a socket that is not using HIP, MUST
NOT have checksum recalculated as described in Section 3.2 paragraph 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. 2 and data MUST NOT be passed to the SP or SA created by the HIP.
Incoming data packets using a SA that is not negotiated by HIP, MUST Incoming data packets using a SA that is not negotiated by HIP, MUST
NOT be processed as described in Section 3.2 paragraph 2. The SPI 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 will identify the correct SA for packet decryption and MUST be used
to identify that the packet has an upper-layer checksum that is to identify that the packet has an upper-layer checksum that is
calculated as specified in [5]. calculated as specified in [I-D.ietf-hip-base].
4. The Protocol 4. The Protocol
In this section, the protocol for setting up an ESP association to be In this section, the protocol for setting up an ESP association to be
used with HIP association is described. used with HIP association is described.
4.1. ESP in HIP 4.1. ESP in HIP
4.1.1. Setting up an ESP Security Association 4.1.1. Setting up an ESP Security Association
skipping to change at page 13, line 9 skipping to change at page 13, line 9
parameter, containing the SPI value to be used by the peer host. parameter, containing the SPI value to be used by the peer host.
In the R2 message, the ESP SA setup is finalized. The packet In the R2 message, the ESP SA setup is finalized. The packet
contains the SPI information required by the Initiator for the ESP contains the SPI information required by the Initiator for the ESP
SA. SA.
4.1.2. Updating an Existing ESP SA 4.1.2. Updating an Existing ESP SA
The update process is accomplished using two messages. The HIP The update process is accomplished using two messages. The HIP
UPDATE message is used to update the parameters of an existing ESP UPDATE message is used to update the parameters of an existing ESP
SA. The UPDATE mechanism and message is defined in [5] and the SA. The UPDATE mechanism and message is defined in
additional parameters for updating an existing ESP SA are described [I-D.ietf-hip-base] and the additional parameters for updating an
here. existing ESP SA are described here.
The following picture shows a typical exchange when an existing ESP The following picture shows a typical exchange when an existing ESP
SA is updated. Messages include SEQ and ACK parameters required by SA is updated. Messages include SEQ and ACK parameters required by
the UPDATE mechanism. the UPDATE mechanism.
H1 H2 H1 H2
UPDATE: SEQ, ESP_INFO [, DIFFIE_HELLMAN] UPDATE: SEQ, ESP_INFO [, DIFFIE_HELLMAN]
-----------------------------------------------------> ----------------------------------------------------->
UPDATE: SEQ, ACK, ESP_INFO [, DIFFIE_HELLMAN] UPDATE: SEQ, ACK, ESP_INFO [, DIFFIE_HELLMAN]
skipping to change at page 13, line 33 skipping to change at page 13, line 33
UPDATE: ACK UPDATE: ACK
-----------------------------------------------------> ----------------------------------------------------->
The host willing to update the ESP SA creates and sends an UPDATE The host willing to update the ESP SA creates and sends an UPDATE
message. The message contains the ESP_INFO parameter, containing the 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 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 index value for the keying material, giving the point from where the
next keys will be drawn. If new keying material must be generated, next keys will be drawn. If new keying material must be generated,
the UPDATE message will also contain the DIFFIE_HELLMAN parameter, the UPDATE message will also contain the DIFFIE_HELLMAN parameter,
defined in [5]. defined in [I-D.ietf-hip-base].
The host receiving the UPDATE message requesting update of an The host receiving the UPDATE message requesting update of an
existing ESP SA, MUST reply with an UPDATE message. In the reply existing ESP SA, MUST reply with an UPDATE message. In the reply
message, the host sends the ESP_INFO parameter containing the message, the host sends the ESP_INFO parameter containing the
corresponding values: old SPI, new SPI, and the keying material corresponding values: old SPI, new SPI, and the keying material
index. If the incoming UPDATE contained a DIFFIE_HELLMAN parameter, index. If the incoming UPDATE contained a DIFFIE_HELLMAN parameter,
the reply packet MUST also contain a DIFFIE_HELLMAN parameter. the reply packet MUST also contain a DIFFIE_HELLMAN parameter.
5. Parameter and Packet Formats 5. Parameter and Packet Formats
In this section, new and modified HIP parameters are presented, as In this section, new and modified HIP parameters are presented, as
well as modified HIP packets. well as modified HIP packets.
5.1. New Parameters 5.1. New Parameters
Two new HIP parameters are defined for setting up ESP transport Two new HIP parameters are defined for setting up ESP transport
format associations in HIP communication and for rekeying existing format associations in HIP communication and for rekeying existing
ones. Also, the NOTIFY parameter, described in [5], has two new ones. Also, the NOTIFY parameter, described in [I-D.ietf-hip-base],
error parameters. has two new error parameters.
Parameter Type Length Data Parameter Type Length Data
ESP_INFO 65 12 Remote's old SPI, ESP_INFO 65 12 Remote's old SPI,
new SPI and other info new SPI and other info
ESP_TRANSFORM 4095 variable ESP Encryption and ESP_TRANSFORM 4095 variable ESP Encryption and
Authentication Transform(s) Authentication Transform(s)
5.1.1. ESP_INFO 5.1.1. ESP_INFO
skipping to change at page 14, line 39 skipping to change at page 14, line 39
generated keying material is the index value into the KEYMAT from generated keying material is the index value into the KEYMAT from
where the keys are drawn. The ESP_INFO parameter is used to transmit where the keys are drawn. The ESP_INFO parameter is used to transmit
this information between the hosts. this information between the hosts.
During the initial ESP SA setup, the hosts send the SPI value that 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 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 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 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 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 zero when additional SAs are set up between HIP hosts, e.g. in case
of multihomed HIP hosts [12]. However, such use is beyond the scope of multihomed HIP hosts [I-D.ietf-hip-mm]. However, such use is
of this specification. beyond the scope of this specification.
RFC4301 [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
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 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 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 is zero only when the ESP_INFO is sent during a rekeying process and
new keying material is generated. new keying material is generated.
During the life of an SA established by HIP, one of the hosts may 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 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 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 local policy on use of a key. Rekeying ends the current SAs and
skipping to change at page 16, line 23 skipping to change at page 17, line 23
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Suite-ID #n | Padding | | Suite-ID #n | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 4095 Type 4095
Length length in octets, excluding Type, Length, and Length length in octets, excluding Type, Length, and
padding padding
Reserved zero when sent, ignored when received Reserved zero when sent, ignored when received
Suite-ID defines the ESP Suite to be used Suite-ID defines the ESP Suite to be used
The following Suite-IDs are defined ([6],[8]): The following Suite-IDs are defined in [RFC2104] (HMAC-SHA1, HMAC-
MD5), [RFC3602] (AES-CBC), and [RFC2451] (3DES-CBC, Blowfish):
Suite-ID Value Suite-ID Value
RESERVED 0 RESERVED 0
ESP-AES-CBC with HMAC-SHA1 1 ESP-AES-CBC with HMAC-SHA1 1
ESP-3DES-CBC with HMAC-SHA1 2 ESP-3DES-CBC with HMAC-SHA1 2
ESP-3DES-CBC with HMAC-MD5 3 ESP-3DES-CBC with HMAC-MD5 3
ESP-BLOWFISH-CBC with HMAC-SHA1 4 ESP-BLOWFISH-CBC with HMAC-SHA1 4
ESP-NULL with HMAC-SHA1 5 ESP-NULL with HMAC-SHA1 5
ESP-NULL with HMAC-MD5 6 ESP-NULL with HMAC-MD5 6
skipping to change at page 16, line 48 skipping to change at page 17, line 49
parameters that contain more than six Suite-IDs. The limited number parameters that contain more than six Suite-IDs. The limited number
of Suite-IDs sets the maximum size of ESP_TRANSFORM parameter. As of Suite-IDs sets the maximum size of ESP_TRANSFORM parameter. As
the default configuration, the ESP_TRANSFORM parameter MUST contain the default configuration, the ESP_TRANSFORM parameter MUST contain
at least one of the mandatory Suite-IDs. There MAY be a at least one of the mandatory Suite-IDs. There MAY be a
configuration option that allows the administrator to override this configuration option that allows the administrator to override this
default. default.
Mandatory implementations: ESP-AES-CBC with HMAC-SHA1 and ESP-NULL Mandatory implementations: ESP-AES-CBC with HMAC-SHA1 and ESP-NULL
with HMAC-SHA1. 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 5.1.3. NOTIFY Parameter
The HIP base specification defines a set of NOTIFY error types. The The HIP base specification defines a set of NOTIFY error types. The
following error types are required for describing errors in ESP following error types are required for describing errors in ESP
Transform crypto suites during negotiation. Transform crypto suites during negotiation.
NOTIFY PARAMETER - ERROR TYPES Value NOTIFY PARAMETER - ERROR TYPES Value
------------------------------ ----- ------------------------------ -----
NO_ESP_PROPOSAL_CHOSEN 18 NO_ESP_PROPOSAL_CHOSEN 18
skipping to change at page 17, line 29 skipping to change at page 18, line 35
The ESP Security Association is set up during the base exchange. The The ESP Security Association is set up during the base exchange. The
following subsections define the ESP SA setup procedure both using following subsections define the ESP SA setup procedure both using
base exchange messages (R1, I2, R2) and using UPDATE messages. base exchange messages (R1, I2, R2) and using UPDATE messages.
5.2.1. Setup During Base Exchange 5.2.1. Setup During Base Exchange
5.2.1.1. Modifications in R1 5.2.1.1. Modifications in R1
The ESP_TRANSFORM contains the ESP modes supported by the sender, in The ESP_TRANSFORM contains the ESP modes supported by the sender, in
the order of preference. All implementations MUST support AES [3] the order of preference. All implementations MUST support AES-CBC
with HMAC-SHA-1-96 [2]. [RFC3602] with HMAC-SHA-1-96 [RFC2404].
The following figure shows the resulting R1 packet layout. The following figure shows the resulting R1 packet layout.
The HIP parameters for the R1 packet: The HIP parameters for the R1 packet:
IP ( HIP ( [ R1_COUNTER, ] IP ( HIP ( [ R1_COUNTER, ]
PUZZLE, PUZZLE,
DIFFIE_HELLMAN, DIFFIE_HELLMAN,
HIP_TRANSFORM, HIP_TRANSFORM,
ESP_TRANSFORM, ESP_TRANSFORM,
skipping to change at page 18, line 6 skipping to change at page 19, line 12
HIP_SIGNATURE_2 ) HIP_SIGNATURE_2 )
[, ECHO_REQUEST ]) [, ECHO_REQUEST ])
5.2.1.2. Modifications in I2 5.2.1.2. Modifications in I2
The ESP_INFO contains the sender's SPI for this association as well 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 as the keymat index from where the ESP SA keys will be drawn. The
Old SPI value is set to zero. Old SPI value is set to zero.
The ESP_TRANSFORM contains the ESP mode selected by the sender of R1. The ESP_TRANSFORM contains the ESP mode selected by the sender of R1.
All implementations MUST support AES [3] with HMAC-SHA-1-96 [2]. All implementations MUST support AES-CBC [RFC3602] with HMAC-SHA-1-96
[RFC2404].
The following figure shows the resulting I2 packet layout. The following figure shows the resulting I2 packet layout.
The HIP parameters for the I2 packet: The HIP parameters for the I2 packet:
IP ( HIP ( ESP_INFO, IP ( HIP ( ESP_INFO,
[R1_COUNTER,] [R1_COUNTER,]
SOLUTION, SOLUTION,
DIFFIE_HELLMAN, DIFFIE_HELLMAN,
HIP_TRANSFORM, HIP_TRANSFORM,
skipping to change at page 20, line 17 skipping to change at page 21, line 20
IP ( HIP ( ESP_INFO, IP ( HIP ( ESP_INFO,
SEQ, SEQ,
ACK, ACK,
[ DIFFIE_HELLMAN, ] [ DIFFIE_HELLMAN, ]
HMAC, HMAC,
HIP_SIGNATURE ) ) HIP_SIGNATURE ) )
5.4. ICMP Messages 5.4. ICMP Messages
The ICMP message handling is mainly described in the HIP base The ICMP message handling is mainly described in the HIP base
specification [5]. In this section, we describe the actions related specification [I-D.ietf-hip-base]. In this section, we describe the
to ESP security associations. actions related to ESP security associations.
5.4.1. Unknown SPI 5.4.1. Unknown SPI
If a HIP implementation receives an ESP packet that has an If a HIP implementation receives an ESP packet that has an
unrecognized SPI number, it MAY respond (subject to rate limiting the unrecognized SPI number, it MAY respond (subject to rate limiting the
responses) with an ICMP packet with type "Parameter Problem", with responses) with an ICMP packet with type "Parameter Problem", with
the Pointer pointing to the the beginning of SPI field in the ESP the Pointer pointing to the the beginning of SPI field in the ESP
header. header.
6. Packet Processing 6. Packet Processing
Packet processing is mainly defined in the HIP base specification Packet processing is mainly defined in the HIP base specification
[5]. This section describes the changes and new requirements for [I-D.ietf-hip-base]. This section describes the changes and new
packet handling when the ESP transport format is used. Note that all requirements for packet handling when the ESP transport format is
HIP packets (currently protocol 99) MUST bypass ESP processing. used. Note that all HIP packets (currently protocol 253) MUST bypass
ESP processing.
6.1. Processing Outgoing Application Data 6.1. Processing Outgoing Application Data
Outgoing application data handling is specified in the HIP base Outgoing application data handling is specified in the HIP base
specification [5]. When ESP transport format is used, and there is specification [I-D.ietf-hip-base]. When ESP transport format is
an active HIP session for the given < source, destination > HIT pair, used, and there is an active HIP session for the given < source,
the outgoing datagram is protected using the ESP security destination > HIT pair, the outgoing datagram is protected using the
association. In a typical implementation, this will result in a ESP security association. In a typical implementation, this will
BEET-mode ESP packet being sent. BEET-mode [11] was introduced above result in a BEET-mode ESP packet being sent. BEET-mode
in Section 3.2. [I-D.nikander-esp-beet-mode] was introduced above in Section 3.2.
1. Detect the proper ESP SA using the HITs in the packet header or 1. Detect the proper ESP SA using the HITs in the packet header or
other information associated with the packet other information associated with the packet
2. Process the packet normally, as if the SA was a transport mode 2. Process the packet normally, as if the SA was a transport mode
SA. SA.
3. Ensure that the outgoing ESP protected packet has proper IP 3. Ensure that the outgoing ESP protected packet has proper IP
header format depending on the used IP address family, and proper header format depending on the used IP address family, and proper
IP addresses in its IP header, e.g., by replacing HITs left by IP addresses in its IP header, e.g., by replacing HITs left by
skipping to change at page 22, line 32 skipping to change at page 23, line 33
datagram to the right upper layer socket is performed as usual, datagram to the right upper layer socket is performed as usual,
except that the HITs are used in place of IP addresses during the except that the HITs are used in place of IP addresses during the
demultiplexing. demultiplexing.
6.3. HMAC and SIGNATURE Calculation and Verification 6.3. HMAC and SIGNATURE Calculation and Verification
The new HIP parameters described in this document, ESP_INFO and The new HIP parameters described in this document, ESP_INFO and
ESP_TRANSFORM, must be protected using HMAC and signature ESP_TRANSFORM, must be protected using HMAC and signature
calculations. In a typical implementation, they are included in R1, calculations. In a typical implementation, they are included in R1,
I2, R2, and UPDATE packet HMAC and SIGNATURE calculations as I2, R2, and UPDATE packet HMAC and SIGNATURE calculations as
described in [5]. described in [I-D.ietf-hip-base].
6.4. Processing Incoming ESP SA Initialization (R1) 6.4. Processing Incoming ESP SA Initialization (R1)
The ESP SA setup is initialized in the R1 message. The receiving The ESP SA setup is initialized in the R1 message. The receiving
host (Initiator) select one of the ESP transforms from the presented host (Initiator) select one of the ESP transforms from the presented
values. If no suitable value is found, the negotiation is values. If no suitable value is found, the negotiation is
terminated. The selected values are subsequently used when terminated. The selected values are subsequently used when
generating and using encryption keys, and when sending the reply generating and using encryption keys, and when sending the reply
packet. If the proposed alternatives are not acceptable to the packet. If the proposed alternatives are not acceptable to the
system, it may abandon the ESP SA establishment negotiation, or it system, it may abandon the ESP SA establishment negotiation, or it
skipping to change at page 23, line 10 skipping to change at page 24, line 10
processing, the system prepares and creates an incoming ESP security processing, the system prepares and creates an incoming ESP security
association. It may also prepare a security association for outgoing association. It may also prepare a security association for outgoing
traffic, but since it does not have the correct SPI value yet, it traffic, but since it does not have the correct SPI value yet, it
cannot activate it. cannot activate it.
6.5. Processing Incoming Initialization Reply (I2) 6.5. Processing Incoming Initialization Reply (I2)
The following steps are required to process the incoming ESP SA The following steps are required to process the incoming ESP SA
initialization replies in I2. The steps below assume that the I2 has 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 been accepted for processing (e.g., has not been dropped due to HIT
comparisons as described in [5]). comparisons as described in [I-D.ietf-hip-base]).
o The ESP_TRANSFORM parameter is verified and it MUST contain a 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 single value in the parameter and it MUST match one of the values
offered in the initialization packet. offered in the initialization packet.
o The ESP_INFO New SPI field is parsed to obtain the SPI that will 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 be used for the Security Association outbound from the Responder
and inbound to the Initiator. For this initial ESP SA and inbound to the Initiator. For this initial ESP SA
establishment, the Old SPI value MUST be zero. The Keymat Index establishment, the Old SPI value MUST be zero. The Keymat Index
field MUST contain the index value to the KEYMAT from where the field MUST contain the index value to the KEYMAT from where the
skipping to change at page 24, line 11 skipping to change at page 25, line 11
A system may initiate the SA rekeying procedure at any time. It MUST 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 initiate a rekey if its incoming ESP sequence counter is about to
overflow. The system MUST NOT replace its keying material until the overflow. The system MUST NOT replace its keying material until the
rekeying packet exchange successfully completes. rekeying packet exchange successfully completes.
Optionally, a system may include a new Diffie-Hellman key for use in Optionally, a system may include a new Diffie-Hellman key for use in
new KEYMAT generation. New KEYMAT generation occurs prior to drawing new KEYMAT generation. New KEYMAT generation occurs prior to drawing
the new keys. the new keys.
The rekeying procedure uses the UPDATE mechanism defined in [5]. The rekeying procedure uses the UPDATE mechanism defined in
Because each peer must update its half of the security association [I-D.ietf-hip-base]. Because each peer must update its half of the
pair (including new SPI creation), the rekeying process requires that security association pair (including new SPI creation), the rekeying
each side both send and receive an UPDATE. A system will then rekey process requires that each side both send and receive an UPDATE. A
the ESP SA when it has sent parameters to the peer and has received system will then rekey the ESP SA when it has sent parameters to the
both an ACK of the relevant UPDATE message and corresponding peer's peer and has received both an ACK of the relevant UPDATE message and
parameters. It may be that the ACK and the required HIP parameters corresponding peer's parameters. It may be that the ACK and the
arrive in different UPDATE messages. This is always true if a system required HIP parameters arrive in different UPDATE messages. This is
does not initiate ESP SA update but responds to an update request always true if a system does not initiate ESP SA update but responds
from the peer, but may also occur if two systems initiate update to an update request from the peer, but may also occur if two systems
nearly simultaneously. In such a case, if the system has an initiate update nearly simultaneously. In such a case, if the system
outstanding update request, it saves the one parameter and waits for has an outstanding update request, it saves the one parameter and
the other before completing rekeying. waits for the other before completing rekeying.
The following steps define the processing rules for initiating an ESP The following steps define the processing rules for initiating an ESP
SA update: SA update:
1. The system decides whether to continue to use the existing KEYMAT 1. The system decides whether to continue to use the existing KEYMAT
or to generate new KEYMAT. In the latter case, the system MUST or to generate new KEYMAT. In the latter case, the system MUST
generate a new Diffie-Hellman public key. generate a new Diffie-Hellman public key.
2. The system creates an UPDATE packet, which contains the ESP_INFO 2. The system creates an UPDATE packet, which contains the ESP_INFO
parameter. In addition, the host may include the optional parameter. In addition, the host may include the optional
skipping to change at page 25, line 19 skipping to change at page 26, line 19
oustanding ESP SA update request for an indefinite time. oustanding ESP SA update request for an indefinite time.
To simplify the state machine, a host MUST NOT generate new UPDATEs To simplify the state machine, a host MUST NOT generate new UPDATEs
while it has an outstanding ESP SA update request, unless it is while it has an outstanding ESP SA update request, unless it is
restarting the update process. restarting the update process.
6.9. Processing Incoming UPDATE Packets 6.9. Processing Incoming UPDATE Packets
When a system receives an UPDATE packet, it must be processed if the When a system receives an UPDATE packet, it must be processed if the
following conditions hold (in addition to the generic conditions following conditions hold (in addition to the generic conditions
specified for UPDATE processing in Section 6.12 of [5]): specified for UPDATE processing in Section 6.12 of
[I-D.ietf-hip-base]):
1. A corresponding HIP association must exist. This is usually 1. A corresponding HIP association must exist. This is usually
ensured by the underlying UPDATE mechanism. ensured by the underlying UPDATE mechanism.
2. The state of the HIP association is ESTABLISHED or R2-SENT. 2. The state of the HIP association is ESTABLISHED or R2-SENT.
If the above conditions hold, the following steps define the If the above conditions hold, the following steps define the
conceptual processing rules for handling the received UPDATE packet: conceptual processing rules for handling the received UPDATE packet:
1. If the received UPDATE contains a DIFFIE_HELLMAN parameter, the 1. If the received UPDATE contains a DIFFIE_HELLMAN parameter, the
skipping to change at page 29, line 7 skipping to change at page 30, line 7
apply: apply:
AES 128 bits AES 128 bits
SHA-1 160 bits SHA-1 160 bits
NULL 0 bits NULL 0 bits
8. Security Considerations 8. Security Considerations
In this document the usage of ESP [4] between HIP hosts to protect In this document the usage of ESP [RFC4303] between HIP hosts to
data traffic is introduced. The Security Considerations for ESP are protect data traffic is introduced. The Security Considerations for
discussed in the ESP specification. ESP are discussed in the ESP specification.
There are different ways to establish an ESP Security Association There are different ways to establish an ESP Security Association
between two nodes. This can be done, e.g. using IKE [10]. This between two nodes. This can be done, e.g. using IKE [RFC4306]. This
document specifies how Host Identity Protocol is used to establish document specifies how Host Identity Protocol is used to establish
ESP Security Associations. ESP Security Associations.
The following issues are new, or changed from the standard ESP usage: The following issues are new, or changed from the standard ESP usage:
o Initial keying material generation o Initial keying material generation
o Updating the keying material o Updating the keying material
The initial keying material is generated using the Host Identity The initial keying material is generated using the Host Identity
Protocol [5] using Diffie-Hellman procedure. This document extends Protocol [I-D.ietf-hip-base] using Diffie-Hellman procedure. This
the usage of UDPATE packet, defined in the base specification, to document extends the usage of UDPATE packet, defined in the base
modify existing ESP SAs. The hosts may rekey, i.e. force the specification, to modify existing ESP SAs. The hosts may rekey, i.e.
generation of new keying material using Diffie-Hellman procedure. force the generation of new keying material using Diffie-Hellman
The initial setup of ESP SA between the hosts is done during the base procedure. The initial setup of ESP SA between the hosts is done
ecxhange and the message exchange is protected with using methods during the base ecxhange and the message exchange is protected with
provided by base exchange. Changing of connection parameters means using methods provided by base exchange. Changing of connection
basically that the old ESP SA is removed and a new one is generated parameters means basically that the old ESP SA is removed and a new
once the UPDATE message exchange has been completed. The message one is generated once the UPDATE message exchange has been completed.
exchange is protected using the HIP association keys. Both HMAC and The message exchange is protected using the HIP association keys.
signing of packets is used. Both HMAC and signing of packets is used.
9. IANA Considerations 9. IANA Considerations
This document defines additional parameters for the Host Identity This document defines additional parameters and NOTIFY error types
Protocol [5]. These parameters are defined in Section 5.1.1 and for the Host Identity Protocol [I-D.ietf-hip-base].
Section 5.1.2 with the following numbers:
o ESP_INFO is 65. The new parameters and their type numbers are defined in
Section 5.1.1 and Section 5.1.2 and they are added in the Parameter
Type namespace, specified in [I-D.ietf-hip-base].
o ESP_TRANSFORM is 4095. The new NOTFY error types and their values are defined in
Section 5.1.3 and they are added in Notify Message Type namespace,
specified in [I-D.ietf-hip-base].
10. Acknowledgments 10. Acknowledgments
This document was separated from the base "Host Identity Protocol" This document was separated from the base "Host Identity Protocol"
specification in the beginning of 2005. Since then, a number of specification in the beginning of 2005. Since then, a number of
people have contributed to the text by giving comments and people have contributed to the text by giving comments and
modification proposals. The list of people include Tom Henderson, modification proposals. The list of people include Tom Henderson,
Jeff Ahrenholz, Jan Melen, Jukka Ylitalo, and Miika Komu. Authors Jeff Ahrenholz, Jan Melen, Jukka Ylitalo, and Miika Komu. Authors
want also thank Charlie Kaufman for reviewing the document with the want also thank Charlie Kaufman for reviewing the document with the
eye on the usage of crypto algorithms. eye on the usage of crypto algorithms.
skipping to change at page 32, line 9 skipping to change at page 33, line 9
Due to the history of this document, most of the ideas are inherited Due to the history of this document, most of the ideas are inherited
from the base "Host Identity Protocol" specification. Thus the list from the base "Host Identity Protocol" specification. Thus the list
of people in the Acknowledgments section of that specification is of people in the Acknowledgments section of that specification is
also valid for this document. Many people have given valueable also valid for this document. Many people have given valueable
feedback, and our apologies for anyone whose name is missing. feedback, and our apologies for anyone whose name is missing.
11. References 11. References
11.1. Normative references 11.1. Normative references
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
and AH", RFC 2404, November 1998. ESP and AH", RFC 2404, November 1998.
[3] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
Algorithm and Its Use with IPsec", RFC 3602, September 2003. Algorithm and Its Use with IPsec", RFC 3602,
September 2003.
[4] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
draft-ietf-ipsec-esp-v3-10 (work in progress), March 2005. RFC 4303, December 2005.
[5] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-06 [I-D.ietf-hip-base]
(work in progress), June 2006. Moskowitz, R., "Host Identity Protocol",
draft-ietf-hip-base-06 (work in progress), June 2006.
[6] Schiller, J., "Cryptographic Algorithms for use in the Internet 11.2. Informative references
Key Exchange Version 2", draft-ietf-ipsec-ikev2-algorithms-05
(work in progress), April 2004.
[7] Moskowitz, R. and P. Nikander, "Host Identity Protocol [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
Architecture", draft-ietf-hip-arch-03 (work in progress), Algorithms", RFC 2451, November 1998.
August 2005.
[8] Schneier, B., "Applied Cryptography Second Edition: protocols [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
algorithms and source in code in C", 1996. Hashing for Message Authentication", RFC 2104,
February 1997.
11.2. Informative references [I-D.ietf-ipsec-rfc2401bis]
Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", draft-ietf-ipsec-rfc2401bis-06 (work
in progress), April 2005.
[9] Kent, S. and K. Seo, "Security Architecture for the Internet [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
Protocol", draft-ietf-ipsec-rfc2401bis-06 (work in progress), RFC 4306, December 2005.
April 2005.
[10] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
RFC 2409, November 1998. Internet Protocol", RFC 4301, December 2005.
[11] Melen, J. and P. Nikander, "A Bound End-to-End Tunnel (BEET) [I-D.nikander-esp-beet-mode]
mode for ESP", draft-nikander-esp-beet-mode-06 (work in Melen, J. and P. Nikander, "A Bound End-to-End Tunnel
progress), August 2006. (BEET) mode for ESP", draft-nikander-esp-beet-mode-06
(work in progress), August 2006.
[12] Nikander, P., "End-Host Mobility and Multihoming with the Host [I-D.ietf-hip-mm]
Identity Protocol", draft-ietf-hip-mm-04 (work in progress), Nikander, P., "End-Host Mobility and Multihoming with the
June 2006. Host Identity Protocol", draft-ietf-hip-mm-04 (work in
progress), June 2006.
[RFC3260] Grossman, D., "New Terminology and Clarifications for
Diffserv", RFC 3260, April 2002.
[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.
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, May 2006.
Appendix A. A Note on Implementation Options Appendix A. A Note on Implementation Options
It is possible to implement this specification in multiple different It is possible to implement this specification in multiple different
ways. As noted above, one possible way of implementing is to rewrite ways. As noted above, one possible way of implementing is to rewrite
IP headers below IPsec. In such an implementation, IPsec is used as IP headers below IPsec. In such an implementation, IPsec is used as
if it was processing IPv6 transport mode packets, with the IPv6 if it was processing IPv6 transport mode packets, with the IPv6
header containing HITs instead of IP addresses in the source and header containing HITs instead of IP addresses in the source and
destionation address fields. In outgoing packets, after IPsec destionation address fields. In outgoing packets, after IPsec
processing, the HITs are replaced with actual IP addresses, based on processing, the HITs are replaced with actual IP addresses, based on
the HITs and the SPI. In incoming packets, before IPsec processing, the HITs and the SPI. In incoming packets, before IPsec processing,
the IP addresses are replaced with HITs, based on the SPI in the the IP addresses are replaced with HITs, based on the SPI in the
incoming packet. In such an implementation, all IPsec policies are incoming packet. In such an implementation, all IPsec policies are
based on HITs and the upper layers only see packets with HITs in the based on HITs and the upper layers only see packets with HITs in the
place of IP addresses. Consequently, support of HIP does not place of IP addresses. Consequently, support of HIP does not
conflict with other use of IPsec as long as the SPI spaces are kept conflict with other use of IPsec as long as the SPI spaces are kept
separate. separate.
Another way for implementing is to use the proposed BEET mode (A Another way for implementing is to use the proposed BEET mode (A
Bound End-to-End mode for ESP) [11]. The BEET mode provides some Bound End-to-End mode for ESP) [I-D.nikander-esp-beet-mode]. The
features from both IPsec tunnel and transport modes. The HIP uses BEET mode provides some features from both IPsec tunnel and transport
HITs as the "inner" addresses and IP addresses as "outer" addresses modes. The HIP uses HITs as the "inner" addresses and IP addresses
like IP addresses are used in the tunnel mode. Instead of tunneling as "outer" addresses like IP addresses are used in the tunnel mode.
packets between hosts, a conversion between inner and outer addresses Instead of tunneling packets between hosts, a conversion between
is made at end-hosts and the inner address is never sent in the wire inner and outer addresses is made at end-hosts and the inner address
after the initial HIP negotiation. BEET provides IPsec transport is never sent in the wire after the initial HIP negotiation. BEET
mode syntax (no inner headers) with limited tunnel mode semantics provides IPsec transport mode syntax (no inner headers) with limited
(fixed logical inner addresses - the HITs - and changeable outer IP tunnel mode semantics (fixed logical inner addresses - the HITs - and
addresses). changeable outer IP addresses).
Compared to the option of implementing the required address rewrites Compared to the option of implementing the required address rewrites
outside of IPsec, BEET has one implementation level benefit. The outside of IPsec, BEET has one implementation level benefit. The
BEET-way of implementing the address rewriting keeps all the BEET-way of implementing the address rewriting keeps all the
configuration information in one place, at the SADB. On the other configuration information in one place, at the SADB. On the other
hand, when address rewriting is implemented separately, the hand, when address rewriting is implemented separately, the
implementation must make sure that the information in the SADB and implementation must make sure that the information in the SADB and
the separate address rewriting DB are kept in synchrony. As a the separate address rewriting DB are kept in synchrony. As a
result, the BEET mode based way of implementing is RECOMMENDED over result, the BEET mode based way of implementing is RECOMMENDED over
the separate implementation. the separate implementation.
skipping to change at page 35, line 5 skipping to change at page 37, line 5
Email: rgm@icsalabs.com Email: rgm@icsalabs.com
Pekka Nikander Pekka Nikander
Ericsson Research NomadicLab Ericsson Research NomadicLab
JORVAS FIN-02420 JORVAS FIN-02420
FINLAND FINLAND
Phone: +358 9 299 1 Phone: +358 9 299 1
Email: pekka.nikander@nomadiclab.com Email: pekka.nikander@nomadiclab.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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 The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 35, line 29 skipping to change at page 37, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 58 change blocks. 
195 lines changed or deleted 248 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/