draft-ietf-hip-esp-02.txt   draft-ietf-hip-esp-03.txt 
Network Working Group P. Jokela Network Working Group P. Jokela
Internet-Draft Ericsson Research NomadicLab Internet-Draft Ericsson Research NomadicLab
Expires: September 3, 2006 R. Moskowitz Expires: December 17, 2006 R. Moskowitz
ICSAlabs, a Division of TruSecure ICSAlabs, a Division of TruSecure
Corporation Corporation
P. Nikander P. Nikander
Ericsson Research NomadicLab Ericsson Research NomadicLab
March 2, 2006 June 15, 2006
Using ESP transport format with HIP Using ESP transport format with HIP
draft-ietf-hip-esp-02 draft-ietf-hip-esp-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 38 skipping to change at page 1, line 38
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 3, 2006. This Internet-Draft will expire on December 17, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
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).
skipping to change at page 10, line 10 skipping to change at page 10, line 10
In addition to AES, all implementations MUST implement the ESP NULL In addition to AES, all implementations MUST implement the ESP NULL
encryption algorithm. When the ESP NULL encryption is used, it MUST encryption algorithm. When the ESP NULL encryption is used, it MUST
be used together with SHA1 or MD5 authentication as specified in be used together with SHA1 or MD5 authentication as specified in
Section 5.1.2 Section 5.1.2
3.3.6. Sequence Number 3.3.6. Sequence Number
The Sequence Number field is MANDATORY when ESP is used with HIP. The Sequence Number field is MANDATORY when ESP is used with HIP.
Anti-replay protection MUST be used in an ESP SA established with Anti-replay protection MUST be used in an ESP SA established with
HIP. This means that each host MUST rekey before its sequence number HIP. When ESP is used with HIP, a 64-bit sequence number MUST be
reaches 2^32, or if extended sequence numbers are used, 2^64. used. This means that each host MUST rekey before its sequence
number reaches 2^64.
In some instances, a 32-bit sequence number is inadequate. In the When using a 64-bit sequence number, the higher 32 bits are NOT
ESP_TRANSFORM parameter, a peer MAY require that a 64-bit sequence included in the ESP header, but are simply kept local to both peers.
numbers be used. In this case the higher 32 bits are NOT included in See [9].
the ESP header, but are simply kept local to both peers. The 64-bit
sequence number is required in fast networks when there is a risk
that the sequence number will rollover too often. See [9].
3.3.7. Lifetimes and Timers 3.3.7. Lifetimes and Timers
HIP does not negotiate any lifetimes. All ESP lifetimes are local HIP does not negotiate any lifetimes. All ESP lifetimes are local
policy. The only lifetimes a HIP implementation MUST support are policy. The only lifetimes a HIP implementation MUST support are
sequence number rollover (for replay protection), and SHOULD support sequence number rollover (for replay protection), and SHOULD support
timing out inactive ESP SAs. An SA times out if no packets are timing out inactive ESP SAs. An SA times out if no packets are
received using that SA. The default timeout value is 15 minutes. received using that SA. The default timeout value is 15 minutes.
Implementations MAY support lifetimes for the various ESP transforms. Implementations MAY support lifetimes for the various ESP transforms.
Each implementation SHOULD implement per-HIT configuration of the Each implementation SHOULD implement per-HIT configuration of the
skipping to change at page 14, line 42 skipping to change at page 14, line 42
a new Diffie-Hellman key. a new Diffie-Hellman key.
Old SPI Old SPI for data sent to address(es) associated Old SPI Old SPI for data sent to address(es) associated
with this SA. If this is an initial SA setup, the with this SA. If this is an initial SA setup, the
Old SPI value is zero. Old SPI value is zero.
New SPI New SPI for data sent to address(es) associated New SPI New SPI for data sent to address(es) associated
with this SA. with this SA.
5.1.2. ESP_TRANSFORM 5.1.2. ESP_TRANSFORM
The ESP_TRANSFORM parameter is used during ESP SA establishment. The The ESP_TRANSFORM parameter is used during ESP SA establishment. The
first party sends a selection of transfrom families in the first party sends a selection of transform families in the
ESP_TRANSFORM parameter and the peer must select one of the proposed ESP_TRANSFORM parameter and the peer must select one of the proposed
values and include it in the response ESP_TRANSFORM parameter. values and include it in the response ESP_TRANSFORM parameter.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |E| Suite-ID #1 | | Reserved | Suite-ID #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Suite-ID #2 | Suite-ID #3 | | Suite-ID #2 | Suite-ID #3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Suite-ID #n | Padding | | Suite-ID #n | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 4095 Type 4095
Length length in octets, excluding Type, Length, and Length length in octets, excluding Type, Length, and
padding padding
E One if the ESP transform requires 64-bit
sequence numbers
(see
Section 3.3.6
Reserved zero when sent, ignored when received Reserved zero when sent, ignored when received
Suite-ID defines the ESP Suite to be used Suite-ID defines the ESP Suite to be used
The following Suite-IDs are defined ([6],[8]): The following Suite-IDs are defined ([6],[8]):
Suite-ID Value Suite-ID Value
RESERVED 0 RESERVED 0
ESP-AES-CBC with HMAC-SHA1 1 ESP-AES-CBC with HMAC-SHA1 1
ESP-3DES-CBC with HMAC-SHA1 2 ESP-3DES-CBC with HMAC-SHA1 2
ESP-3DES-CBC with HMAC-MD5 3 ESP-3DES-CBC with HMAC-MD5 3
ESP-BLOWFISH-CBC with HMAC-SHA1 4 ESP-BLOWFISH-CBC with HMAC-SHA1 4
ESP-NULL with HMAC-SHA1 5 ESP-NULL with HMAC-SHA1 5
ESP-NULL with HMAC-MD5 6 ESP-NULL with HMAC-MD5 6
There MUST NOT be more than six (6) ESP Suite-IDs in one The sender of an ESP transform parameter MUST make sure that there
ESP_TRANSFORM parameter. The limited number of Suite-IDs sets the are no more than six (6) Suite-IDs in one ESP transform parameter.
maximum size of ESP_TRANSFORM parameter. The ESP_TRANSFORM MUST Conversely, a recipient MUST be prepared to handle received transport
contain at least one of the mandatory Suite-IDs. parameters that contain more than six Suite-IDs. The limited number
of Suite-IDs sets the maximum size of ESP_TRANSFORM parameter. As
the default configuration, the ESP_TRANSFORM parameter MUST contain
at least one of the mandatory Suite-IDs. There MAY be a
configuration option that allows the administrator to override this
default.
Mandatory implementations: ESP-AES-CBC with HMAC-SHA1 and ESP-NULL Mandatory implementations: ESP-AES-CBC with HMAC-SHA1 and ESP-NULL
with HMAC-SHA1. with HMAC-SHA1.
5.1.3. NOTIFY Parameter 5.1.3. NOTIFY Parameter
The HIP base specification defines a set of NOTIFY error types. The The HIP base specification defines a set of NOTIFY error types. The
following error types are required for describing errors in ESP following error types are required for describing errors in ESP
Transform crypto suites during negotiation. Transform crypto suites during negotiation.
skipping to change at page 30, line 21 skipping to change at page 30, line 21
[2] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP [2] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP
and AH", RFC 2404, November 1998. and AH", RFC 2404, November 1998.
[3] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher [3] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
Algorithm and Its Use with IPsec", RFC 3602, September 2003. Algorithm and Its Use with IPsec", RFC 3602, September 2003.
[4] Kent, S., "IP Encapsulating Security Payload (ESP)", [4] Kent, S., "IP Encapsulating Security Payload (ESP)",
draft-ietf-ipsec-esp-v3-10 (work in progress), March 2005. draft-ietf-ipsec-esp-v3-10 (work in progress), March 2005.
[5] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-04 [5] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-05
(work in progress), October 2005. (work in progress), March 2006.
[6] Schiller, J., "Cryptographic Algorithms for use in the Internet [6] Schiller, J., "Cryptographic Algorithms for use in the Internet
Key Exchange Version 2", draft-ietf-ipsec-ikev2-algorithms-05 Key Exchange Version 2", draft-ietf-ipsec-ikev2-algorithms-05
(work in progress), April 2004. (work in progress), April 2004.
[7] Moskowitz, R. and P. Nikander, "Host Identity Protocol [7] Moskowitz, R. and P. Nikander, "Host Identity Protocol
Architecture", draft-ietf-hip-arch-03 (work in progress), Architecture", draft-ietf-hip-arch-03 (work in progress),
August 2005. August 2005.
[8] Schneier, B., "Applied Cryptography Second Edition: protocols [8] Schneier, B., "Applied Cryptography Second Edition: protocols
skipping to change at page 30, line 45 skipping to change at page 30, line 45
10.2. Informative references 10.2. Informative references
[9] Kent, S. and K. Seo, "Security Architecture for the Internet [9] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", draft-ietf-ipsec-rfc2401bis-06 (work in progress), Protocol", draft-ietf-ipsec-rfc2401bis-06 (work in progress),
April 2005. April 2005.
[10] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", [10] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998. RFC 2409, November 1998.
[11] Melen, J. and P. Nikander, "A Bound End-to-End Tunnel (BEET) [11] Melen, J. and P. Nikander, "A Bound End-to-End Tunnel (BEET)
mode for ESP", draft-nikander-esp-beet-mode-04 (work in mode for ESP", draft-nikander-esp-beet-mode-05 (work in
progress), November 2005. progress), February 2006.
[12] Nikander, P., "End-Host Mobility and Multihoming with the Host [12] Nikander, P., "End-Host Mobility and Multihoming with the Host
Identity Protocol", draft-ietf-hip-mm-02 (work in progress), Identity Protocol", draft-ietf-hip-mm-03 (work in progress),
July 2005. March 2006.
Appendix A. A Note on Implementation Options Appendix A. A Note on Implementation Options
It is possible to implement this specification in multiple different It is possible to implement this specification in multiple different
ways. As noted above, one possible way of implementing is to rewrite ways. As noted above, one possible way of implementing is to rewrite
IP headers below IPsec. In such an implementation, IPsec is used as IP headers below IPsec. In such an implementation, IPsec is used as
if it was processing IPv6 transport mode packets, with the IPv6 if it was processing IPv6 transport mode packets, with the IPv6
header containing HITs instead of IP addresses in the source and header containing HITs instead of IP addresses in the source and
destionation address fields. In outgoing packets, after IPsec destionation address fields. In outgoing packets, after IPsec
processing, the HITs are replaced with actual IP addresses, based on processing, the HITs are replaced with actual IP addresses, based on
 End of changes. 13 change blocks. 
29 lines changed or deleted 27 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/