Network Working Group S. Jeong Internet-Draft M-K. Shin Intended status: Informational ETRI Expires: May 7, 2009 S. Lee TmaxSoft November 3, 2008 Applicability Issues of IPsec in NAT-PT draft-lee-ipsec-nat-pt-applicability-03.txt Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 7, 2009. Abstract NAT-PT (Network Address Translation - Protocol Translation) mechanism that has been deprecated in [RFC4966] comes into spotlight again. The use-cases that NAT-PT addresses still need to be discussed and the requirements persist in IPv6 transition work. This document discusses the applicability issues when applying IPsec protocol to NAT-PT mechanism. Jeong, et al. Expires May 7, 2009 [Page 1] Internet-Draft Applicability Issues of IPsec in NAT-PT November 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. IPsec Support Scenarios in NAT-PT . . . . . . . . . . . . . . 3 3.1. Case 1: Transport Mode Operation . . . . . . . . . . . . . 4 3.2. Case 2: Tunneling Mode Operation . . . . . . . . . . . . . 4 4. IPsec Applicability Issues in NAT-PT . . . . . . . . . . . . . 4 4.1. Issues for Negotiation of NAT-Traversal in the IKE . . . . 5 4.1.1. Basic IP Operation Issue . . . . . . . . . . . . . . . 5 4.1.2. IDii Payload Type Issue . . . . . . . . . . . . . . . 6 4.1.3. IKE Phase 2 Step(Quick Mode) . . . . . . . . . . . . . 6 4.2. Transport Mode Issues . . . . . . . . . . . . . . . . . . 6 4.3. Tunneling Mode Issues . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Jeong, et al. Expires May 7, 2009 [Page 2] Internet-Draft Applicability Issues of IPsec in NAT-PT November 2008 1. Introduction NAT-PT (Network Address Translation - Protocol Translation) addresses the IPv6 deployment scenario where IPv6 only node in IPv6 only network communicates with IPv4 only node in IPv4 only network and vice versa. However, the original NAT-PT [RFC2766] has a limitation on supporting IPsec applications. There exists a similar problem in the NAT. In order to solve the problem, a few solutions were proposed for IPsec NAT traversal [RFC3947][RFC3948]. This document discusses the applicability issues when applying IPsec protocol to NAT-PT mechanism. 2. Terminology o IPv6-only node : A node that implements IPv6 and does not support IPv4 stack. o IPv4-only node : A node that implements IPv4 and does not support IPv6 stack. o NAT-PT : The NAT-PT refers to IPv4/IPv6 transition mechanism that translates an IPv4 address into an IPv6 address and vice versa [RFC2766]. 3. IPsec Support Scenarios in NAT-PT IPv6-only node can communicate with IPv4-only node via NAT-PT. To secure bi-directional traffic security between IPv6-only node and IPv4-only node in the NAT-PT environment, the IPv6-only node can use IPsec protocols[AH],[ESP] with two types of IPsec mode. IPsec uses two protocols in order to provide traffic security -- Authentication Header(AH) and Encapsulation Security Payload (ESP). Both protocols are described in more detail in their respective RFCs [RFC2402][RFC2406]. These protocols may be applied alone or in combination with each other so as to provide a desired set of security services in IPv4 and IPv6. In this document, we consider ESP protocol only in order to simplify scenarios. Each protocol supports two types of secure mode that can be applicable to NAT-PT: Transport mode and Tunnel mode. The detailed description of the two modes are discussed in the following section. Jeong, et al. Expires May 7, 2009 [Page 3] Internet-Draft Applicability Issues of IPsec in NAT-PT November 2008 3.1. Case 1: Transport Mode Operation Transport Mode is most commonly used to provide end-to-end security between IPv6-only and IPv4-only node across the NAT-PT. IPv6-only node initiates IKE negotiation with the IPv4-only node to make security association across the NAT-PT before encapsulating UDP Tunneling packtes for NAT-PT traversal. IPv6-only node ------------ NAT-PT----------------- IPv4-only node | | | | | | | | | | ----------Security Association 1----------------| | | (ESP transport) | | | |-------------Security Association 2------------------| (AH transport) Figure 1: Transport Mode in NAT-PT 3.2. Case 2: Tunneling Mode Operation When Tunneling Mode is applied, the peer node is not involved in the IPsec steps. On the contrary to above scenario, IPv6-only and IPv4- only node are not the endpoints which negotiates security association. GW-1(Gateway),GW-2(Gateway) will be charge of the IKE negotiation and Tunneling for encapsulation/decapsuation procedures. IPv6-only node ----GW-1-------- NAT-PT----------GW-2----- IPv4-only node | | | | | | | | | |--Security Association 1-- | | (ESP transport) | | | |----Security Association 2----| (AH transport) Figure 2: Tunneling Mode in NAT-PT 4. IPsec Applicability Issues in NAT-PT This section is split into two parts. The first part describes the issues related to applying the IKE Phase1, Phase2 of NAT-Traversal mechanism to NAT-PT environment. The second part describes the detailed issues when applied with Jeong, et al. Expires May 7, 2009 [Page 4] Internet-Draft Applicability Issues of IPsec in NAT-PT November 2008 Tunneling Mode and Transport Mode. 4.1. Issues for Negotiation of NAT-Traversal in the IKE If there is no SA(Security Association) in IPv6-only node, it starts the IKE negotiation and creates the SAs when it finished negotiation. For example, IPv6 node implemented with Linux launches the Racoon that is the IKE Daemon to exchange IKE messages. To support the IKE negotiation in NAT-PT, IPv6-only node sends the detection packets to the IPv4-only node in order to check the existence of NATs between the peers using a NAT-Traversal mechanism [RFC3947]. The following example is IKE Phase1 Exchange using NAT-Traversal with Main Mode (Authentication with pre-shared key) in NAT-PT : IPv6 Node A NAT-PT IPv4 Node B -------------------------------------------------------------------- UDP(500,500) HDR, SA, VID --> <---- UDP(500,X) HDR, SA, VID UDP(500,500) HDR, KE, Ni, NAT-D, NAT-D --> <---- UDP(500,X) HDR, KE, Ni, NAT-D, NAT-D UDP(4500,4500) HDR*#, IDii, HASH_I --> <--- UDP(4500,Y)HDR*#, IDir, HASH_R --------------------------------------------------------------------- Figure 3: NAT-Traversal in NAT-PT ping6 aaaa:bbbb:cccc::129.254.114.20 --> * NAT-PT Prefix : aaaa:bbbb:cccc::/96 * NAT-PT address pool :129.254.144.1-15 * Router Advertisement Prefix : 220:220:101a:3::1/64 * Node A :220:220:101a:3::213:d4ff:fec2:a2bd/64 * Node B : 129.254.114.20 4.1.1. Basic IP Operation Issue IPv6 Node A wants to communicate with the IPv4 Node B in the NAT-PT. Thus, IPv6 Node A creates a packet with : Jeong, et al. Expires May 7, 2009 [Page 5] Internet-Draft Applicability Issues of IPsec in NAT-PT November 2008 Source Address, SA = 220:220:101a:3::213:d4ff:fec2:a2bd/64 (The /64 prefix is NAT-PT's advertisement message) Destination Address, DA = aaaa:bbbb:cccc::129.254.114.20/96 (NAT-PT PREFIX::/96) This packet is routed to the NAT-PT gateway, where the packet will be translated to IPv4 format [RFC2766]. i.e : SA = 129.254.114.1 (one of the NAT-PT's IPv4 address pool), DA = 129.254.114.20 4.1.2. IDii Payload Type Issue This issue is caused by applying IKE to the NAT-PT environment because IKE address identifier is being used as an identifier in IKE Phase1 or Phase2 : o IPv6 Node A sets the ID type value to ID_IPV6_ADDR(5) in the IDii payload o IPv4 Node B receives the packet with IPv4 SRC, IPv4 DST whose addresses were changed in NAT-PT, but IDii payload's Identifier type still has a IPv6 address type. Since the modification of IP source or destination address is occurred in the NAT-PT, the IKE's identifier will not match. Thus in order to apply IPsec to NAT-PT, ID_FQDN or ID_USER_FQDN[RFC2766] should be used in the identifier of peer node. 4.1.3. IKE Phase 2 Step(Quick Mode) After the Phase1 step, the Phase2 of IKE operation starts to get IPsec parameters such as the type of UDP encapsulated IPsec packets in IKE's Quick Mode. These encapsulation modes are: UDP-Encapsulated-Tunnel 3 UDP-Encapsulated-Transport 4 The two types of encapsulation mode can be support in NAT-PT, but due to the issues in Section 4.2, it is recommended to use the transport mode only in NAT-PT environment. 4.2. Transport Mode Issues In case of applying the UDP-Encapsulated-Transport mode between IPv6 node and IPv4 node, both peers know how to calculate the incremental Jeong, et al. Expires May 7, 2009 [Page 6] Internet-Draft Applicability Issues of IPsec in NAT-PT November 2008 TCP checksum. To solve the problem, [RFC3977] suggests the NAT-OA (NAT Original Address) payload. NAT-OA payload is included in the first and second packets of Quick Mode. In the NAT-PT environment, Node A sends the NAT-OA Payload encapsulated UDP with IDii type is ID_IPv6_ADDR and IPv6 address embedded the Identifier data field. If the IPv6 packet crosses the NAT-PT, the NAT-PT changes the outer header of the IPv6 packet into IPv4 header. But the NAT-OA in the payload is not chanaged, because the above transport layer is encrypted by authentication algorithm. On receiving the packets to the IPv4 node, the packets may recalculate using NAT-OA payload to verify TCP/IP checksum. But, IPv4 node has only native IPv4 network protocol stack, so it cannot parse the NAT-OA option. This will may raise the issues for IPsec to apply in NAT-PT environment. 4.3. Tunneling Mode Issues When a tunneling mode is applied to secure packets between peers, the outer IP header is changed by NAT-PT from IPv6 HDR to IPv4 HDR. This will cause the tunneling issue for IPsec application to the NAT-PT. Below is a diagram for the tunneling mode : STEP-1 :/* Before Applying ESP/UDP from IPv6 Node */ [IPv6 HDR][TCP][DATA] STEP-2 : /* After Applying ESP/UDP from IPv6 Node */ [IPv6 HDR][UDP HDR][ESP HDR][IPv6 HDR][TCP][DATA][ESP Trailer][ESP AUTH] STEP-3 : /* via the NAT-PT */ [IPv4 HDR][UDP HDR][ESP HDR][IPv6 HDR][TCP][DATA][ESP Trailer][ESP AUTH] The IPv4 Node is waiting the UDP-Encapsulated ESP packets on port 4500. The procedures for incoming packets below : o On receiving the packets, IPv4 node removes outer IPv4 HDR and UDP HDR. o Using a existing SA (Security Association) value, the packets will be decrypted by authentication algorithm using pre-shared key. However, the decrypted IPv6 packet cannot forward to the local network protocol stack, because the IPv4 node did not support the Jeong, et al. Expires May 7, 2009 [Page 7] Internet-Draft Applicability Issues of IPsec in NAT-PT November 2008 IPv6 header processing. Therefore, the tunneling mode operation is not suitable for IPsec traversal for in the NAT-PT. 5. IANA Considerations This draft does not require any actions from IANA. 6. Security Considerations This document discusses IPsec applicability issues in NAT-PT and does not incur any additional security vulnerability. 7. References 7.1. Normative References [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000. [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation (NAT) Compatibility Requirements", RFC 3715, March 2004. [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005. [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005. [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status", RFC 4966, July 2007. Jeong, et al. Expires May 7, 2009 [Page 8] Internet-Draft Applicability Issues of IPsec in NAT-PT November 2008 7.2. Informative References [I-D.choi-v6ops-natpt-ipsec] Choi, I., "IPsec support for NAT-PT in IPv6", draft-choi-v6ops-natpt-ipsec-00 (work in progress), October 2004. Authors' Addresses Sangjin Jeong ETRI 161 Gajeong-dong, Yuseong-gu Daejeon, 305-700 Korea Phone: +82-42-860-1877 Email: sjjeong@gmail.com Myung-Ki Shin ETRI 161 Gajeong-dong, Yuseong-gu Daejeon, 305-700 Korea Phone: +82-42-860-4847 Email: mkshin@etri.re.kr Sangdo Lee TmaxSoft 272-6 Seohyeon-dong, Bundang-gu Sungnam, Korea Phone: Email: doyaa2@gmail.com Jeong, et al. Expires May 7, 2009 [Page 9] Internet-Draft Applicability Issues of IPsec in NAT-PT November 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Jeong, et al. Expires May 7, 2009 [Page 10]