draft-ietf-hip-rfc5202-bis-03.txt   draft-ietf-hip-rfc5202-bis-04.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 Obsoletes: 5202 (if approved) R. Moskowitz
Expires: January 11, 2014 ICSAlabs, An Independent Intended status: Standards Track ICSAlabs, An Independent
Division of Verizon Business Expires: March 8, 2014 Division of Verizon Business
Systems Systems
J. Melen J. Melen
Ericsson Research NomadicLab Ericsson Research NomadicLab
July 10, 2013 September 4, 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-03 draft-ietf-hip-rfc5202-bis-04
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). This document obsoletes RFC 5202.
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
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). 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 January 11, 2014. This Internet-Draft will expire on March 8, 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 3, line 19 skipping to change at page 3, line 19
6.10. Finalizing Rekeying . . . . . . . . . . . . . . . . . . . 25 6.10. Finalizing Rekeying . . . . . . . . . . . . . . . . . . . 25
6.11. Processing NOTIFY Packets . . . . . . . . . . . . . . . . 26 6.11. Processing NOTIFY Packets . . . . . . . . . . . . . . . . 26
7. Keying Material . . . . . . . . . . . . . . . . . . . . . . . 26 7. Keying Material . . . . . . . . . . . . . . . . . . . . . . . 26
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 . . . . . . . . 30
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 . . . . . . . . . . . . . . . . . . . . 31
B.1.3. Cryptographic processing . . . . . . . . . . . . . . . 32 B.1.3. Cryptographic processing . . . . . . . . . . . . . . . 33
B.1.4. IP header processing . . . . . . . . . . . . . . . . . 33 B.1.4. IP header processing . . . . . . . . . . . . . . . . . 33
B.1.5. Handling of outgoing packets . . . . . . . . . . . . . 33 B.1.5. Handling of outgoing packets . . . . . . . . . . . . . 33
B.1.6. Handling of incoming packets . . . . . . . . . . . . . 34 B.1.6. Handling of incoming packets . . . . . . . . . . . . . 34
B.1.7. IPv4 options handling . . . . . . . . . . . . . . . . 35 B.1.7. IPv4 options handling . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
In the Host Identity Protocol Architecture In the Host Identity Protocol Architecture
[I-D.ietf-hip-rfc4423-bis], hosts are identified with public keys. [I-D.ietf-hip-rfc4423-bis], hosts are identified with public keys.
The Host Identity Protocol [I-D.ietf-hip-rfc5201-bis] base exchange The Host Identity Protocol [I-D.ietf-hip-rfc5201-bis] base exchange
skipping to change at page 4, line 46 skipping to change at page 4, line 46
For user data packets, ESP SPIs (in possible combination with IP For user data packets, ESP SPIs (in possible combination with IP
addresses) are used indirectly to identify the host context, thereby addresses) are used indirectly to identify the host context, thereby
avoiding any additional explicit protocol headers. avoiding any additional explicit protocol headers.
HIP and ESP traffic have known issues with middlebox traversal RFC HIP and ESP traffic have known issues with middlebox traversal RFC
5207 [RFC5207]. Other specifications exist for operating HIP and ESP 5207 [RFC5207]. Other specifications exist for operating HIP and ESP
over UDP (RFC 5770 [RFC5770] is an experimental specification, and over UDP (RFC 5770 [RFC5770] is an experimental specification, and
others are being developed). Middlebox traversal is out of scope for others are being developed). Middlebox traversal is out of scope for
this document. this document.
This document obsoletes RFC 5202.
2. Conventions Used in This Document 2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Using ESP with HIP 3. Using ESP with HIP
The HIP base exchange is used to set up a HIP association between two The HIP base exchange is used to set up a HIP association between two
hosts. The base exchange provides two-way host authentication and hosts. The base exchange provides two-way host authentication and
skipping to change at page 26, line 46 skipping to change at page 26, line 46
of the keys, as specified in Section 6.5 of of the keys, as specified in Section 6.5 of
[I-D.ietf-hip-rfc5201-bis]. [I-D.ietf-hip-rfc5201-bis].
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 [RFC5996].
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 23 skipping to change at page 28, line 23
progress), June 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.
[RFC2410] Glenn, R. and S. Kent, "The NULL
Encryption Algorithm and Its Use With
IPsec", RFC 2410, November 1998.
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, [RFC3602] Frankel, S., Glenn, R., and S. Kelly,
"The AES-CBC Cipher Algorithm and Its Use "The AES-CBC Cipher Algorithm and Its Use
with IPsec", RFC 3602, September 2003. with IPsec", RFC 3602, September 2003.
[RFC4106] Viega, J. and D. McGrew, "The Use of
Galois/Counter Mode (GCM) in IPsec
Encapsulating Security Payload (ESP)",
RFC 4106, June 2005.
[RFC4303] Kent, S., "IP Encapsulating Security [RFC4303] Kent, S., "IP Encapsulating Security
Payload (ESP)", RFC 4303, December 2005. Payload (ESP)", RFC 4303, December 2005.
[RFC4309] Housley, R., "Using Advanced Encryption
Standard (AES) CCM Mode with IPsec
Encapsulating Security Payload (ESP)",
RFC 4309, December 2005.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC- [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-
SHA-256, HMAC-SHA-384, and HMAC-SHA-512 SHA-256, HMAC-SHA-384, and HMAC-SHA-512
with IPsec", RFC 4868, May 2007. with IPsec", RFC 4868, May 2007.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P.
Eronen, "Internet Key Exchange Protocol
Version 2 (IKEv2)", RFC 5996,
September 2010.
11.2. Informative references 11.2. Informative references
[I-D.ietf-hip-rfc4423-bis] Moskowitz, R., "Host Identity Protocol [I-D.ietf-hip-rfc4423-bis] Moskowitz, R., "Host Identity Protocol
Architecture", Architecture",
draft-ietf-hip-rfc4423-bis-05 (work in draft-ietf-hip-rfc4423-bis-05 (work in
progress), September 2012. progress), September 2012.
[RFC0791] Postel, J., "Internet Protocol", STD 5, [RFC0791] Postel, J., "Internet Protocol", STD 5,
RFC 791, September 1981. RFC 791, September 1981.
[RFC2401] Kent, S. and R. Atkinson, "Security
Architecture for the Internet Protocol",
RFC 2401, November 1998.
[RFC4301] Kent, S. and K. Seo, "Security [RFC4301] Kent, S. and K. Seo, "Security
Architecture for the Internet Protocol", Architecture for the Internet Protocol",
RFC 4301, December 2005. RFC 4301, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange
(IKEv2) Protocol", RFC 4306,
December 2005.
[RFC5206] Henderson, T., Ed., "End-Host Mobility [RFC5206] Henderson, T., Ed., "End-Host Mobility
and Multihoming with the Host Identity and Multihoming with the Host Identity
Protocol", RFC 5206, April 2008. Protocol", RFC 5206, April 2008.
[RFC5207] Stiemerling, M., Quittek, J., and L. [RFC5207] Stiemerling, M., Quittek, J., and L.
Eggert, "NAT and Firewall Traversal Eggert, "NAT and Firewall Traversal
Issues of Host Identity Protocol (HIP) Issues of Host Identity Protocol (HIP)
Communication", RFC 5207, April 2008. Communication", RFC 5207, April 2008.
[RFC5770] Komu, M., Henderson, T., Tschofenig, H., [RFC5770] Komu, M., Henderson, T., Tschofenig, H.,
Melen, J., and A. Keranen, "Basic Host Melen, J., and A. Keranen, "Basic Host
Identity Protocol (HIP) Extensions for Identity Protocol (HIP) Extensions for
Traversal of Network Address Traversal of Network Address
Translators", RFC 5770, April 2010. Translators", RFC 5770, April 2010.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P.
Eronen, "Internet Key Exchange Protocol
Version 2 (IKEv2)", RFC 5996,
September 2010.
Appendix A. A Note on Implementation Options Appendix A. A Note on Implementation Options
It is possible to implement this specification in multiple different It is possible to implement this specification in multiple different
ways. As noted above, one possible way of implementing this is to ways. As noted above, one possible way of implementing this is to
rewrite IP headers below IPsec. In such an implementation, IPsec is rewrite IP headers below IPsec. In such an implementation, IPsec is
used as if it was processing IPv6 transport mode packets, with the used as if it was processing IPv6 transport mode packets, with the
IPv6 header containing HITs instead of IP addresses in the source and IPv6 header containing HITs instead of IP addresses in the source and
destination address fields. In outgoing packets, after IPsec destination address fields. In outgoing packets, after IPsec
processing, the HITs are replaced with actual IP addresses, based on processing, the HITs are replaced with actual IP addresses, based on
the HITs and the SPI. In incoming packets, before IPsec processing, the HITs and the SPI. In incoming packets, before IPsec processing,
skipping to change at page 30, line 40 skipping to change at page 30, line 48
A BEET mode Security Association contains the same data as a regular A BEET mode Security Association contains the same data as a regular
tunnel mode Security Association, with the exception that the inner tunnel mode Security Association, with the exception that the inner
selectors must be single addresses and cannot be subnets. The data selectors must be single addresses and cannot be subnets. The data
includes the following: includes the following:
A pair of inner IP addresses. A pair of inner IP addresses.
A pair of outer IP addresses. A pair of outer IP addresses.
Cryptographic keys and other data as defined in RFC2401 [RFC2401] Cryptographic keys and other data as defined in RFC4301 [RFC4301]
Section 4.4.3. Section 4.4.2.
A conforming implementation MAY store the data in a way similar to a A conforming implementation MAY store the data in a way similar to a
regular tunnel mode Security Association. regular tunnel mode Security Association.
Note that in a conforming implementation the inner and outer Note that in a conforming implementation the inner and outer
addresses MAY belong to different address families. All addresses MAY belong to different address families. All
implementations that support both IPv4 and IPv6 SHOULD support both implementations that support both IPv4 and IPv6 SHOULD support both
IPv4-over-IPv6 and IPv6-over-IPv4 tunneling. IPv4-over-IPv6 and IPv6-over-IPv4 tunneling.
B.1.2. Packet format B.1.2. Packet format
The wire packet format is identical to the ESP transport mode wire The wire packet format is identical to the ESP transport mode wire
format as defined in [RFC4303] Section 3.1.1. However, the resulting format as defined in [RFC4303] Section 3.1.1. However, the resulting
packet contains outer IP addresses instead of the inner IP addresses packet contains outer IP addresses instead of the inner IP addresses
received from the upper layer. The construction of the outer headers received from the upper layer. The construction of the outer headers
is defined in RFC2401 [RFC2401] Section 5.1.2. The following diagram is defined in RFC4301 [RFC4301] Section 5.1.2. The following diagram
illustrates ESP BEET mode positioning for typical IPv4 and IPv6 illustrates ESP BEET mode positioning for typical IPv4 and IPv6
packets. packets.
IPv4 INNER ADDRESSES IPv4 INNER ADDRESSES
-------------------- --------------------
BEFORE APPLYING ESP BEFORE APPLYING ESP
------------------------------ ------------------------------
| inner IP hdr | | | | inner IP hdr | | |
| | TCP | Data | | | TCP | Data |
skipping to change at page 35, line 27 skipping to change at page 35, line 36
In BEET mode, if IPv4 options are transported inside the tunnel, the In BEET mode, if IPv4 options are transported inside the tunnel, the
sender MUST include a pseudo-header after ESP header. The pseudo- sender MUST include a pseudo-header after ESP header. The pseudo-
header identifies that IPv4 options from the original packet are to header identifies that IPv4 options from the original packet are to
be applied on the packet on input side. be applied on the packet on input side.
The sender MUST set the next protocol field on the ESP header as 94. The sender MUST set the next protocol field on the ESP header as 94.
The resulting pseudo header including the IPv4 options MUST be padded The resulting pseudo header including the IPv4 options MUST be padded
to 8 octet boundary. The padding length is expressed in octets, to 8 octet boundary. The padding length is expressed in octets,
valid padding lengths are 0 or 4 octets as the original IPv4 options valid padding lengths are 0 or 4 octets as the original IPv4 options
are already padded to 4 octet boundary. The padding MUST be filled are already padded to 4 octet boundary. The padding MUST be filled
with NOP options as defined in [RFC0791]Internet Protocol section 3.1 with NOP options as defined in Internet Protocol [RFC0791] section
Internet header format. The padding is added in front of the 3.1 Internet header format. The padding is added in front of the
original options to ensure that the receiver is able to reconstruct original options to ensure that the receiver is able to reconstruct
the original IPv4 datagram. The Header Length field contains the the original IPv4 datagram. The Header Length field contains the
length of the IPv4 options, and padding in 8 octets units. length of the IPv4 options, and padding in 8 octets units.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Header Len | Pad Len | Reserved | | Next Header | Header Len | Pad Len | Reserved |
+---------------+---------------+-------------------------------+ +---------------+---------------+-------------------------------+
| Padding (if needed) | | Padding (if needed) |
 End of changes. 19 change blocks. 
28 lines changed or deleted 36 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/