draft-ietf-hip-rfc5202-bis-01.txt   draft-ietf-hip-rfc5202-bis-02.txt 
Network Working Group P. Jokela Network Working Group P. Jokela
Internet-Draft Ericsson Research NomadicLab Internet-Draft Ericsson Research NomadicLab
Intended status: Standards Track R. Moskowitz Intended status: Standards Track R. Moskowitz
Expires: March 31, 2013 ICSAlabs, An Independent Expires: December 12, 2013 ICSAlabs, An Independent
Division of Verizon Business Division of Verizon Business
Systems Systems
J. Melen J. Melen
Ericsson Research NomadicLab Ericsson Research NomadicLab
September 27, 2012 June 10, 2013
Using the Encapsulating Security Payload (ESP) Transport Format with the Using the Encapsulating Security Payload (ESP) Transport Format with the
Host Identity Protocol (HIP) Host Identity Protocol (HIP)
draft-ietf-hip-rfc5202-bis-01 draft-ietf-hip-rfc5202-bis-02
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).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on March 31, 2013. This Internet-Draft will expire on December 12, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 4 2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Using ESP with HIP . . . . . . . . . . . . . . . . . . . . . . 4 3. Using ESP with HIP . . . . . . . . . . . . . . . . . . . . . . 5
3.1. ESP Packet Format . . . . . . . . . . . . . . . . . . . . 5 3.1. ESP Packet Format . . . . . . . . . . . . . . . . . . . . 5
3.2. Conceptual ESP Packet Processing . . . . . . . . . . . . . 5 3.2. Conceptual ESP Packet Processing . . . . . . . . . . . . . 5
3.2.1. Semantics of the Security Parameter Index (SPI) . . . 6 3.2.1. Semantics of the Security Parameter Index (SPI) . . . 6
3.3. Security Association Establishment and Maintenance . . . . 6 3.3. Security Association Establishment and Maintenance . . . . 7
3.3.1. ESP Security Associations . . . . . . . . . . . . . . 6 3.3.1. ESP Security Associations . . . . . . . . . . . . . . 7
3.3.2. Rekeying . . . . . . . . . . . . . . . . . . . . . . . 7 3.3.2. Rekeying . . . . . . . . . . . . . . . . . . . . . . . 7
3.3.3. Security Association Management . . . . . . . . . . . 8 3.3.3. Security Association Management . . . . . . . . . . . 8
3.3.4. Security Parameter Index (SPI) . . . . . . . . . . . . 8 3.3.4. Security Parameter Index (SPI) . . . . . . . . . . . . 8
3.3.5. Supported Transforms . . . . . . . . . . . . . . . . . 8 3.3.5. Supported Ciphers . . . . . . . . . . . . . . . . . . 9
3.3.6. Sequence Number . . . . . . . . . . . . . . . . . . . 9 3.3.6. Sequence Number . . . . . . . . . . . . . . . . . . . 9
3.3.7. Lifetimes and Timers . . . . . . . . . . . . . . . . . 9 3.3.7. Lifetimes and Timers . . . . . . . . . . . . . . . . . 9
3.4. IPsec and HIP ESP Implementation Considerations . . . . . 9 3.4. IPsec and HIP ESP Implementation Considerations . . . . . 9
3.4.1. Data Packet Processing Considerations . . . . . . . . 10 3.4.1. Data Packet Processing Considerations . . . . . . . . 10
3.4.2. HIP Signaling Packet Considerations . . . . . . . . . 10 3.4.2. HIP Signaling Packet Considerations . . . . . . . . . 10
4. The Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. The Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. ESP in HIP . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. ESP in HIP . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.1. Setting Up an ESP Security Association . . . . . . . . 11 4.1.1. Setting Up an ESP Security Association . . . . . . . . 11
4.1.2. Updating an Existing ESP SA . . . . . . . . . . . . . 12 4.1.2. Updating an Existing ESP SA . . . . . . . . . . . . . 12
5. Parameter and Packet Formats . . . . . . . . . . . . . . . . . 12 5. Parameter and Packet Formats . . . . . . . . . . . . . . . . . 13
5.1. New Parameters . . . . . . . . . . . . . . . . . . . . . . 12 5.1. New Parameters . . . . . . . . . . . . . . . . . . . . . . 13
5.1.1. ESP_INFO . . . . . . . . . . . . . . . . . . . . . . . 13 5.1.1. ESP_INFO . . . . . . . . . . . . . . . . . . . . . . . 13
5.1.2. ESP_TRANSFORM . . . . . . . . . . . . . . . . . . . . 15 5.1.2. ESP_TRANSFORM . . . . . . . . . . . . . . . . . . . . 14
5.1.3. NOTIFY Parameter . . . . . . . . . . . . . . . . . . . 16 5.1.3. NOTIFICATION Parameter . . . . . . . . . . . . . . . . 16
5.2. HIP ESP Security Association Setup . . . . . . . . . . . . 16 5.2. HIP ESP Security Association Setup . . . . . . . . . . . . 16
5.2.1. Setup During Base Exchange . . . . . . . . . . . . . . 16 5.2.1. Setup During Base Exchange . . . . . . . . . . . . . . 16
5.3. HIP ESP Rekeying . . . . . . . . . . . . . . . . . . . . . 18 5.3. HIP ESP Rekeying . . . . . . . . . . . . . . . . . . . . . 18
5.3.1. Initializing Rekeying . . . . . . . . . . . . . . . . 18 5.3.1. Initializing Rekeying . . . . . . . . . . . . . . . . 18
5.3.2. Responding to the Rekeying Initialization . . . . . . 19 5.3.2. Responding to the Rekeying Initialization . . . . . . 19
5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 19 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 19
5.4.1. Unknown SPI . . . . . . . . . . . . . . . . . . . . . 19 5.4.1. Unknown SPI . . . . . . . . . . . . . . . . . . . . . 19
6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 19 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Processing Outgoing Application Data . . . . . . . . . . . 20 6.1. Processing Outgoing Application Data . . . . . . . . . . . 20
6.2. Processing Incoming Application Data . . . . . . . . . . . 20 6.2. Processing Incoming Application Data . . . . . . . . . . . 20
skipping to change at page 3, line 21 skipping to change at page 3, line 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
11.1. Normative references . . . . . . . . . . . . . . . . . . . 28 11.1. Normative references . . . . . . . . . . . . . . . . . . . 28
11.2. Informative references . . . . . . . . . . . . . . . . . . 28 11.2. Informative references . . . . . . . . . . . . . . . . . . 28
Appendix A. A Note on Implementation Options . . . . . . . . . . 29 Appendix A. A Note on Implementation Options . . . . . . . . . . 29
Appendix B. Bound End-to-End Tunnel mode for ESP . . . . . . . . 29 Appendix B. Bound End-to-End Tunnel mode for ESP . . . . . . . . 29
B.1. Protocol definition . . . . . . . . . . . . . . . . . . . 30 B.1. Protocol definition . . . . . . . . . . . . . . . . . . . 30
B.1.1. Changes to Security Association data structures . . . 30 B.1.1. Changes to Security Association data structures . . . 30
B.1.2. Packet format . . . . . . . . . . . . . . . . . . . . 30 B.1.2. Packet format . . . . . . . . . . . . . . . . . . . . 31
B.1.3. Cryptographic processing . . . . . . . . . . . . . . . 32 B.1.3. Cryptographic processing . . . . . . . . . . . . . . . 32
B.1.4. IP header processing . . . . . . . . . . . . . . . . . 32 B.1.4. IP header processing . . . . . . . . . . . . . . . . . 33
B.1.5. Handling of outgoing packets . . . . . . . . . . . . . 33 B.1.5. Handling of outgoing packets . . . . . . . . . . . . . 33
B.1.6. Handling of incoming packets . . . . . . . . . . . . . 34 B.1.6. Handling of incoming packets . . . . . . . . . . . . . 34
B.1.7. IPv4 options handling . . . . . . . . . . . . . . . . 35 B.1.7. IPv4 options handling . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
In the Host Identity Protocol Architecture In the Host Identity Protocol Architecture
[I-D.ietf-hip-rfc4423-bis], hosts are identified with public keys. [I-D.ietf-hip-rfc4423-bis], hosts are identified with public keys.
The Host Identity Protocol [I-D.ietf-hip-rfc5201-bis] base exchange The Host Identity Protocol [I-D.ietf-hip-rfc5201-bis] base exchange
allows any two HIP-supporting hosts to authenticate each other and to allows any two HIP-supporting hosts to authenticate each other and to
skipping to change at page 4, line 40 skipping to change at page 4, line 40
update an existing ESP Security Association. update an existing ESP Security Association.
It should be noted that representations of Host Identity are not It should be noted that representations of Host Identity are not
carried explicitly in the headers of user data packets. Instead, the carried explicitly in the headers of user data packets. Instead, the
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.
HIP and ESP traffic have known issues with middlebox traversal RFC
5207 [RFC5207]. Other specifications exist for operating HIP and ESP
over UDP (RFC 5770 [RFC5770] is an experimental specification, and
others are being developed). Middlebox traversal is out of scope for
this document.
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 RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [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, protecting data communication between the hosts. In this document,
we specify the use of ESP for protecting user data traffic after the 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 HIP base exchange. Note that this use of ESP is intended only for
host-to-host traffic; security gateways are not supported. host-to-host traffic; security gateways are not supported.
To support ESP use, the HIP base exchange messages require some minor To support ESP use, the HIP base exchange messages require some minor
additions to the parameters transported. In the R1 packet, the additions to the parameters transported. In the R1 packet, the
Responder adds the possible ESP transforms in a npew ESP_TRANSFORM Responder adds the possible ESP transforms in an ESP_TRANSFORM
parameter before sending it to the Initiator. The Initiator gets the parameter before sending it to the Initiator. The Initiator gets the
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 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 [RFC4303] defines the ESP packet format for The ESP specification [RFC4303] defines the ESP packet format for
IPsec. The HIP ESP packet looks exactly the same as the IPsec ESP IPsec. The HIP ESP packet looks exactly the same as the IPsec ESP
transport format packet. The semantics, however, are a bit different transport format packet. The semantics, however, are a bit different
and are 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 [RFC4303] can be used. unmodified IPsec implementation [RFC4303] can be used in conjunction
with some additional transport checksum processing above it, and if
IP addresses are used as indexes to the right host context.
When a standards compliant IPsec implementation that uses IP When a standards compliant IPsec implementation that uses IP
addresses in the SPD and Security Association Database (SAD) is used, addresses in the SPD and Security Association Database (SAD) is used,
the packet processing may take the following steps. For outgoing the packet processing may take the following steps. For outgoing
packets, assuming that the upper-layer pseudoheader has been built packets, assuming that the upper-layer pseudoheader has been built
using IP addresses, the implementation recalculates upper-layer using IP addresses, the implementation recalculates upper-layer
checksums using Host Identity Tags (HITs) and, after that, changes checksums using Host Identity Tags (HITs) and, after that, changes
the packet source and destination addresses back to corresponding IP the packet source and destination addresses back to corresponding IP
addresses. The packet is sent to the IPsec ESP for transport mode addresses. The packet is sent to the IPsec ESP for transport mode
handling and from there the encrypted packet is sent to the network. handling and from there the encrypted packet is sent to the network.
skipping to change at page 8, line 34 skipping to change at page 8, line 43
An SA pair is indexed by the 2 SPIs and 2 HITs (both local and remote 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 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 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. SA, a timer is set to allow for any late arriving packets.
3.3.4. Security Parameter Index (SPI) 3.3.4. Security Parameter Index (SPI)
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 Internet Key Exchange (IKE)
[RFC5996].
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 peer.
3.3.5. Supported Transforms 3.3.5. Supported Ciphers
All HIP implementations MUST support AES-128-CBC [RFC3602] and HMAC- All HIP implementations MUST support AES-128-CBC and AES-256-CBC
SHA1 [RFC2404]. If the Initiator does not support any of the [RFC3602]. If the Initiator does not support any of the transforms
transforms offered by the Responder, it should abandon the offered by the Responder, it should abandon the negotiation and
negotiation and inform the peer with a NOTIFY message about a non- inform the peer with a NOTIFY message about a non-supported
supported transform. transform.
In addition to AES-128-CBC, all implementations MUST implement the In addition to AES-128-CBC, all implementations MUST implement the
ESP NULL encryption algorithm. When the ESP NULL encryption is used, ESP NULL encryption algorithm. When the ESP NULL encryption is used,
it MUST be used together with SHA1 authentication as specified in it MUST be used together with SHA-256 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 [RFC4301]. See [RFC4301].
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. Implementations SHOULD support a
Implementations MAY support lifetimes for the various ESP transforms. configurable SA timeout value. Implementations MAY support lifetimes
Each implementation SHOULD implement per-HIT configuration of the for the various ESP transforms. Each implementation SHOULD implement
inactivity timeout, allowing statically configured HIP associations per-HIT configuration of the inactivity timeout, allowing statically
to stay alive for days, even when inactive. configured HIP associations to stay alive for days, even when
inactive.
3.4. IPsec and HIP ESP Implementation Considerations 3.4. IPsec and HIP ESP Implementation Considerations
When HIP is run on a node where a standards compliant IPsec is used, When HIP is run on a node where a standards compliant IPsec is used,
some issues have to be considered. some issues have to be considered.
The HIP implementation must be able to co-exist with other IPsec The HIP implementation must be able to co-exist with other IPsec
keying protocols. When the HIP implementation selects the SPI value, keying protocols. When the HIP implementation selects the SPI value,
it may lead to a collision if not implemented properly. To avoid the it may lead to a collision if not implemented properly. To avoid the
possibility for a collision, the HIP implementation MUST ensure that possibility for a collision, the HIP implementation MUST ensure that
skipping to change at page 12, line 51 skipping to change at page 13, line 14
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 ones. Also, the NOTIFICATION parameter, described in
[I-D.ietf-hip-rfc5201-bis], has two new error parameters. [I-D.ietf-hip-rfc5201-bis], 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
During the establishment and update of an ESP SA, the SPI value of During the establishment and update of an ESP SA, the SPI value of
both hosts must be transmitted between the hosts. During the both hosts must be transmitted between the hosts. In addition, hosts
establishment and update of an ESP SA, the SPI value of both hosts need the index value to the KEYMAT when they are drawing keys from
must be transmitted between the hosts. In addition, hosts need the the generated keying material. The ESP_INFO parameter is used to
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 transmit the SPI values and the KEYMAT index information between the
hosts. 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 [RFC5206]. However, such use is beyond the of multihomed HIP hosts [RFC5206]. However, such use is beyond the
scope of this specification. 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
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
starts new ones on both peers. starts new ones on both peers.
skipping to change at page 15, line 36 skipping to change at page 15, line 29
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 can be used: The following Suite IDs can be used:
Suite ID Value Suite ID Value
RESERVED 0 RESERVED 0
AES-128-CBC with HMAC-SHA1 1 [RFC3602], [RFC2404] AES-128-CBC with HMAC-SHA1 1 [RFC3602], [RFC2404]
3DES-CBC with HMAC-SHA1 2 [RFC2451], [RFC2404] DEPRECATED 2
DEPRECATED 3 DEPRECATED 3
DEPRECATED 4 DEPRECATED 4
NULL-ENCRYPT with HMAC-SHA1 5 [RFC2410], [RFC2404] DEPRECATED 5
DEPRECATED 6 DEPRECATED 6
NULL-ENCRYPT with HMAC-SHA2 7 [RFC2410], [RFC4868] NULL-ENCRYPT with HMAC-SHA-256 7 [RFC2410], [RFC4868]
AES-128-CBC with HMAC-SHA2 8 [RFC3602], [RFC4868] AES-128-CBC with HMAC-SHA-256 8 [RFC3602], [RFC4868]
AES-256-CBC with HMAC-SHA2 9 [RFC3602], [RFC4868] AES-256-CBC with HMAC-SHA-256 9 [RFC3602], [RFC4868]
AES-CCM-8 10 [RFC4309] AES-CCM-8 10 [RFC4309]
AES-CCM-16 11 [RFC4309] AES-CCM-16 11 [RFC4309]
AES-GCM with a 8 octet ICV 12 [RFC4106] AES-GCM with a 8 octet ICV 12 [RFC4106]
AES-GCM with a 16 octet ICV 13 [RFC4106] AES-GCM with a 16 octet ICV 13 [RFC4106]
The sender of an ESP transform parameter MUST make sure that there 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. are no more than six (6) Suite IDs in one ESP transform parameter.
Conversely, a recipient MUST be prepared to handle received transform Conversely, a recipient MUST be prepared to handle received transform
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 the ESP_TRANSFORM parameter. of Suite IDs sets the maximum size of the ESP_TRANSFORM parameter.
As the default configuration, the ESP_TRANSFORM parameter MUST As the default configuration, the ESP_TRANSFORM parameter MUST
contain at least one of the mandatory Suite IDs. There MAY be a contain 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: AES-CBC with HMAC-SHA1 and NULL with HMAC- Mandatory implementations: AES-128-CBC with HMAC-SHA-256 and NULL
SHA1. with HMAC-SHA-256.
Under some conditions, it is possible to use Traffic Flow Under some conditions, it is possible to use Traffic Flow
Confidentiality (TFC) [RFC4303] with ESP in BEET mode. However, the Confidentiality (TFC) [RFC4303] with ESP in BEET mode. However, the
definition of such operation is future work and must be done in a definition of such operation is future work and must be done in a
separate specification. separate specification.
5.1.3. NOTIFY Parameter 5.1.3. NOTIFICATION Parameter
The HIP base specification defines a set of NOTIFY error types. The The HIP base specification defines a set of NOTIFICATION error types.
following error types are required for describing errors in ESP The 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 NOTIFICATION PARAMETER - ERROR TYPES Value
------------------------------ ----- ------------------------------------ -----
NO_ESP_PROPOSAL_CHOSEN 18 NO_ESP_PROPOSAL_CHOSEN 18
None of the proposed ESP Transform crypto suites was None of the proposed ESP Transform crypto suites was
acceptable. acceptable.
INVALID_ESP_TRANSFORM_CHOSEN 19 INVALID_ESP_TRANSFORM_CHOSEN 19
The ESP Transform crypto suite does not correspond to The ESP Transform crypto suite does not correspond to
one offered by the Responder. one offered by the Responder.
skipping to change at page 16, line 48 skipping to change at page 16, line 41
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 using both following subsections define the ESP SA setup procedure using both
base exchange messages (R1, I2, R2) and UPDATE messages. base exchange messages (R1, I2, R2) and 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-CBC the order of preference. All implementations MUST support AES-128-
[RFC3602] with HMAC-SHA1 [RFC2404]. CBC [RFC3602] with HMAC-SHA-256 [RFC4868].
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_CIPHER,
ESP_TRANSFORM, ESP_TRANSFORM,
HOST_ID, HOST_ID,
[ ECHO_REQUEST, ] [ ECHO_REQUEST, ]
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-CBC [RFC3602] with HMAC-SHA1 All implementations MUST support AES-128-CBC [RFC3602] with HMAC-SHA-
[RFC2404]. 256 [RFC4868].
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_CIPHER,
ESP_TRANSFORM, ESP_TRANSFORM,
ENCRYPTED { HOST_ID }, ENCRYPTED { HOST_ID },
[ ECHO_RESPONSE ,] [ ECHO_RESPONSE ,]
HMAC, HMAC,
HIP_SIGNATURE HIP_SIGNATURE
[, ECHO_RESPONSE] ) ) [, ECHO_RESPONSE] ) )
5.2.1.3. Modifications in R2 5.2.1.3. Modifications in R2
The R2 contains an ESP_INFO parameter, which has the SPI value of the The R2 contains an ESP_INFO parameter, which has the SPI value of the
skipping to change at page 19, line 48 skipping to change at page 19, line 47
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 beginning of SPI field in the ESP header. the pointer pointing to the beginning of SPI field in the ESP 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
[I-D.ietf-hip-rfc5201-bis]. This section describes the changes and [I-D.ietf-hip-rfc5201-bis]. This section describes the changes and
new requirements for packet handling when the ESP transport format is new requirements for packet handling when the ESP transport format is
used. Note that all HIP packets (currently protocol 253) MUST bypass used. Note that all HIP packets (currently protocol 139) MUST bypass
ESP processing. 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 [I-D.ietf-hip-rfc5201-bis]. When the ESP transport specification [I-D.ietf-hip-rfc5201-bis]. When the ESP transport
format is used, and there is an active HIP session for the given < format is used, and there is an active HIP session for the given <
source, destination > HIT pair, the outgoing datagram is protected source, destination > HIT pair, the outgoing datagram is protected
using the ESP security association. The following additional steps using the ESP security association. The following additional steps
define the conceptual processing rules for outgoing ESP protected define the conceptual processing rules for outgoing ESP protected
skipping to change at page 28, line 12 skipping to change at page 28, line 12
also valid for this document. Many people have given valuable also valid for this document. Many people have given valuable
feedback, and our apologies to anyone whose name is missing. feedback, and our apologies to anyone whose name is missing.
11. References 11. References
11.1. Normative references 11.1. Normative references
[I-D.ietf-hip-rfc5201-bis] Moskowitz, R., Heer, T., Jokela, P., and [I-D.ietf-hip-rfc5201-bis] Moskowitz, R., Heer, T., Jokela, P., and
T. Henderson, "Host Identity Protocol T. Henderson, "Host Identity Protocol
Version 2 (HIPv2)", Version 2 (HIPv2)",
draft-ietf-hip-rfc5201-bis-09 (work in draft-ietf-hip-rfc5201-bis-11 (work in
progress), July 2012. progress), February 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs [RFC2119] Bradner, S., "Key words for use in RFCs
to Indicate Requirement Levels", BCP 14, to Indicate Requirement Levels", BCP 14,
RFC 2119, March 1997. RFC 2119, March 1997.
[RFC2404] Madson, C. and R. Glenn, "The Use of [RFC2404] Madson, C. and R. Glenn, "The Use of
HMAC-SHA-1-96 within ESP and AH", HMAC-SHA-1-96 within ESP and AH",
RFC 2404, November 1998. RFC 2404, November 1998.
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, [RFC3602] Frankel, S., Glenn, R., and S. Kelly,
"The AES-CBC Cipher Algorithm and Its Use "The AES-CBC Cipher Algorithm and Its Use
with IPsec", RFC 3602, September 2003. with IPsec", RFC 3602, September 2003.
[RFC4303] Kent, S., "IP Encapsulating Security [RFC4303] Kent, S., "IP Encapsulating Security
Payload (ESP)", RFC 4303, December 2005. Payload (ESP)", RFC 4303, December 2005.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-
SHA-256, HMAC-SHA-384, and HMAC-SHA-512
with IPsec", RFC 4868, May 2007.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P.
Eronen, "Internet Key Exchange Protocol
Version 2 (IKEv2)", RFC 5996,
September 2010.
11.2. Informative references 11.2. Informative references
[I-D.ietf-hip-rfc4423-bis] Moskowitz, R., "Host Identity Protocol [I-D.ietf-hip-rfc4423-bis] Moskowitz, R., "Host Identity Protocol
Architecture", Architecture",
draft-ietf-hip-rfc4423-bis-04 (work in draft-ietf-hip-rfc4423-bis-05 (work in
progress), July 2012. progress), September 2012.
[RFC0791] Postel, J., "Internet Protocol", STD 5, [RFC0791] Postel, J., "Internet Protocol", STD 5,
RFC 791, September 1981. RFC 791, September 1981.
[RFC2401] Kent, S. and R. Atkinson, "Security [RFC2401] Kent, S. and R. Atkinson, "Security
Architecture for the Internet Protocol", Architecture for the Internet Protocol",
RFC 2401, November 1998. RFC 2401, November 1998.
[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.
[RFC4301] Kent, S. and K. Seo, "Security [RFC4301] Kent, S. and K. Seo, "Security
Architecture for the Internet Protocol", Architecture for the Internet Protocol",
RFC 4301, December 2005. RFC 4301, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange [RFC4306] Kaufman, C., "Internet Key Exchange
(IKEv2) Protocol", RFC 4306, (IKEv2) Protocol", RFC 4306,
December 2005. December 2005.
[RFC5206] Henderson, T., Ed., "End-Host Mobility [RFC5206] Henderson, T., Ed., "End-Host Mobility
and Multihoming with the Host Identity and Multihoming with the Host Identity
Protocol", RFC 5206, April 2008. Protocol", RFC 5206, April 2008.
[RFC5207] Stiemerling, M., Quittek, J., and L.
Eggert, "NAT and Firewall Traversal
Issues of Host Identity Protocol (HIP)
Communication", RFC 5207, April 2008.
[RFC5770] Komu, M., Henderson, T., Tschofenig, H.,
Melen, J., and A. Keranen, "Basic Host
Identity Protocol (HIP) Extensions for
Traversal of Network Address
Translators", RFC 5770, April 2010.
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 this is to ways. As noted above, one possible way of implementing this is to
rewrite IP headers below IPsec. In such an implementation, IPsec is rewrite IP headers below IPsec. In such an implementation, IPsec is
used as if it was processing IPv6 transport mode packets, with the used as if it was processing IPv6 transport mode packets, with the
IPv6 header containing HITs instead of IP addresses in the source and IPv6 header containing HITs instead of IP addresses in the source and
destination address fields. In outgoing packets, after IPsec destination 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,
 End of changes. 42 change blocks. 
94 lines changed or deleted 89 lines changed or added

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