--- 1/draft-ietf-hip-rfc5202-bis-03.txt 2013-09-05 23:14:24.708445243 -0700 +++ 2/draft-ietf-hip-rfc5202-bis-04.txt 2013-09-05 23:14:24.780447054 -0700 @@ -1,47 +1,47 @@ Network Working Group P. Jokela Internet-Draft Ericsson Research NomadicLab -Intended status: Standards Track R. Moskowitz -Expires: January 11, 2014 ICSAlabs, An Independent - Division of Verizon Business +Obsoletes: 5202 (if approved) R. Moskowitz +Intended status: Standards Track ICSAlabs, An Independent +Expires: March 8, 2014 Division of Verizon Business Systems J. Melen Ericsson Research NomadicLab - July 10, 2013 + September 4, 2013 Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) - draft-ietf-hip-rfc5202-bis-03 + draft-ietf-hip-rfc5202-bis-04 Abstract This memo specifies an Encapsulated Security Payload (ESP) based 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 This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -102,25 +102,25 @@ 6.10. Finalizing Rekeying . . . . . . . . . . . . . . . . . . . 25 6.11. Processing NOTIFY Packets . . . . . . . . . . . . . . . . 26 7. Keying Material . . . . . . . . . . . . . . . . . . . . . . . 26 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 11.1. Normative references . . . . . . . . . . . . . . . . . . . 28 11.2. Informative references . . . . . . . . . . . . . . . . . . 28 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.1. Changes to Security Association data structures . . . 30 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.5. Handling of outgoing packets . . . . . . . . . . . . . 33 B.1.6. Handling of incoming packets . . . . . . . . . . . . . 34 B.1.7. IPv4 options handling . . . . . . . . . . . . . . . . 35 1. Introduction In the Host Identity Protocol Architecture [I-D.ietf-hip-rfc4423-bis], hosts are identified with public keys. The Host Identity Protocol [I-D.ietf-hip-rfc5201-bis] base exchange @@ -153,20 +153,22 @@ For user data packets, ESP SPIs (in possible combination with IP addresses) are used indirectly to identify the host context, thereby avoiding any additional explicit protocol headers. HIP and ESP traffic have known issues with middlebox traversal RFC 5207 [RFC5207]. Other specifications exist for operating HIP and ESP over UDP (RFC 5770 [RFC5770] is an experimental specification, and others are being developed). Middlebox traversal is out of scope for this document. + This document obsoletes RFC 5202. + 2. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Using ESP with HIP The HIP base exchange is used to set up a HIP association between two hosts. The base exchange provides two-way host authentication and @@ -1197,21 +1199,21 @@ of the keys, as specified in Section 6.5 of [I-D.ietf-hip-rfc5201-bis]. 8. Security Considerations In this document, the usage of ESP [RFC4303] between HIP hosts to protect data traffic is introduced. The Security Considerations for ESP are discussed in the ESP specification. 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 establish ESP Security Associations. The following issues are new or have changed from the standard ESP usage: o Initial keying material generation o Updating the keying material @@ -1271,73 +1273,79 @@ progress), June 2013. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", 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, "The AES-CBC Cipher Algorithm and Its Use 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 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- SHA-256, HMAC-SHA-384, and HMAC-SHA-512 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 [I-D.ietf-hip-rfc4423-bis] Moskowitz, R., "Host Identity Protocol Architecture", draft-ietf-hip-rfc4423-bis-05 (work in progress), September 2012. [RFC0791] Postel, J., "Internet Protocol", STD 5, 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 Architecture for the Internet Protocol", RFC 4301, December 2005. - [RFC4306] Kaufman, C., "Internet Key Exchange - (IKEv2) Protocol", RFC 4306, - December 2005. - [RFC5206] Henderson, T., Ed., "End-Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008. [RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) Communication", RFC 5207, April 2008. [RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. Keranen, "Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address 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 It is possible to implement this specification in multiple different ways. As noted above, one possible way of implementing this is to rewrite IP headers below IPsec. In such an implementation, IPsec is used as if it was processing IPv6 transport mode packets, with the IPv6 header containing HITs instead of IP addresses in the source and destination address fields. In outgoing packets, after IPsec processing, the HITs are replaced with actual IP addresses, based on the HITs and the SPI. In incoming packets, before IPsec processing, @@ -1385,38 +1393,38 @@ A BEET mode Security Association contains the same data as a regular tunnel mode Security Association, with the exception that the inner selectors must be single addresses and cannot be subnets. The data includes the following: A pair of inner IP addresses. A pair of outer IP addresses. - Cryptographic keys and other data as defined in RFC2401 [RFC2401] - Section 4.4.3. + Cryptographic keys and other data as defined in RFC4301 [RFC4301] + Section 4.4.2. A conforming implementation MAY store the data in a way similar to a regular tunnel mode Security Association. Note that in a conforming implementation the inner and outer addresses MAY belong to different address families. All implementations that support both IPv4 and IPv6 SHOULD support both IPv4-over-IPv6 and IPv6-over-IPv4 tunneling. B.1.2. Packet format The wire packet format is identical to the ESP transport mode wire format as defined in [RFC4303] Section 3.1.1. However, the resulting packet contains outer IP addresses instead of the inner IP addresses 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 packets. IPv4 INNER ADDRESSES -------------------- BEFORE APPLYING ESP ------------------------------ | inner IP hdr | | | | | TCP | Data | @@ -1610,22 +1618,22 @@ In BEET mode, if IPv4 options are transported inside the tunnel, the sender MUST include a pseudo-header after ESP header. The pseudo- header identifies that IPv4 options from the original packet are to be applied on the packet on input side. 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 to 8 octet boundary. The padding length is expressed in octets, 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 - with NOP options as defined in [RFC0791]Internet Protocol section 3.1 - Internet header format. The padding is added in front of the + with NOP options as defined in Internet Protocol [RFC0791] section + 3.1 Internet header format. The padding is added in front of the original options to ensure that the receiver is able to reconstruct the original IPv4 datagram. The Header Length field contains the length of the IPv4 options, and padding in 8 octets units. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Header Len | Pad Len | Reserved | +---------------+---------------+-------------------------------+ | Padding (if needed) |