Network Working Group S. Jeong Internet-Draft M-K. Shin Intended status: Informational ETRI Expires: January 15, 2009 S. Lee TmaxSoft July 14, 2008 Applicability Issues for Supporting IPsec NAT-Traversal Mechanism in NAT-PT draft-lee-ipsec-nat-pt-applicability-02.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 January 15, 2009. Abstract This document describes applicability issues for supporting IPsec protocol at NAT-PT, which is based on the NAT-Traversal mechanism. Jeong, et al. Expires January 15, 2009 [Page 1] Internet-Draft IPsec NAT Traversal in NAT-PT July 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Scenarios for NAT-PT . . . . . . . . . . . . . . . . . . . . . 3 3.1. Case 1: Transport Mode operation . . . . . . . . . . . . . 4 3.2. Case 2: Tunneling Mode operation . . . . . . . . . . . . . 4 4. IPsec Applicabilty Issues in a NAT-PT environment . . . . . . 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 . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Jeong, et al. Expires January 15, 2009 [Page 2] Internet-Draft IPsec NAT Traversal in NAT-PT July 2008 1. Introduction Network Address Translation - Protocol Translation (NAT-PT) is one of the IPv6/IPv4 translation mechanisms, which can be possible allowing IPv6-only node to communicate with IPv4-only node and vice versa. But NAT-PT has some limitations to support applications utilizing IPsec in the NAT-PT environment. There exists a similar problem in the NAT. In order to solve the problem, some solutions were proposed for IPsec NAT traversal [RFC3947][RFC3948]. This document describes the applicabiltiy issues while applying IPsec protocol to the NAT-PT environment and the reasons why the problems was raised. 2. Terminology o IPv6-only node : A host that implements IPv6 and does not support IPv4 network stack. o IPv4-only node : A host that implements IPv4 and does not support IPv6 network stack. o NAT-PT : The NAT-PT refers to translation of an IPv4 address into an IPv6 address and vice versa[RFC2766]. 3. Scenarios for 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 to provide a desired set of security services in IPv4 and IPv6. In this document, we consider ESP protocol only for simplifying scenarios. Each protocol supports two secure mode operations to apply in the NAT-PT: Transport mode and Tunnel mode. The detailed cases will be described below. Jeong, et al. Expires January 15, 2009 [Page 3] Internet-Draft IPsec NAT Traversal in NAT-PT July 2008 3.1. Case 1: Transport Mode operation Transport Mode is most commonly used to provide end-to-end security beween 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 does not involve 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 eacapsulation/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 Applicabilty Issues in a NAT-PT environment This section is split into two parts. The first part describes the issues related to applying the IKE Phase1, Phase2 for NAT-Travesal mechanism in NAT-PT environment. The second part describes the detailed issues when applied with Jeong, et al. Expires January 15, 2009 [Page 4] Internet-Draft IPsec NAT Traversal in NAT-PT July 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, linux will lunch the Racoon,which is the IKE Daemon to exchange IKE messages. To support the IKE negotiation in the NAT-PT, IPv6-only node sends the dectection packets to the IPv4-only node to check whether there is one or more NATs between the peers using a NAT-Travesal technique [RFC3947]. The following example is Phase1 Exchange using NAT-Travesal with Main Mode(Authentication with pre-shared key) in a NAT-PT : IPv6 Host A NAT-PT IPv4 Host 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-Travesal 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 * Host A :220:220:101a:3::213:d4ff:fec2:a2bd/64 * Host B : 129.254.114.20 4.1.1. Basic IP operation Issue IPv6 Host A wants to communicate with the IPv4 Host B in the NAT-PT. Thus, IPv6 Host A creates a packet with : Jeong, et al. Expires January 15, 2009 [Page 5] Internet-Draft IPsec NAT Traversal in NAT-PT July 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 address[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 was caused by applying IKE to the NAT-PT environment because IKE address identifier is being used as an identifier in Internet Key Exchange protocol(IKE) Phase1 or Phase2 : o IPv6 Host A sets the ID type value to ID_IPV6_ADDR(5) in the IDii payload o IPv4 Host B receives the packet with IPv4 SRC, IPv4 DST which address was changed via NAT-PT, but IDii payload's Identifer type still has a IPv6 address type. Because the IP source or desination address modification was caused by the NAT-PT, the IKE's indentifier will mismatch. Thus to apply IPsec to the NAT-PT, peer's identifier should be used the ID_FQDN or ID_USER_FQDN[RFC2766]. 4.1.3. IKE Phase 2 step(Quick Mode) After the phase1 step, the second phase of IKE operation will start to get some IPsec parameters such as the type of UDP encapuslated IPsec packets in IKE's Quick Mode. These encapsulation modes are: UDP-Encapsulated-Tunnel 3 UDP-Encapuslated-Transport 4 The two types of encapsulation mode will be support in NAT-PT, but some reasons below secion 5.2 It recommend that use just the transport mode in NAT-PT environment. 4.2. Transport Mode issues In case of applying the UDP-Encapuslated-Transport mode between IPv6 Host and IPv4 Host, both peers know how to calculate the incremental Jeong, et al. Expires January 15, 2009 [Page 6] Internet-Draft IPsec NAT Traversal in NAT-PT July 2008 TCP checksum. To solve the problem, [RFC3977] suggests the NAT-OA (NAT Original Address)payload. NAT-OA payload is sent the first and second packets of Quick Mode. In the NAT-PT environment, Host 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 packets accrossing the NAT-PT, they will be changed their outer IPv6 HDR to IPv4 HDR. But inner the NAT-OA payload will not be chanaged. Because the above transport layer is encrypted by authentication algorithm. On receving the packets to the IPv4 host, the packets may recalculate using NAT-OA payload to verify TCP/IP checksum. But, IPv4 host 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 has been 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 Host */ [IPv6 HDR][TCP][DATA] STEP-2 : /* After Applying ESP/UDP from IPv6 Host */ [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 Host is waiting the UDP-Encapsulated ESP packets on port 4500. The procedures for incoming packets below : o On receiving the packets, IPv4 host removes outer IPv4 HDR and UDP HDR. o Using a existing SA(Security Association) value, the packets will be decrpyted by authentication algorithm using pre-shared key. But,the decrypted IPv6 packet cannot forward to the local network Jeong, et al. Expires January 15, 2009 [Page 7] Internet-Draft IPsec NAT Traversal in NAT-PT July 2008 protocol stack, because the IPv4 host did not support the IPv6 header processing[Re ferece to the STEP-3]. Therefore, the tunneling mode opeation is not suitable for IPsec travesal for in the NAT-PT. 5. IANA Considerations This draft does not require any actions from IANA. 6. Security Considerations TBD 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. 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. Jeong, et al. Expires January 15, 2009 [Page 8] Internet-Draft IPsec NAT Traversal in NAT-PT July 2008 Authors' Addresses Sangjin Jeong ETRI 161 Gajeong-dong, Yuseong-gu Daejeon, 305-350 Korea Phone: +82-42-860-1877 Email: sjjeong@gmail.com Myung-Ki Shin ETRI 161 Gajeong-dong, Yuseong-gu Daejeon, 305-350 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 January 15, 2009 [Page 9] Internet-Draft IPsec NAT Traversal in NAT-PT July 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 January 15, 2009 [Page 10]