Internet Draft Inseok Choi v6ops Working Group Souhwan Jung Expires: April 18, 2005 Younghan Kim Soongsil University Yongseok Park Duyoung Oh Samsung Electronics October 18, 2004 IPsec support for NAT-PT in IPv6 draft-choi-v6ops-natpt-ipsec-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 April 14, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract The NAT-PT, one of the IPv6 transition mechanisms, supports IPv6 node in a NAT-PT domain to communicate with IPv4-only nodes outside. However, due to the IP datagram conversion at the NAT-PT server, NAT-PT node has a problem in establishing the end-to-end security using the IPsec IKE and AH mode. This memo describes the reason why the problem is caused and proposes a solution for assuring the end-to-end security using IPsec in the NAT-PT environment. Choi [Expires April 2005] [Page 1] Internet-Draft IPsec support for NAT-PT in IPv6 February 2004 Table of Contents 1. Introduction.....................................................3 2. End-to-end IPsec security issue in NAT-PT environment............3 2.1. IKE negotiation..............................................3 2.2. IPsec AH operation...........................................4 3. IP Header Translation Information (IP HTI).......................4 4. IKE negotiation using IP HTI.....................................5 5. AH operation using IP HTI........................................7 6. Modified operations of NAT-PT server and node...................10 6.1. NAT-PT Server operation...................................10 6.2. NAT-PT node operation.....................................10 7. Security Considerations.........................................11 References.........................................................11 Choi [Expires April 2005] [Page 2] Internet-Draft IPsec support for NAT-PT in IPv6 February 2004 1. Introduction NAT-PT[1] technology was proposed as one of the IPv6 transition mechanisms, and supports IPv6 node(thereafter NAT-PT node) inside the NAT-PT domain to communicate with the IPv4-only node outside. The basic mechanism of NAT-PT in IPv6 is very similar to the address translation at the NAT server operation in IPv4 networks. In IPv6 transition, however, the NAT-PT server converts IPv6 datagrams into the IPv4 datagrams after allocating a new IPv4 address to the NAT-PT node. Since the calculation of integrity value ICV in IPsec AH mode are based on the different parameters in IPv4 and Ipv6, applying the IPsec between the NAT-PT node and IPv4-only node fails due to the datagram conversion at the NAT-PT server. This memo describes a problem while applying IPsec to the nodes inside the NAT-PT environments, and proposes a method to solve the problem. 2. IPsec end-to-end security issues at NAT-PT environment Generic IPsec process starts with the IKE negotiation which establishes SA and key agreement[2]. After this steps, the main mode of IKE negotiation includes ID authentication against ID spoofing attack. The second phase of IKE establishes the SA agreement for IPsec treatment for the IP payloads. Using the SA and key information agreed through the IKE negotiation, IPsec ESP[3] or AH[4] modes are applied to support confidentiality or integrity of the IP datagrams. In the NAT-PT environments, however, applying IPsec transport mode causes a problem due to the datagram conversion at the NAT-PT server on route to the destination node. The problem happens at the first phase of the IKE negotiation and at the mode of IPsec AH operation. 2.1. IKE negotiation issue The main mode procedure of IKE negotiation includes the ID authentication. At the fifth and sixth steps of the main mode operations of IKE, both nodes exchange the ID information and hash values(HASH_I and HASH_R) verifying some information including the ID values. The IP addresses are usually used as the ID values in this procedure. The IP translation from IPv6 to IPv4 or vice versa at the NAT-PT server, however, causes the ID authentication to fail, because the IPv4 node at the destination is ignorant of the IP translation at the NAT-PT server, and verifies the hash value (HASH_I) based on the translated IP address, and is to fail the verification. The whole IKE negotiation procesure, therefore, also fails. Choi [Expires April 2005] [Page 3] Internet-Draft IPsec support for NAT-PT in IPv6 February 2004 2.2. IPsec AH mode issue IPsec AH transport mode provides an authentication function for the IP header and payload[4]. The ICV value at the AH mode is calculated using the IP header fields that is immutable or mutable, but predictable. The NAT-PT translation , however, changes some of the IP header fields and causes a problem in applying the AH function for end-to-end security. The IPv6 header format itself is different from the IPv4 header, and NAT-PT server in between the two nodes has to assign some of the IP header field values (e.g. IP datagram identification) by itself. Therefore, the ICV verification at the destination node fails. For the success of IPsec AH security, therefore, the NAT-PT server needs to provide the translation information to the NAT-PT node, which makes it possible for the NAT-PT node to calculate the ICV values based on the provided translation information. 3. IP Header Translation Information (IP HTI) This memo defines an IP Header Translation Information(IP HTI) that includes the translation parameter information at the NAT-PT server. This message SHOULD be provided by the NAT-PT server to the NAT-PT node during the IKE negotiation process, because the information is only necessary for IPsec operation. The NAT-PT node SHOULD use the information for calculating hash values in IKE negotiation or ICV values in AH mode. Figure 1 shows the format of the message. The main information of the message is the IPv4 address allocated by the NAT-PT server and the NAT-PT prefix information. The allocated IPv4 address is replaced as the ID information when calculating HASH_I or ICV value at the NAT-PT node. The prefix information of NAT-PT server is used for translating the IPv4 address of the IP datagram from IPv4 node into the IPv6 address. The NAT-PT server generates an IPv6 address by appending the delivered 32-bit IPv4 address to its own 96-bit prefix address. Using the prefix information, the NAT-PT node can distinguish IP datagrams through the NAT-PT server from IP datagrams from other IPv6 nodes. The NAT-PT node, therefore, SHOULD save the prefix information in a table until it finishes the corresponding IPsec session. Choi [Expires April 2005] [Page 4] Internet-Draft IPsec support for NAT-PT in IPv6 February 2004 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg-type | Reserved | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Allocated IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | NAT-PT prefix information | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: IP Header Translator Information(IP HTI) 4. IKE negotiation using IP HIT The NAT-PT node MAY establish a successful IKE negotiation with an IPv4 node outside using the IP HTI information. Figure 2 shows the steps of IKE negotiation proposed in this memo. In the figure, the NAT-PT server is an initiator of IKE operation, and the IPv4 node is the responder. Choi [Expires April 2005] [Page 5] Internet-Draft IPsec support for NAT-PT in IPv6 February 2004 IPv6 address = X prefix = Y IPv4 address = Z NAT-PT Node NAT-PT Server IPv4 node | | | | HDR, SA | HDR, SA | | -----------------> | -----------------> | | | | | IP HTI | HDR, SA | |(2)<+++++++++++++++++ :(1) <--------------- | | | | | HDR, SA | | |(3)<----------------- | | | | | | HDR, KE, Ni | HDR, KE, Ni | | -----------------> | -----------------> | | | | | HDR, KE, Nr | HDR, KE, Nr | | <----------------- | <----------------- | | | | | HDR*, IDii^, HASH_I^ | HDR*, IDii^, HASH_I^ | (4): #################> | #################> :(5) | | | | HDR*, IDir, HASH_R | HDR*, IDir, HASH_R | : <----------------- | <----------------- | (6)| | | * X = 2001:aaaa:bbbb::1 * Y = aaaa::0:0:0:0:0::/96 * Z = aaa.bbb.ccc.ddd * Allocated IPv4 address of NAT-PT Node = eee.fff.ggg.hhh * IDii^ : information include Allocated IPv4 address (eee.fff.ggg.hhh) * HASH_I^ : HASH value which compute using eee.fff.ggg.hhh * IP HTI : IP Header Translator Information Figure 2. IKE Process using IP Header Translator Information Upon receiving the IKE SA agreement information from the IPv4 node (Figure 2 (1)), the NAT-PT server generates the IP HTI message and sends it to the NAT-PT node(Figure 2 (2)). Right after sending the IP HTI message, the NAT-PT server forwards the IKE SA message to the NAT-PT node(Figure 2 (3)). The exchange of KE information is the same as the normal IKE process. Choi [Expires April 2005] [Page 6] Internet-Draft IPsec support for NAT-PT in IPv6 February 2004 As a step for ID authentication, the NAT-PT node SHOULD calculate HASH_I value using the IPv4 address information allocated in the IP HTI message(Figure 2 (4)). The NAT-PT server will forward the IKE message to the IPv4 node. But, the HASH_I value will remain the same while transmitted through the NAT-PT server (Figure 2 (5)). Then, the IPv4 node at destination can successfully verify the HASH_I value using the source IP address, which is the allocated IPv4 address. When receiving the final IKE message, the NAT-PT node performs ID authentication process. At this point, the NAT-PT node SHOULD check whether the 96-bit prefix address matches with any elements of the prefix table. If a match is found, the NAT-PT node extracts the IPv4 address from the delivered IPv6 address, and verify the HASH_R value based on the extracted IPv4 address (Figure 2 (6)). The detailed operations of NAT-PT server and NAT-PT node will be described at the Section 6. 5. IPsec AH operation using IP HTI The NAT-PT node SHOULD generate or verify the ICV value based on the IP HTI information. The following sections explain how to generate and verify the ICV value at the NAT-PT node. 5-1. Calculating the AH ICV value at the NAT-PT node Figure 3 shows the field values of virtual IPv4 header at the NAT-PT node for ICV calculation considering the translation at the NAT-PT node in advance. Choi [Expires April 2005] [Page 7] Internet-Draft IPsec support for NAT-PT in IPv6 February 2004 +------------------------+-----------------------------------------+ | Version | 4 | +------------------------+-----------------------------------------+ | Header Length | 20 | +------------------------+-----------------------------------------+ | Protocol | Payload Length + 20 | +------------------------+-----------------------------------------+ | Identification | * If no IPv6 fragment Header, set 0 | | | * If IPv6 Fragment Heder, | | | set Identifcation of Fragment Header | +------------------------+-----------------------------------------+ | Source Address | Allocated IPv4 address of IP HTI | | | | +------------------------+-----------------------------------------+ | Destination Address | 32 bit address except NAT-PT prefix | | | information of IP HTI | +------------------------+-----------------------------------------+ Figure 3. IP Header field value for ICV computation There is no way for the NAT-PT node to know the exact value of the Identification field in IP datagram. The Identification field will be assigned by the NAT-PT server in sequence while it is generating the IPv4 datagram. Hence, the NAT-PT node SHOULD use the Identification field value in the fragment header if a Fragment Header exists. Otherwise, the NAT-PT node SHOULD use the value 0 for the Identification field. Then, receiving this datagram, the NAT-PT server also sets the Identification field to 0, and sets the Don't Fragment bit to 1. The simple example of calculating the ICV value is as follows. (1) Without IPv6 Fragment Header ICV = (Version | Header Length | protocol | Identification | Source Address | Destination Address) = (4 | 120 | 51 | 0 | eee.fff.ggg.hhh | aaa.bbb.ccc.ddd) Source Address : 2001:aaaa:bbbb::1 Destination Address : aaaa::0:0:0:0:0:aaa.bbb.ccc.ddd Payload Length : 100 Protocol : 51 (AH protocol value) IP HTI : Allocated IPv4 address = eee.fff.ggg.hhh NAT-PT prefix information = aaaa::0:0:0:0:0::/96) Choi [Expires April 2005] [Page 8] Internet-Draft IPsec support for NAT-PT in IPv6 February 2004 (2) With IPv6 Fragment Header ICV = (Version | Header Length | protocol | Identification | Source Address | Destination Address) = (4 | 120 | 51 | 0 | eee.fff.ggg.hhh | aaa.bbb.ccc.ddd) Source Address : 2001:aaaa:bbbb::1 Destination Address : aaaa::0:0:0:0:0:aaa.bbb.ccc.ddd Payload Length : 100 Protocol : 51 (AH protocol value) IP HTI : Allocated IPv4 address = eee.fff.ggg.hhh NAT-PT prefix information = aaaa::0:0:0:0:0::/96) ID : Identification of IPv6 fragment header The details of NAT-PT server operation depending on the existence of IPv6 Fragment Header are explained in Section 6. 5-2. Verifying the ICV value of AH mode at the NAT-PT node The verification of the ICV value at the NAT-PT node has a problem since the Identification field of the IPv4 datagram from Ipv4 node is removed at the NAT-PT server. Then the NAT-PT node has no way to verify the ICV value without the original value of the Identification field. The NAT-PT server, therefore, SHOULD send the value of Identification field to the NAT-PT node using the IPv6 Fragment Header. The extension Fragment Header SHOULD include the Identification field from the IPv4 node. Then, the NAT-PT node can verify the ICV value by extracting the IPv4 address from the translated IPv6 header, and Identification value from the Fragment Header. Figure 4 shows how the NAT-PT node extracts the necessary field information to verify the ICV value. +------------------------+-----------------------------------------+ | Version | 4 | +------------------------+-----------------------------------------+ | Header Length | 20 | +------------------------+-----------------------------------------+ | Protocol | Payload Length + 20 | +------------------------+-----------------------------------------+ | Identification | Identifcation of IPv6 Fragment Header | +------------------------+-----------------------------------------+ | Source Address | 32 bit address except NAT-PT prefix | | | information of IP HTI | +------------------------+-----------------------------------------+ | Destination Address | Allocated IPv4 address of IP HTI | +------------------------+-----------------------------------------+ Figure 4. IP Header field value for ICV verification Choi [Expires April 2005] [Page 9] Internet-Draft IPsec support for NAT-PT in IPv6 February 2004 6. Modified operations of NAT-PT server and node 6.1 NAT-PT server operation The NAT-PT server operation SHOULD be modified at the following two cases. First, upon receiving the IKE SA from IPv4 node, it SHOULD generate the IP HTI message and send it to the NAT-PT node just before it forwards the IKE SA message from IPv4 mode. Second, when calculating the ICV value at AH mode, the NAT-PT server extracts the IP Identification number from the Fragment Header if a Fragment Header exists. If there is no Fragment Header in IPv6 datagram, the NAT-PT server can allocate an arbitrary number to the IP Identification field when translating the IP datagram. Then, the NAT-PT node cannot predict the Identification number field when calculating the AH ICV value. To solve this problem, the NAT-PT server MUST always set the Identification field to 0, and also set the Don't Fragment bit to 1. Since the Identification field is used only for reassembly of fragmented IP datagrams, this does not cause any new problem. 6.2 NAT-PT node operation The operation of the NAT-PT node SHOULD be modified at the following three cases. First, when receiving the IP HTI message from the NAT-PT server, the NAT-PT node recognizes itself belonging to a NAT-PT domain. Then it SHOULD save the allocated IPv4 address for calculating HASH_I and ICV value later, and also save the NAT-PT prefix information for identifying the translated datagrams through the NAT-PT server. Second, when calculating the HASH_I value, the NAT-PT node SHOULD use the allocated IPv4 address as the ID value instead of his own IPv6 address. Third, When calculating the ICV value, the NAT-PT node use the translated values of the Figure 4. Choi [Expires April 2005] [Page 10] Internet-Draft IPsec support for NAT-PT in IPv6 February 2004 7. Security Considerations This memo describes how to solve IPsec end-to-end security issue at IPv6 NAT-PT environment. Since this memo does not change or disgrade any of the IPsec security itself, the security of this memo is exactly the same as that of the IPsec. References [1] G. Tsirtsis, P. Srisuresh., "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000. [2] D. Harkins, D. Carrel., "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [3] S. Kent, R. Atkinson., "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [4] S. Kent, R. Atkinson., "IP Authentication Header", RFC 2402, November 1998. [5] S. Deering, R. Hinden., "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, December 1995 Authors' Addresses Inseok Choi Soongsil University 1-1, Sangdo-dong, Dongjak-ku Seoul 156-743 KOREA Phone: +82-2-824-1807 EMail: ischl@cns.ssu.ac.kr Souhwan Jung Soongsil University 1-1, Sangdo-dong, Dongjak-ku Seoul 156-743 KOREA Phone: +82-2-820-0714 EMail: souhwanj@ssu.ac.kr Choi [Expires April 2005] [Page 11] Internet-Draft IPsec support for NAT-PT in IPv6 February 2004 Younghan Kim Soongsil University 1-1, Sangdo-dong, Dongjak-ku Seoul 156-743 KOREA Phone: +82-2-820-0904 EMail: yhkim@dcn.ssu.ac.kr Yongseok Park Telecommunication R&D Center Samsung Electronics CO. LTD. Phone: +82-031-279-5180 EMail: yongseok.park@samsung.com Duyoung Oh Telecommunication R&D Center Samsung Electronics CO. LTD. Phone: +82-031-279-5628 EMail: duyoung.oh@samsung.com Intellectual Property Statement 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. Choi [Expires April 2005] [Page 12] Internet-Draft IPsec support for NAT-PT in IPv6 February 2004 Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2004). 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. Choi [Expires April 2005] [Page 13]