--- 1/draft-ietf-hip-rfc5202-bis-05.txt 2014-07-28 05:14:53.248248868 -0700 +++ 2/draft-ietf-hip-rfc5202-bis-06.txt 2014-07-28 05:14:53.324250729 -0700 @@ -1,24 +1,22 @@ Network Working Group P. Jokela Internet-Draft Ericsson Research NomadicLab Obsoletes: 5202 (if approved) R. Moskowitz -Intended status: Standards Track ICSAlabs, An Independent -Expires: May 22, 2014 Division of Verizon Business - Systems - J. Melen +Intended status: Standards Track Verizon +Expires: January 29, 2015 J. Melen Ericsson Research NomadicLab - November 18, 2013 + July 28, 2014 Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) - draft-ietf-hip-rfc5202-bis-05 + draft-ietf-hip-rfc5202-bis-06 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). This document obsoletes RFC 5202. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -27,104 +25,104 @@ 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 May 22, 2014. + This Internet-Draft will expire on January 29, 2015. Copyright Notice - Copyright (c) 2013 IETF Trust and the persons identified as the + Copyright (c) 2014 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 - 3. Using ESP with HIP . . . . . . . . . . . . . . . . . . . . . . 5 + 3. Using ESP with HIP . . . . . . . . . . . . . . . . . . . . . 4 3.1. ESP Packet Format . . . . . . . . . . . . . . . . . . . . 5 - 3.2. Conceptual ESP Packet Processing . . . . . . . . . . . . . 5 + 3.2. Conceptual ESP Packet Processing . . . . . . . . . . . . 5 3.2.1. Semantics of the Security Parameter Index (SPI) . . . 6 - 3.3. Security Association Establishment and Maintenance . . . . 7 - 3.3.1. ESP Security Associations . . . . . . . . . . . . . . 7 - 3.3.2. Rekeying . . . . . . . . . . . . . . . . . . . . . . . 7 + 3.3. Security Association Establishment and Maintenance . . . 6 + 3.3.1. ESP Security Associations . . . . . . . . . . . . . . 6 + 3.3.2. Rekeying . . . . . . . . . . . . . . . . . . . . . . 7 3.3.3. Security Association Management . . . . . . . . . . . 8 - 3.3.4. Security Parameter Index (SPI) . . . . . . . . . . . . 8 - 3.3.5. Supported Ciphers . . . . . . . . . . . . . . . . . . 9 - 3.3.6. Sequence Number . . . . . . . . . . . . . . . . . . . 9 - 3.3.7. Lifetimes and Timers . . . . . . . . . . . . . . . . . 9 + 3.3.4. Security Parameter Index (SPI) . . . . . . . . . . . 8 + 3.3.5. Supported Ciphers . . . . . . . . . . . . . . . . . . 8 + 3.3.6. Sequence Number . . . . . . . . . . . . . . . . . . . 8 + 3.3.7. Lifetimes and Timers . . . . . . . . . . . . . . . . 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 . . . . . . . . 9 3.4.2. HIP Signaling Packet Considerations . . . . . . . . . 10 - 4. The Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 4.1. ESP in HIP . . . . . . . . . . . . . . . . . . . . . . . . 11 - 4.1.1. IPsec ESP Transport Format Type . . . . . . . . . . . 11 - 4.1.2. Setting Up an ESP Security Association . . . . . . . . 11 + 4. The Protocol . . . . . . . . . . . . . . . . . . . . . . . . 10 + 4.1. ESP in HIP . . . . . . . . . . . . . . . . . . . . . . . 10 + 4.1.1. IPsec ESP Transport Format Type . . . . . . . . . . . 10 + 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.1. New Parameters . . . . . . . . . . . . . . . . . . . . . . 13 - 5.1.1. ESP_INFO . . . . . . . . . . . . . . . . . . . . . . . 13 - 5.1.2. ESP_TRANSFORM . . . . . . . . . . . . . . . . . . . . 15 - 5.1.3. NOTIFICATION Parameter . . . . . . . . . . . . . . . . 16 - 5.2. HIP ESP Security Association Setup . . . . . . . . . . . . 16 - 5.2.1. Setup During Base Exchange . . . . . . . . . . . . . . 16 - 5.3. HIP ESP Rekeying . . . . . . . . . . . . . . . . . . . . . 18 + 5. Parameter and Packet Formats . . . . . . . . . . . . . . . . 12 + 5.1. New Parameters . . . . . . . . . . . . . . . . . . . . . 12 + 5.1.1. ESP_INFO . . . . . . . . . . . . . . . . . . . . . . 13 + 5.1.2. ESP_TRANSFORM . . . . . . . . . . . . . . . . . . . . 14 + 5.1.3. NOTIFICATION Parameter . . . . . . . . . . . . . . . 16 + 5.2. HIP ESP Security Association Setup . . . . . . . . . . . 16 + 5.2.1. Setup During Base Exchange . . . . . . . . . . . . . 16 + 5.3. HIP ESP Rekeying . . . . . . . . . . . . . . . . . . . . 18 5.3.1. Initializing Rekeying . . . . . . . . . . . . . . . . 18 5.3.2. Responding to the Rekeying Initialization . . . . . . 19 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 19 5.4.1. Unknown SPI . . . . . . . . . . . . . . . . . . . . . 19 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 20 - 6.1. Processing Outgoing Application Data . . . . . . . . . . . 20 - 6.2. Processing Incoming Application Data . . . . . . . . . . . 20 + 6.1. Processing Outgoing Application Data . . . . . . . . . . 20 + 6.2. Processing Incoming Application Data . . . . . . . . . . 20 6.3. HMAC and SIGNATURE Calculation and Verification . . . . . 21 - 6.4. Processing Incoming ESP SA Initialization (R1) . . . . . . 21 + 6.4. Processing Incoming ESP SA Initialization (R1) . . . . . 21 6.5. Processing Incoming Initialization Reply (I2) . . . . . . 22 - 6.6. Processing Incoming ESP SA Setup Finalization (R2) . . . . 22 + 6.6. Processing Incoming ESP SA Setup Finalization (R2) . . . 22 6.7. Dropping HIP Associations . . . . . . . . . . . . . . . . 22 - 6.8. Initiating ESP SA Rekeying . . . . . . . . . . . . . . . . 22 - 6.9. Processing Incoming UPDATE Packets . . . . . . . . . . . . 24 - 6.9.1. Processing UPDATE Packet: No Outstanding Rekeying - Request . . . . . . . . . . . . . . . . . . . . . . . 24 + 6.8. Initiating ESP SA Rekeying . . . . . . . . . . . . . . . 22 + 6.9. Processing Incoming UPDATE Packets . . . . . . . . . . . 24 + 6.9.1. Processing UPDATE Packet: No Outstanding + Rekeying Request . . . . . . . . . . . . . . . . . . 24 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 . . . . . . . . . . . . . . . . . . 29 - Appendix A. A Note on Implementation Options . . . . . . . . . . 30 - Appendix B. Bound End-to-End Tunnel mode for ESP . . . . . . . . 30 - B.1. Protocol definition . . . . . . . . . . . . . . . . . . . 31 - B.1.1. Changes to Security Association data structures . . . 31 - B.1.2. Packet format . . . . . . . . . . . . . . . . . . . . 31 - B.1.3. Cryptographic processing . . . . . . . . . . . . . . . 33 - B.1.4. IP header processing . . . . . . . . . . . . . . . . . 33 - B.1.5. Handling of outgoing packets . . . . . . . . . . . . . 34 - B.1.6. Handling of incoming packets . . . . . . . . . . . . . 35 - B.1.7. IPv4 options handling . . . . . . . . . . . . . . . . 35 + 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 + 11.1. Normative references . . . . . . . . . . . . . . . . . . 28 + 11.2. Informative references . . . . . . . . . . . . . . . . . 29 + Appendix A. A Note on Implementation Options . . . . . . . . . . 31 + Appendix B. Bound End-to-End Tunnel mode for ESP . . . . . . . . 31 + B.1. Protocol definition . . . . . . . . . . . . . . . . . . . 32 + B.1.1. Changes to Security Association data structures . . . 32 + B.1.2. Packet format . . . . . . . . . . . . . . . . . . . . 32 + B.1.3. Cryptographic processing . . . . . . . . . . . . . . 34 + B.1.4. IP header processing . . . . . . . . . . . 34 + B.1.5. Handling of outgoing packets . . . . . . . . . . . . 35 + B.1.6. Handling of incoming packets . . . . . . . . . . . . 36 + B.1.7. IPv4 options handling . . . . . . . . . . . . . . . . 36 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 allows any two HIP-supporting hosts to authenticate each other and to create a HIP association between themselves. During the base exchange, the hosts generate a piece of shared keying material using an authenticated Diffie-Hellman exchange. @@ -236,26 +234,26 @@ corresponding host implements it, instead the corresponding host can have ESP transport mode and do HIT IP conversions outside ESP. 3.2.1. Semantics of the Security Parameter Index (SPI) SPIs are used in ESP to find the right Security Association for received packets. The ESP SPIs have added significance when used with HIP; they are a compressed representation of a pair of HITs. Thus, SPIs MAY be used by intermediary systems in providing services like address mapping. Note that since the SPI has significance at - the receiver, only the < DST, SPI >, where DST is a destination IP + the receiver, only the ?< DST, SPI >?, where DST is a destination IP address, uniquely identifies the receiver HIT at any given point of - time. The same SPI value may be used by several hosts. A single < - DST, SPI > value may denote different hosts and contexts at different - points of time, depending on the host that is currently reachable at - the DST. + time. The same SPI value may be used by several hosts. A single ?< + DST, SPI >? value may denote different hosts and contexts at + different points of time, depending on the host that is currently + reachable at the DST. Each host selects for itself the SPI it wants to see in packets received from its peer. This allows it to select different SPIs for different peers. The SPI selection SHOULD be random; the rules of Section 2.1 of the ESP specification [RFC4303] must be followed. A different SPI SHOULD be used for each HIP exchange with a particular host; this is to avoid a replay attack. Additionally, when a host rekeys, the SPI MUST be changed. Furthermore, if a host changes over to use a different IP address, it MAY change the SPI. @@ -668,21 +666,21 @@ Suite ID Value RESERVED 0 AES-128-CBC with HMAC-SHA1 1 [RFC3602], [RFC2404] DEPRECATED 2 DEPRECATED 3 DEPRECATED 4 DEPRECATED 5 DEPRECATED 6 - NULL-ENCRYPT with HMAC-SHA-256 7 [RFC2410], [RFC4868] + NULL with HMAC-SHA-256 7 [RFC2410], [RFC4868] AES-128-CBC with HMAC-SHA-256 8 [RFC3602], [RFC4868] AES-256-CBC with HMAC-SHA-256 9 [RFC3602], [RFC4868] AES-CCM-8 10 [RFC4309] AES-CCM-16 11 [RFC4309] AES-GCM with a 8 octet ICV 12 [RFC4106] AES-GCM with a 16 octet ICV 13 [RFC4106] AES-CMAC-96 14 [RFC4493], [RFC4494] AES-GMAC 15 [RFC4543] The sender of an ESP transform parameter MUST make sure that there @@ -727,22 +724,22 @@ The ESP Security Association is set up during the base exchange. The following subsections define the ESP SA setup procedure using both base exchange messages (R1, I2, R2) and UPDATE messages. 5.2.1. Setup During Base Exchange 5.2.1.1. Modifications in R1 The ESP_TRANSFORM contains the ESP modes supported by the sender, in - the order of preference. All implementations MUST support AES-128- - CBC [RFC3602] with HMAC-SHA-256 [RFC4868]. + the order of preference. All implementations MUST support AES- + 128-CBC [RFC3602] with HMAC-SHA-256 [RFC4868]. The following figure shows the resulting R1 packet layout. The HIP parameters for the R1 packet: IP ( HIP ( [ R1_COUNTER, ] PUZZLE, DIFFIE_HELLMAN, HIP_CIPHER, ESP_TRANSFORM, @@ -751,22 +748,22 @@ HIP_SIGNATURE_2 ) [, ECHO_REQUEST ]) 5.2.1.2. Modifications in I2 The ESP_INFO contains the sender's SPI for this association as well as the KEYMAT index from where the ESP SA keys will be drawn. The old SPI value is set to zero. The ESP_TRANSFORM contains the ESP mode selected by the sender of R1. - All implementations MUST support AES-128-CBC [RFC3602] with HMAC-SHA- - 256 [RFC4868]. + All implementations MUST support AES-128-CBC [RFC3602] with HMAC- + SHA-256 [RFC4868]. The following figure shows the resulting I2 packet layout. The HIP parameters for the I2 packet: IP ( HIP ( ESP_INFO, [R1_COUNTER,] SOLUTION, DIFFIE_HELLMAN, HIP_CIPHER, @@ -1229,30 +1226,39 @@ using the Diffie-Hellman procedure. The initial setup of ESP SA between the hosts is done during the base exchange, and the message exchange is protected using methods provided by base exchange. Changes in connection parameters means basically that the old ESP SA is removed and a new one is generated once the UPDATE message exchange has been completed. The message exchange is protected using the HIP association keys. Both HMAC and signing of packets is used. 9. IANA Considerations - This document defines additional parameters and NOTIFY error types - for the Host Identity Protocol [I-D.ietf-hip-rfc5201-bis]. + The following changes to the "Host Identity Protocol (HIP) + Parameters" registries are requested. In all cases, the changes + required are to update the reference from [RFC5202] to this + specification. - The new parameters and their type numbers are defined in - Section 5.1.1 and Section 5.1.2, and they have been added to the - Parameter Type namespace specified in [I-D.ietf-hip-rfc5201-bis]. + This document defines two Parameter Types and two NOTIFY Message + Types for the Host Identity Protocol [I-D.ietf-hip-rfc5201-bis]. + + The parameters and their type numbers are defined in Section 5.1.1 + and Section 5.1.2, and they have been added to the Parameter Type + namespace created by [I-D.ietf-hip-rfc5201-bis]. No new action + regarding these values are required by this specification, other than + updating the reference from [RFC5202] to this specification. The new NOTIFY error types and their values are defined in Section 5.1.3, and they have been added to the Notify Message Type - namespace specified in [I-D.ietf-hip-rfc5201-bis]. + namespace created by [I-D.ietf-hip-rfc5201-bis]. No new action + regarding these values are required by this specification, other than + updating the reference from [RFC5202] to this specification. 10. Acknowledgments 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 providing comments and modification proposals. The list of people include Tom Henderson, Jeff Ahrenholz, Jan Melen, Jukka Ylitalo, and Miika Komu. Especially, the authors want to thank Pekka Nikander for his invaluable contributions to the document since the first draft @@ -1263,104 +1269,99 @@ 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 valuable feedback, and our apologies to anyone whose name is missing. 11. References 11.1. Normative references - [I-D.ietf-hip-rfc5201-bis] Moskowitz, R., Heer, T., Jokela, P., and - T. Henderson, "Host Identity Protocol - Version 2 (HIPv2)", - draft-ietf-hip-rfc5201-bis-14 (work in - progress), October 2013. + [I-D.ietf-hip-rfc5201-bis] + Moskowitz, R., Heer, T., Jokela, P., and T. Henderson, + "Host Identity Protocol Version 2 (HIPv2)", draft-ietf- + hip-rfc5201-bis-14 (work in progress), October 2013. - [RFC2119] Bradner, S., "Key words for use in RFCs - to Indicate Requirement Levels", BCP 14, - RFC 2119, March 1997. + [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. + [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. + [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. + [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. + [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. + [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. + [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM + Mode with IPsec Encapsulating Security Payload (ESP)", RFC + 4309, December 2005. - [RFC4493] Song, JH., Poovendran, R., Lee, J., and - T. Iwata, "The AES-CMAC Algorithm", - RFC 4493, June 2006. + [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The + AES-CMAC Algorithm", RFC 4493, June 2006. - [RFC4494] Song, JH., Poovendran, R., and J. Lee, - "The AES-CMAC-96 Algorithm and Its Use - with IPsec", RFC 4494, June 2006. + [RFC4494] Song, JH., Poovendran, R., and J. Lee, "The AES-CMAC-96 + Algorithm and Its Use with IPsec", RFC 4494, June 2006. - [RFC4543] McGrew, D. and J. Viega, "The Use of - Galois Message Authentication Code (GMAC) - in IPsec ESP and AH", RFC 4543, May 2006. + [RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message + Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, + May 2006. - [RFC4868] Kelly, S. and S. Frankel, "Using HMAC- - SHA-256, HMAC-SHA-384, and HMAC-SHA-512 - with IPsec", RFC 4868, May 2007. + [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- + 384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007. 11.2. Informative references - [I-D.ietf-hip-rfc4423-bis] Moskowitz, R. and M. Komu, "Host Identity - Protocol Architecture", - draft-ietf-hip-rfc4423-bis-06 (work in - progress), November 2013. + [I-D.ietf-hip-rfc4423-bis] + Moskowitz, R. and M. Komu, "Host Identity Protocol + Architecture", draft-ietf-hip-rfc4423-bis-08 (work in + progress), April 2014. - [RFC0791] Postel, J., "Internet Protocol", STD 5, - RFC 791, September 1981. + [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September + 1981. - [RFC4301] Kent, S. and K. Seo, "Security - Architecture for the Internet Protocol", - RFC 4301, December 2005. + [RFC4301] Kent, S. and K. Seo, "Security Architecture for the + Internet Protocol", RFC 4301, December 2005. - [RFC5206] Henderson, T., Ed., "End-Host Mobility - and Multihoming with the Host Identity + [RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the + Encapsulating Security Payload (ESP) Transport Format with + the Host Identity Protocol (HIP)", RFC 5202, April 2008. + + [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "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) + [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. + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. - [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. - Eronen, "Internet Key Exchange Protocol - Version 2 (IKEv2)", RFC 5996, - September 2010. + [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 @@ -1566,22 +1567,22 @@ source and destination addresses, exactly as defined in the SA. This verification MAY be explicit, or it MAY be implicit, for example, as a result of prior policy processing. Note that in some implementations there may be no real IP header at this time but the source and destination addresses may be carried out-of- band. In case the source address is still unassigned, it SHOULD be ensured that the designated inner source address would be selected at a later stage. 2. The IP payload (the contents of the packet beyond the IP header) - is wrapped into an ESP header as defined in [RFC4303] Section - 3.3. + is wrapped into an ESP header as defined in [RFC4303] + Section 3.3. 3. A new IP header is constructed, replacing the original one. The new IP header MUST contain the outer source and destination addresses, as defined in the SA. Note that in some implementations there may be no real IP header at this time but the source and destination addresses may be carried out-of-band. In the case where the source address must be left unassigned, it SHOULD be made sure that the right source address is selected at a later stage. Other than the addresses, it is RECOMMENDED that the new IP header copies the fields from the original IP header. @@ -1672,21 +1673,21 @@ Petri Jokela Ericsson Research NomadicLab JORVAS FIN-02420 FINLAND Phone: +358 9 299 1 EMail: petri.jokela@nomadiclab.com Robert Moskowitz - ICSAlabs, An Independent Division of Verizon Business Systems + Verizon Telcom and Business 1000 Bent Creek Blvd, Suite 200 Mechanicsburg, PA USA EMail: rgm@icsalabs.com Jan Melen Ericsson Research NomadicLab JORVAS FIN-02420 FINLAND