One document matched: draft-lee-ipsec-nat-pt-applicability-02.txt
Differences from draft-lee-ipsec-nat-pt-applicability-01.txt
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) <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 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]
| PAFTECH AB 2003-2026 | 2026-04-24 01:54:36 |