draft-ietf-hip-rfc5202-bis-00.txt   draft-ietf-hip-rfc5202-bis-01.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 27, 2011 ICSA labs Expires: March 31, 2013 ICSAlabs, An Independent
P. Nikander Division of Verizon Business
Systems
J. Melen J. Melen
Ericsson Research NomadicLab Ericsson Research NomadicLab
September 23, 2010 September 27, 2012
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-00 draft-ietf-hip-rfc5202-bis-01
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).
IESG Note
The following issues describe IESG concerns about this document. The
IESG expects that these issues will be addressed when future versions
of HIP are designed.
In case of complex Security Policy Databases (SPDs) and the co-
existence of HIP and security-related protocols such as IKE,
implementors may encounter conditions that are unspecified in these
documents. For example, when the SPD defines an IP address subnet to
be protected and a HIP host is residing in that IP address area,
there is a possibility that the communication is encrypted multiple
times. Readers are advised to pay special attention when running HIP
with complex SPD settings. Future specifications should clearly
define when multiple encryption is intended, and when it should be
avoided.
Status of This Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on March 31, 2013.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 27, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2012 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 BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
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 . . . . . . . . . . . . . . . . . . . . . . 4
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 . . . . 6
skipping to change at page 4, line 7 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 . . . . . . . . . . . . . . . . . . . . 31 B.1.2. Packet format . . . . . . . . . . . . . . . . . . . . 30
B.1.3. Cryptographic processing . . . . . . . . . . . . . . . 32 B.1.3. Cryptographic processing . . . . . . . . . . . . . . . 32
B.1.4. IP header processing . . . . . . . . . . . . . . . . . 33 B.1.4. IP header processing . . . . . . . . . . . . . . . . . 32
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.moskowitz-hip-rfc4423-bis], hosts are identified with public [I-D.ietf-hip-rfc4423-bis], hosts are identified with public keys.
keys. The Host Identity Protocol [I-D.moskowitz-hip-rfc5201-bis] The Host Identity Protocol [I-D.ietf-hip-rfc5201-bis] base exchange
base exchange allows any two HIP-supporting hosts to authenticate allows any two HIP-supporting hosts to authenticate each other and to
each other and to create a HIP association between themselves. create a HIP association between themselves. During the base
During the base exchange, the hosts generate a piece of shared keying exchange, the hosts generate a piece of shared keying material using
material using an authenticated Diffie-Hellman exchange. an authenticated Diffie-Hellman exchange.
The HIP base exchange specification [I-D.moskowitz-hip-rfc5201-bis] The HIP base exchange specification [I-D.ietf-hip-rfc5201-bis] does
does not describe any transport formats or methods for user data to not describe any transport formats or methods for user data to be
be used during the actual communication; it only defines that it is used during the actual communication; it only defines that it is
mandatory to implement the Encapsulated Security Payload (ESP) mandatory to implement the Encapsulated Security Payload (ESP)
[RFC4303] based transport format and method. This document specifies [RFC4303] based transport format and method. This document specifies
how ESP is used with HIP to carry actual user data. how ESP is used 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
skipping to change at page 6, line 9 skipping to change at page 5, line 9
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 new ESP_TRANSFORM Responder adds the possible ESP transforms in a npew 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 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
skipping to change at page 7, line 51 skipping to change at page 6, line 51
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 [I-D.moskowitz-hip-rfc5201-bis]. Existing during the base exchange [I-D.ietf-hip-rfc5201-bis]. Existing ESP
ESP SAs can be updated later using UPDATE messages. The reason for SAs can be updated later using UPDATE messages. The reason for
updating the ESP SA later can be, for example, a need for rekeying updating the ESP SA later can be, for example, a need for rekeying
the SA because of sequence number rollover. 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
skipping to change at page 8, line 28 skipping to change at page 7, line 28
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
[I-D.moskowitz-hip-rfc5201-bis]. [I-D.ietf-hip-rfc5201-bis].
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 10, line 50 skipping to change at page 9, line 50
In the sending host, the HIP SA processing takes place always before In the sending host, the HIP SA processing takes place always before
the IPsec processing. Vice versa, at the receiving host, the IPsec the IPsec processing. Vice versa, at the receiving host, the IPsec
processing is done first for incoming packets and the decrypted processing is done first for incoming packets and the decrypted
packet is further given to the HIP processing. packet is further given to the HIP processing.
Incoming packets using an SA that is not negotiated by HIP MUST NOT Incoming packets using an SA that is not negotiated by HIP MUST NOT
be processed as described in Section 3.2, paragraph 2. The SPI will be processed as described in Section 3.2, paragraph 2. The SPI will
identify the correct SA for packet decryption and MUST be used to identify the correct SA for packet decryption and MUST be used to
identify that the packet has an upper-layer checksum that is identify that the packet has an upper-layer checksum that is
calculated as specified in [I-D.moskowitz-hip-rfc5201-bis]. calculated as specified in [I-D.ietf-hip-rfc5201-bis].
3.4.1. Data Packet Processing Considerations 3.4.1. Data Packet Processing Considerations
For outbound traffic, the SPD or (coordinated) SPDs if there are two For outbound traffic, the SPD or (coordinated) SPDs if there are two
(one for HIP and one for IPsec) MUST ensure that packets intended for (one for HIP and one for IPsec) MUST ensure that packets intended for
HIP processing are given a HIP-enabled SA and that packets intended HIP processing are given a HIP-enabled SA and that packets intended
for IPsec processing are given an IPsec-enabled SA. The SP then MUST for IPsec processing are given an IPsec-enabled SA. The SP then MUST
be bound to the matching SA and non-HIP packets will not be processed be bound to the matching SA and non-HIP packets will not be processed
by this SA. Data originating from a socket that is not using HIP by this SA. Data originating from a socket that is not using HIP
MUST NOT have checksum recalculated (as described in Section 3.2, MUST NOT have checksum recalculated (as described in Section 3.2,
skipping to change at page 13, line 10 skipping to change at page 12, line 10
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 SA. The UPDATE mechanism and message is defined in
[I-D.moskowitz-hip-rfc5201-bis], and the additional parameters for [I-D.ietf-hip-rfc5201-bis], and the additional parameters for
updating an existing ESP SA are described here. updating an 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]
-----------------------------------------------------> ----------------------------------------------------->
skipping to change at page 13, line 33 skipping to change at page 12, 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 [I-D.moskowitz-hip-rfc5201-bis]. defined in [I-D.ietf-hip-rfc5201-bis].
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 ones. Also, the NOTIFY parameter, described in
[I-D.moskowitz-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
skipping to change at page 16, line 51 skipping to change at page 15, line 51
NULL-ENCRYPT with HMAC-SHA2 7 [RFC2410], [RFC4868] NULL-ENCRYPT with HMAC-SHA2 7 [RFC2410], [RFC4868]
AES-128-CBC with HMAC-SHA2 8 [RFC3602], [RFC4868] AES-128-CBC with HMAC-SHA2 8 [RFC3602], [RFC4868]
AES-256-CBC with HMAC-SHA2 9 [RFC3602], [RFC4868] AES-256-CBC with HMAC-SHA2 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 transport 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-CBC with HMAC-SHA1 and NULL with HMAC-
SHA1. SHA1.
skipping to change at page 20, line 33 skipping to change at page 19, line 33
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
ICMP message handling is mainly described in the HIP base ICMP message handling is mainly described in the HIP base
specification [I-D.moskowitz-hip-rfc5201-bis]. In this section, we specification [I-D.ietf-hip-rfc5201-bis]. In this section, we
describe the actions related to ESP security associations. describe the 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 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.moskowitz-hip-rfc5201-bis]. This section describes the changes [I-D.ietf-hip-rfc5201-bis]. This section describes the changes and
and new requirements for packet handling when the ESP transport new requirements for packet handling when the ESP transport format is
format is used. Note that all HIP packets (currently protocol 253) used. Note that all HIP packets (currently protocol 253) MUST bypass
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.moskowitz-hip-rfc5201-bis]. When the ESP specification [I-D.ietf-hip-rfc5201-bis]. When the ESP transport
transport format is used, and there is an active HIP session for the format is used, and there is an active HIP session for the given <
given < source, destination > HIT pair, the outgoing datagram is source, destination > HIT pair, the outgoing datagram is protected
protected using the ESP security association. The following using the ESP security association. The following additional steps
additional steps define the conceptual processing rules for outgoing define the conceptual processing rules for outgoing ESP protected
ESP protected datagrams. datagrams.
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 25 skipping to change at page 21, line 25
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 [I-D.moskowitz-hip-rfc5201-bis]. described in [I-D.ietf-hip-rfc5201-bis].
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) selects one of the ESP transforms from the presented host (Initiator) selects 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 22, line 49 skipping to change at page 21, line 49
the system prepares and creates an incoming ESP security association. the system prepares and creates an incoming ESP security association.
It may also prepare a security association for outgoing traffic, but It may also prepare a security association for outgoing traffic, but
since it does not have the correct SPI value yet, it cannot activate since it does not have the correct SPI value yet, it cannot activate
it. 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 [I-D.moskowitz-hip-rfc5201-bis]). comparisons as described in [I-D.ietf-hip-rfc5201-bis]).
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 6 skipping to change at page 23, line 6
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 The rekeying procedure uses the UPDATE mechanism defined in
[I-D.moskowitz-hip-rfc5201-bis]. Because each peer must update its [I-D.ietf-hip-rfc5201-bis]. Because each peer must update its half
half of the security association pair (including new SPI creation), of the security association pair (including new SPI creation), the
the rekeying process requires that each side both send and receive an rekeying process requires that each side both send and receive an
UPDATE. A system will then rekey the ESP SA when it has sent UPDATE. A system will then rekey the ESP SA when it has sent
parameters to the peer and has received both an ACK of the relevant parameters to the peer and has received both an ACK of the relevant
UPDATE message and corresponding peer's parameters. It may be that UPDATE message and corresponding peer's parameters. It may be that
the ACK and the required HIP parameters arrive in different UPDATE the ACK and the required HIP parameters arrive in different UPDATE
messages. This is always true if a system does not initiate ESP SA messages. This is always true if a system does not initiate ESP SA
update but responds to an update request from the peer, and may also update but responds to an update request from the peer, and may also
occur if two systems initiate update nearly simultaneously. In such occur if two systems initiate update nearly simultaneously. In such
a case, if the system has an outstanding update request, it saves the a case, if the system has an outstanding update request, it saves the
one parameter and waits for the other before completing rekeying. one parameter and waits for the other before completing rekeying.
skipping to change at page 25, line 14 skipping to change at page 24, line 14
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 specified for UPDATE processing in Section 6.12 of
[I-D.moskowitz-hip-rfc5201-bis]): [I-D.ietf-hip-rfc5201-bis]):
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 27, line 36 skipping to change at page 26, line 36
denotes the host with the lower HIT value. When HIT values are denotes the host with the lower HIT value. When HIT values are
compared, they are interpreted as positive (unsigned) 128-bit compared, they are interpreted as positive (unsigned) 128-bit
integers in network byte order. integers in network byte order.
The four HIP keys are only drawn from KEYMAT during a HIP I1->R2 The four HIP keys are only drawn from KEYMAT during a HIP I1->R2
exchange. Subsequent rekeys using UPDATE will only draw the four ESP exchange. Subsequent rekeys using UPDATE will only draw the four ESP
keys from KEYMAT. Section 6.9 describes the rules for reusing or keys from KEYMAT. Section 6.9 describes the rules for reusing or
regenerating KEYMAT based on the rekeying. regenerating KEYMAT based on the rekeying.
The number of bits drawn for a given algorithm is the "natural" size The number of bits drawn for a given algorithm is the "natural" size
of the keys. For the mandatory algorithms, the following sizes of the keys, as specified in Section 6.5 of
apply: [I-D.ietf-hip-rfc5201-bis].
AES 128 bits
SHA-1 160 bits
NULL 0 bits
8. Security Considerations 8. Security Considerations
In this document, the usage of ESP [RFC4303] between HIP hosts to In this document, the usage of ESP [RFC4303] between HIP hosts to
protect data traffic is introduced. The Security Considerations for protect data traffic is introduced. The Security Considerations for
ESP are 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 [RFC4306]. between two nodes. This can be done, e.g., using IKE [RFC4306].
This document specifies how the Host Identity Protocol is used to This document specifies how the Host Identity Protocol is used to
establish ESP Security Associations. establish ESP Security Associations.
The following issues are new or have changed from the standard ESP The following issues are new or have changed from the standard ESP
usage: usage:
o Initial keying material generation o Initial keying material generation
o Updating the keying material o Updating the keying material
skipping to change at page 28, line 16 skipping to change at page 27, line 10
establish ESP Security Associations. establish ESP Security Associations.
The following issues are new or have changed from the standard ESP The following issues are new or have changed from the standard ESP
usage: 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 [I-D.moskowitz-hip-rfc5201-bis] using the Diffie-Hellman Protocol [I-D.ietf-hip-rfc5201-bis] using the Diffie-Hellman
procedure. This document extends the usage of the UPDATE packet, procedure. This document extends the usage of the UPDATE packet,
defined in the base specification, to modify existing ESP SAs. The defined in the base specification, to modify existing ESP SAs. The
hosts may rekey, i.e., force the generation of new keying material hosts may rekey, i.e., force the generation of new keying material
using the Diffie-Hellman procedure. The initial setup of ESP SA using the Diffie-Hellman procedure. The initial setup of ESP SA
between the hosts is done during the base exchange, and the message between the hosts is done during the base exchange, and the message
exchange is protected using methods provided by base exchange. exchange is protected using methods provided by base exchange.
Changes in connection parameters means basically that the old ESP SA Changes in connection parameters means basically that the old ESP SA
is removed and a new one is generated once the UPDATE message is removed and a new one is generated once the UPDATE message
exchange has been completed. The message exchange is protected using exchange has been completed. The message exchange is protected using
the HIP association keys. Both HMAC and signing of packets is used. the HIP association keys. Both HMAC and signing of packets is used.
9. IANA Considerations 9. IANA Considerations
This document defines additional parameters and NOTIFY error types This document defines additional parameters and NOTIFY error types
for the Host Identity Protocol [I-D.moskowitz-hip-rfc5201-bis]. for the Host Identity Protocol [I-D.ietf-hip-rfc5201-bis].
The new parameters and their type numbers are defined in The new parameters and their type numbers are defined in
Section 5.1.1 and Section 5.1.2, and they have been added to the Section 5.1.1 and Section 5.1.2, and they have been added to the
Parameter Type namespace specified in Parameter Type namespace specified in [I-D.ietf-hip-rfc5201-bis].
[I-D.moskowitz-hip-rfc5201-bis].
The new NOTIFY error types and their values are defined in The new NOTIFY error types and their values are defined in
Section 5.1.3, and they have been added to the Notify Message Type Section 5.1.3, and they have been added to the Notify Message Type
namespace specified in [I-D.moskowitz-hip-rfc5201-bis]. namespace specified in [I-D.ietf-hip-rfc5201-bis].
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 providing comments and people have contributed to the text by providing comments and
modification proposals. The list of people include Tom Henderson, modification proposals. The list of people include Tom Henderson,
Jeff Ahrenholz, Jukka Ylitalo, and Miika Komu. The authors also want Jeff Ahrenholz, Jan Melen, Jukka Ylitalo, and Miika Komu.
to thank Charlie Kaufman for reviewing the document with his eye on Especially, the authors want to thank Pekka Nikander for his
the usage of crypto algorithms. invaluable contributions to the document since the first draft
version. The authors want to thank also Charlie Kaufman for
reviewing the document with his eye on the usage of crypto
algorithms.
Due to the history of this document, most of the ideas are inherited 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 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
[RFC2119] Bradner, S., "Key words for use in [I-D.ietf-hip-rfc5201-bis] Moskowitz, R., Heer, T., Jokela, P., and
RFCs to Indicate Requirement T. Henderson, "Host Identity Protocol
Levels", BCP 14, RFC 2119, Version 2 (HIPv2)",
March 1997. draft-ietf-hip-rfc5201-bis-09 (work in
progress), July 2012.
[RFC2404] Madson, C. and R. Glenn, "The Use of [RFC2119] Bradner, S., "Key words for use in RFCs
HMAC-SHA-1-96 within ESP and AH", to Indicate Requirement Levels", BCP 14,
RFC 2404, November 1998. RFC 2119, March 1997.
[RFC3602] Frankel, S., Glenn, R., and S. [RFC2404] Madson, C. and R. Glenn, "The Use of
Kelly, "The AES-CBC Cipher Algorithm HMAC-SHA-1-96 within ESP and AH",
and Its Use with IPsec", RFC 3602, RFC 2404, November 1998.
September 2003.
[RFC4303] Kent, S., "IP Encapsulating Security [RFC3602] Frankel, S., Glenn, R., and S. Kelly,
Payload (ESP)", RFC 4303, "The AES-CBC Cipher Algorithm and Its Use
December 2005. with IPsec", RFC 3602, September 2003.
11.2. Informative references [RFC4303] Kent, S., "IP Encapsulating Security
Payload (ESP)", RFC 4303, December 2005.
[I-D.moskowitz-hip-rfc4423-bis] Moskowitz, R., "Host Identity 11.2. Informative references
Protocol Architecture",
draft-moskowitz-hip-rfc4423-bis-02
(work in progress), June 2010.
[I-D.moskowitz-hip-rfc5201-bis] Moskowitz, R., Jokela, P., [I-D.ietf-hip-rfc4423-bis] Moskowitz, R., "Host Identity Protocol
Henderson, T., and T. Heer, "Host Architecture",
Identity Protocol", draft-ietf-hip-rfc4423-bis-04 (work in
draft-moskowitz-hip-rfc5201-bis-02 progress), July 2012.
(work in progress), July 2010.
[RFC0791] Postel, J., "Internet Protocol", [RFC0791] Postel, J., "Internet Protocol", STD 5,
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 Architecture for the Internet Protocol",
Protocol", RFC 2401, November 1998. RFC 2401, November 1998.
[RFC3260] Grossman, D., "New Terminology and [RFC3260] Grossman, D., "New Terminology and
Clarifications for Diffserv", Clarifications for Diffserv", RFC 3260,
RFC 3260, April 2002. April 2002.
[RFC3474] Lin, Z. and D. Pendarakis, [RFC3474] Lin, Z. and D. Pendarakis, "Documentation
"Documentation of IANA assignments of IANA assignments for Generalized
for Generalized MultiProtocol Label MultiProtocol Label Switching (GMPLS)
Switching (GMPLS) Resource Resource Reservation Protocol - Traffic
Reservation Protocol - Traffic Engineering (RSVP-TE) Usage and
Engineering (RSVP-TE) Usage and Extensions for Automatically Switched
Extensions for Automatically Optical Network (ASON)", RFC 3474,
Switched Optical Network (ASON)", March 2003.
RFC 3474, March 2003.
[RFC4301] Kent, S. and K. Seo, "Security [RFC4301] Kent, S. and K. Seo, "Security
Architecture for the Internet Architecture for the Internet Protocol",
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 [RFC5206] Henderson, T., Ed., "End-Host Mobility
Mobility and Multihoming with the and Multihoming with the Host Identity
Host Identity Protocol", RFC 5206, Protocol", RFC 5206, April 2008.
April 2008.
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
skipping to change at page 37, line 19 skipping to change at page 36, line 16
Petri Jokela Petri Jokela
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: petri.jokela@nomadiclab.com EMail: petri.jokela@nomadiclab.com
Robert Moskowitz Robert Moskowitz
ICSA labs, An Independent Division of Verizon Business ICSAlabs, An Independent Division of Verizon Business Systems
1000 Bent Creek Blvd, Suite 200 1000 Bent Creek Blvd, Suite 200
Mechanicsburg, PA Mechanicsburg, PA
USA USA
EMail: rgm@icsalabs.com EMail: rgm@icsalabs.com
Pekka Nikander
Ericsson Research NomadicLab
JORVAS FIN-02420
FINLAND
Phone: +358 9 299 1
EMail: pekka.nikander@nomadiclab.com
Jan Melen Jan Melen
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: jan.melen@nomadiclab.com EMail: jan.melen@nomadiclab.com
 End of changes. 51 change blocks. 
160 lines changed or deleted 108 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/