One document matched: draft-choi-v6ops-natpt-ipsec-00.txt
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]| PAFTECH AB 2003-2026 | 2026-04-24 03:16:11 |