draft-ietf-hip-rfc5202-bis-02.txt   draft-ietf-hip-rfc5202-bis-03.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: December 12, 2013 ICSAlabs, An Independent Expires: January 11, 2014 ICSAlabs, An Independent
Division of Verizon Business Division of Verizon Business
Systems Systems
J. Melen J. Melen
Ericsson Research NomadicLab Ericsson Research NomadicLab
June 10, 2013 July 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-02 draft-ietf-hip-rfc5202-bis-03
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 December 12, 2013. This Internet-Draft will expire on January 11, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 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
skipping to change at page 2, line 30 skipping to change at page 2, line 30
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 Ciphers . . . . . . . . . . . . . . . . . . 9 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. IPsec ESP Transport Format Type . . . . . . . . . . . 11
4.1.2. Updating an Existing ESP SA . . . . . . . . . . . . . 12 4.1.2. Setting Up an ESP Security Association . . . . . . . . 11
4.1.3. Updating an Existing ESP SA . . . . . . . . . . . . . 12
5. Parameter and Packet Formats . . . . . . . . . . . . . . . . . 13 5. Parameter and Packet Formats . . . . . . . . . . . . . . . . . 13
5.1. New Parameters . . . . . . . . . . . . . . . . . . . . . . 13 5.1. New Parameters . . . . . . . . . . . . . . . . . . . . . . 13
5.1.1. ESP_INFO . . . . . . . . . . . . . . . . . . . . . . . 13 5.1.1. ESP_INFO . . . . . . . . . . . . . . . . . . . . . . . 13
5.1.2. ESP_TRANSFORM . . . . . . . . . . . . . . . . . . . . 14 5.1.2. ESP_TRANSFORM . . . . . . . . . . . . . . . . . . . . 15
5.1.3. NOTIFICATION 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
skipping to change at page 10, line 6 skipping to change at page 10, line 6
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
the SPI values used for HIP SAs are not used for IPsec or other SAs, the SPI values used for HIP SAs are not used for IPsec or other SAs,
and vice versa. and vice versa.
In the sending host, the HIP SA processing takes place always before
the IPsec processing. Vice versa, at the receiving host, the IPsec
processing is done first for incoming packets and the decrypted
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.ietf-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
skipping to change at page 11, line 22 skipping to change at page 11, line 17
the eventual HIP middle boxes to handle the passing HIP signaling the eventual HIP middle boxes to handle the passing HIP signaling
packets. packets.
4. The Protocol 4. The Protocol
In this section, the protocol for setting up an ESP association to be In this section, the protocol for setting up an ESP association to be
used with HIP association is described. used with HIP association is described.
4.1. ESP in HIP 4.1. ESP in HIP
4.1.1. Setting Up an ESP Security Association 4.1.1. IPsec ESP Transport Format Type
The HIP handshake signals the TRANSPORT_FORMAT_LIST parameter in the
R1 and I2 messages. This parameter contains a list of the supported
HIP transport formats of the sending host in the order of preference.
The transport format type for IPsec ESP is the type number of the
ESP_TRANSFORM parameter, i.e., 4095.
4.1.2. Setting Up an ESP Security Association
Setting up an ESP Security Association between hosts using HIP Setting up an ESP Security Association between hosts using HIP
consists of three messages passed between the hosts. The parameters consists of three messages passed between the hosts. The parameters
are included in R1, I2, and R2 messages during base exchange. are included in R1, I2, and R2 messages during base exchange.
Initiator Responder Initiator Responder
I1 I1
----------------------------------> ---------------------------------->
skipping to change at page 11, line 50 skipping to change at page 12, line 6
<---------------------------------- <----------------------------------
Setting up an ESP Security Association between HIP hosts requires Setting up an ESP Security Association between HIP hosts requires
three messages to exchange the information that is required during an three messages to exchange the information that is required during an
ESP communication. ESP communication.
The R1 message contains the ESP_TRANSFORM parameter, in which the The R1 message contains the ESP_TRANSFORM parameter, in which the
sending host defines the possible ESP transforms it is willing to use sending host defines the possible ESP transforms it is willing to use
for the ESP SA. for the ESP SA.
Including the ESP_TRANSFORM parameter in the R1 message adds clarity
to the TRANSPORT_FORMAT_LIST, but may initiate negotiations for
possibly unselected transforms. However, resource-constrained
devices will most likely restrict support to a single transform for
the sake of minimizing ROM overhead and the additional parameter adds
negligible overhead with unconstrained devices.
The I2 message contains the response to an ESP_TRANSFORM received in The I2 message contains the response to an ESP_TRANSFORM received in
the R1 message. The sender must select one of the proposed ESP the R1 message. The sender must select one of the proposed ESP
transforms from the ESP_TRANSFORM parameter in the R1 message and transforms from the ESP_TRANSFORM parameter in the R1 message and
include the selected one in the ESP_TRANSFORM parameter in the I2 include the selected one in the ESP_TRANSFORM parameter in the I2
packet. In addition to the transform, the host includes the ESP_INFO packet. In addition to the transform, the host includes the ESP_INFO
parameter containing the SPI value to be used by the peer host. parameter containing the SPI value to be used by the peer host.
In the R2 message, the ESP SA setup is finalized. The packet In the R2 message, the ESP SA setup is finalized. The packet
contains the SPI information required by the Initiator for the ESP contains the SPI information required by the Initiator for the ESP
SA. SA.
4.1.2. Updating an Existing ESP SA 4.1.3. 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.ietf-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.
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-11 (work in draft-ietf-hip-rfc5201-bis-12 (work in
progress), February 2013. progress), June 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,
 End of changes. 11 change blocks. 
16 lines changed or deleted 27 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/