One document matched: draft-lee-ipsec-nat-pt-applicability-00.txt
Network Working Group S. Lee
Internet-Draft S. Jeong
Intended status: Informational H-J. Kim
Expires: December 28, 2007 ETRI
June 26, 2007
Applicability Issues for IPsec NAT-Traversal in NAT-PT
draft-lee-ipsec-nat-pt-applicability-00.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 December 28, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This memo describes how to apply IPsec protocol based on NAT-
Traversal mechanisms and applicability issues at NAT-PT.
Lee, et al. Expires December 28, 2007 [Page 1]
Internet-Draft IPsec NAT Traversal in NAT-PT June 2007
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
Lee, et al. Expires December 28, 2007 [Page 2]
Internet-Draft IPsec NAT Traversal in NAT-PT June 2007
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 apply IPsec based application to
the NAT-PT environment. To solve the similar problem the NAT in IPv4
network, some documents were suggested for traversal such as NAT-
Travesal [RFC3947][RFC3948].
This memo just 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 kinds of IPsec mode.
IPsec uses two protocols 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, AH is out of scope in this memo, just ESP protocol
will be used the reason for simplify 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.
Lee, et al. Expires December 28, 2007 [Page 3]
Internet-Draft IPsec NAT Traversal in NAT-PT June 2007
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. Contrary to as noted above, IPv6-only and IPv4-only
node are not the endpoints to negotiation for 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 two parts. The first describes the issues
while applying the IKE Phase1, Phase2 for NAT-Travesal mechanism in
NAT-PT environment.
The second part describes the detailed issues when applied with
Lee, et al. Expires December 28, 2007 [Page 4]
Internet-Draft IPsec NAT Traversal in NAT-PT June 2007
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. For
example, linux will lunch the Racoon,which is 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) <non-ESP market> HDR*#, IDii, HASH_I -->
<--- UDP(4500,Y)<non-ESP market>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 create a packet with :
Lee, et al. Expires December 28, 2007 [Page 5]
Internet-Draft IPsec NAT Traversal in NAT-PT June 2007
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 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
Lee, et al. Expires December 28, 2007 [Page 6]
Internet-Draft IPsec NAT Traversal in NAT-PT June 2007
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
Lee, et al. Expires December 28, 2007 [Page 7]
Internet-Draft IPsec NAT Traversal in NAT-PT June 2007
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.
Lee, et al. Expires December 28, 2007 [Page 8]
Internet-Draft IPsec NAT Traversal in NAT-PT June 2007
Authors' Addresses
Sangdo Lee
ETRI
161 Gajeong-dong, Yuseong-gu
Daejeon, 305-350
Korea
Phone: +82-42-860-6679
Email: doyaa2@gmail.com
Sangjin Jeong
ETRI
161 Gajeong-dong, Yuseong-gu
Daejeon, 305-350
Korea
Phone: +82-42-860-1877
Email: sjjeong@gmail.com
Hyoung-Jun Kim
ETRI
161 Gajeong-dong, Yuseong-gu
Daejeon, 305-350
Korea
Phone: +82-42-860-6576
Email: khj@etri.re.kr
Lee, et al. Expires December 28, 2007 [Page 9]
Internet-Draft IPsec NAT Traversal in NAT-PT June 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Lee, et al. Expires December 28, 2007 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-24 01:56:13 |