draft-ietf-hip-esp-03.txt   draft-ietf-hip-esp-04.txt 
Network Working Group P. Jokela Network Working Group P. Jokela
Internet-Draft Ericsson Research NomadicLab Internet-Draft Ericsson Research NomadicLab
Expires: December 17, 2006 R. Moskowitz Expires: April 4, 2007 R. Moskowitz
ICSAlabs, a Division of TruSecure ICSAlabs, a Division of TruSecure
Corporation Corporation
P. Nikander P. Nikander
Ericsson Research NomadicLab Ericsson Research NomadicLab
June 15, 2006
Using ESP transport format with HIP Using ESP transport format with HIP
draft-ietf-hip-esp-03 draft-ietf-hip-esp-04
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 36
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 December 17, 2006. This Internet-Draft will expire on April 4, 2007.
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 2, line 21 skipping to change at page 2, line 21
3.2. Conceptual ESP Packet Processing . . . . . . . . . . . . . 6 3.2. Conceptual ESP Packet Processing . . . . . . . . . . . . . 6
3.2.1. Semantics of the Security Parameter Index (SPI) . . . 7 3.2.1. Semantics of the Security Parameter Index (SPI) . . . 7
3.3. Security Association Establishment and Maintenance . . . . 7 3.3. Security Association Establishment and Maintenance . . . . 7
3.3.1. ESP Security Associations . . . . . . . . . . . . . . 8 3.3.1. ESP Security Associations . . . . . . . . . . . . . . 8
3.3.2. Rekeying . . . . . . . . . . . . . . . . . . . . . . . 8 3.3.2. Rekeying . . . . . . . . . . . . . . . . . . . . . . . 8
3.3.3. Security Association Management . . . . . . . . . . . 9 3.3.3. Security Association Management . . . . . . . . . . . 9
3.3.4. Security Parameter Index (SPI) . . . . . . . . . . . . 9 3.3.4. Security Parameter Index (SPI) . . . . . . . . . . . . 9
3.3.5. Supported Transforms . . . . . . . . . . . . . . . . . 9 3.3.5. Supported Transforms . . . . . . . . . . . . . . . . . 9
3.3.6. Sequence Number . . . . . . . . . . . . . . . . . . . 10 3.3.6. Sequence Number . . . . . . . . . . . . . . . . . . . 10
3.3.7. Lifetimes and Timers . . . . . . . . . . . . . . . . . 10 3.3.7. Lifetimes and Timers . . . . . . . . . . . . . . . . . 10
4. The Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.4. IPsec and HIP ESP Implementation Considerations . . . . . 10
4.1. ESP in HIP . . . . . . . . . . . . . . . . . . . . . . . . 11 4. The Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1.1. Setting up an ESP Security Association . . . . . . . . 11 4.1. ESP in HIP . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1.2. Updating an Existing ESP SA . . . . . . . . . . . . . 12 4.1.1. Setting up an ESP Security Association . . . . . . . . 12
5. Parameter and Packet Formats . . . . . . . . . . . . . . . . . 13 4.1.2. Updating an Existing ESP SA . . . . . . . . . . . . . 13
5.1. New Parameters . . . . . . . . . . . . . . . . . . . . . . 13 5. Parameter and Packet Formats . . . . . . . . . . . . . . . . . 14
5.1.1. ESP_INFO . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. New Parameters . . . . . . . . . . . . . . . . . . . . . . 14
5.1.2. ESP_TRANSFORM . . . . . . . . . . . . . . . . . . . . 14 5.1.1. ESP_INFO . . . . . . . . . . . . . . . . . . . . . . . 14
5.1.3. NOTIFY Parameter . . . . . . . . . . . . . . . . . . . 15 5.1.2. ESP_TRANSFORM . . . . . . . . . . . . . . . . . . . . 15
5.2. HIP ESP Security Association Setup . . . . . . . . . . . . 16 5.1.3. NOTIFY Parameter . . . . . . . . . . . . . . . . . . . 16
5.2.1. Setup During Base Exchange . . . . . . . . . . . . . . 16 5.2. HIP ESP Security Association Setup . . . . . . . . . . . . 17
5.3. HIP ESP Rekeying . . . . . . . . . . . . . . . . . . . . . 17 5.2.1. Setup During Base Exchange . . . . . . . . . . . . . . 17
5.3.1. Initializing Rekeying . . . . . . . . . . . . . . . . 18 5.3. HIP ESP Rekeying . . . . . . . . . . . . . . . . . . . . . 18
5.3.2. Responding to the Rekeying Initialization . . . . . . 18 5.3.1. Initializing Rekeying . . . . . . . . . . . . . . . . 19
5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 19 5.3.2. Responding to the Rekeying Initialization . . . . . . 19
5.4.1. Unknown SPI . . . . . . . . . . . . . . . . . . . . . 19 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 20
6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 20 5.4.1. Unknown SPI . . . . . . . . . . . . . . . . . . . . . 20
6.1. Processing Outgoing Application Data . . . . . . . . . . . 20 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 21
6.2. Processing Incoming Application Data . . . . . . . . . . . 20 6.1. Processing Outgoing Application Data . . . . . . . . . . . 21
6.3. HMAC and SIGNATURE Calculation and Verification . . . . . 21 6.2. Processing Incoming Application Data . . . . . . . . . . . 21
6.4. Processing Incoming ESP SA Initialization (R1) . . . . . . 21 6.3. HMAC and SIGNATURE Calculation and Verification . . . . . 22
6.5. Processing Incoming Initialization Reply (I2) . . . . . . 22 6.4. Processing Incoming ESP SA Initialization (R1) . . . . . . 22
6.6. Processing Incoming ESP SA Setup Finalization (R2) . . . . 22 6.5. Processing Incoming Initialization Reply (I2) . . . . . . 23
6.7. Dropping HIP Associations . . . . . . . . . . . . . . . . 22 6.6. Processing Incoming ESP SA Setup Finalization (R2) . . . . 23
6.8. Initiating ESP SA Rekeying . . . . . . . . . . . . . . . . 22 6.7. Dropping HIP Associations . . . . . . . . . . . . . . . . 23
6.9. Processing Incoming UPDATE Packets . . . . . . . . . . . . 24 6.8. Initiating ESP SA Rekeying . . . . . . . . . . . . . . . . 23
6.9. Processing Incoming UPDATE Packets . . . . . . . . . . . . 25
6.9.1. Processing UPDATE Packet: No Outstanding Rekeying 6.9.1. Processing UPDATE Packet: No Outstanding Rekeying
Request . . . . . . . . . . . . . . . . . . . . . . . 24 Request . . . . . . . . . . . . . . . . . . . . . . . 25
6.10. Finalizing Rekeying . . . . . . . . . . . . . . . . . . . 25 6.10. Finalizing Rekeying . . . . . . . . . . . . . . . . . . . 26
6.11. Processing NOTIFY Packets . . . . . . . . . . . . . . . . 26 6.11. Processing NOTIFY Packets . . . . . . . . . . . . . . . . 27
7. Keying Material . . . . . . . . . . . . . . . . . . . . . . . 27 7. Keying Material . . . . . . . . . . . . . . . . . . . . . . . 28
8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 8. Security Considerations . . . . . . . . . . . . . . . . . . . 29
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
10.1. Normative references . . . . . . . . . . . . . . . . . . . 30 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
10.2. Informative references . . . . . . . . . . . . . . . . . . 30 11.1. Normative references . . . . . . . . . . . . . . . . . . . 32
Appendix A. A Note on Implementation Options . . . . . . . . . . 31 11.2. Informative references . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 Appendix A. A Note on Implementation Options . . . . . . . . . . 33
Intellectual Property and Copyright Statements . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
Intellectual Property and Copyright Statements . . . . . . . . . . 35
1. Introduction 1. Introduction
In the Host Identity Protocol Architecture [7], hosts are identified In the Host Identity Protocol Architecture [7], hosts are identified
with public keys. The Host Identity Protocol [5] base exchange with public keys. The Host Identity Protocol [5] 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
create a HIP association between themselves. During the base create a HIP association between themselves. During the base
exchange, the hosts generate a piece of shared keying material using exchange, the hosts generate a piece of shared keying material using
an authenticated Diffie-Hellman exchange. an authenticated Diffie-Hellman exchange.
skipping to change at page 11, line 5 skipping to change at page 10, line 30
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
inactivity timeout, allowing statically configured HIP associations inactivity timeout, allowing statically configured HIP associations
to stay alive for days, even when inactive. to stay alive for days, even when inactive.
3.4. IPsec and HIP ESP Implementation Considerations
When HIP is run on a node where a standards compliant IPsec is used,
some issues have to be considered.
The HIP implementation must be able to co-exist with other IPsec
keying protocols. When the HIP implementation selects the SPI value,
it may lead to a collision if not implemented properly. To avoid the
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,
and vice versa.
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
HIP processing are given a HIP-enabled SA and packets intended 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 by
this SA. Data originating from a socket that is not using HIP, MUST
NOT have checksum recalculated as described in Section 3.2 paragraph
2 and data MUST NOT be passed to the SP or SA created by the HIP.
Incoming data packets using a SA that is not negotiated by HIP, MUST
NOT be processed as described in Section 3.2 paragraph 2. The SPI
will identify the correct SA for packet decryption and MUST be used
to identify that the packet has an upper-layer checksum that is
calculated as specified in [5].
4. The Protocol 4. The Protocol
In this section, the protocol for setting up an ESP association to be In this section, the protocol for setting up an ESP association to be
used with HIP association is described. used with HIP association is described.
4.1. ESP in HIP 4.1. ESP in HIP
4.1.1. Setting up an ESP Security Association 4.1.1. Setting up an ESP Security Association
Setting up an ESP Security Association between hosts using HIP Setting up an ESP Security Association between hosts using HIP
skipping to change at page 30, line 5 skipping to change at page 31, line 5
9. IANA Considerations 9. IANA Considerations
This document defines additional parameters for the Host Identity This document defines additional parameters for the Host Identity
Protocol [5]. These parameters are defined in Section 5.1.1 and Protocol [5]. These parameters are defined in Section 5.1.1 and
Section 5.1.2 with the following numbers: Section 5.1.2 with the following numbers:
o ESP_INFO is 65. o ESP_INFO is 65.
o ESP_TRANSFORM is 4095. o ESP_TRANSFORM is 4095.
10. References 10. Acknowledgments
10.1. Normative references This document was separated from the base "Host Identity Protocol"
specification in the beginning of 2005. Since then, a number of
people have contributed to the text by giving comments and
modification proposals. The list of people include Tom Henderson,
Jeff Ahrenholz, Jan Melen, Jukka Ylitalo, and Miika Komu. Authors
want also thank Charlie Kaufman for reviewing the document with the
eye on the usage of crypto algorithms.
Due to the history of this document, most of the ideas are inherited
from the base "Host Identity Protocol" specification. Thus the list
of people in the Acknowledgments section of that specification is
also valid for this document. Many people have given valueable
feedback, and our apologies for anyone whose name is missing.
11. References
11.1. Normative references
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[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-05 [5] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-06
(work in progress), March 2006. (work in progress), June 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
algorithms and source in code in C", 1996. algorithms and source in code in C", 1996.
10.2. Informative references 11.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-05 (work in mode for ESP", draft-nikander-esp-beet-mode-06 (work in
progress), February 2006. progress), August 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-03 (work in progress), Identity Protocol", draft-ietf-hip-mm-04 (work in progress),
March 2006. June 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. 
52 lines changed or deleted 95 lines changed or added

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