Network Working Group Xiangyang. Wu Internet-Draft Huawei Technologies Expires: March 25, 2006 September 21, 2005 UDP enhanced tunnel for traversing NAT draft-wu-behave-udp-tunnel-00 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 March 25, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This protocol specification describes a more generic method to encapsulate and decapsulate packets inside a UDP enhanced tunnel for traversing Network Address Translators (NATs). UDP enhanced tunnel header (UTH) encapsulation, as defined in this document, can be used in both IPv4 and IPv6 scenarios. Wu Expires March 25, 2006 [Page 1] Internet-Draft UDP enhanced tunnel for traversing NAT September 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology and Notation . . . . . . . . . . . . . . . . . . . 4 3. Basic technique . . . . . . . . . . . . . . . . . . . . . . . 5 4. UDP enhanced tunnel Header (UTH) Format . . . . . . . . . . . 7 5. Encapsulation and Decapsulation Procedures . . . . . . . . . . 8 5.1. xTC behaviors . . . . . . . . . . . . . . . . . . . . . . 8 5.1.1. xTC encapsulate packets . . . . . . . . . . . . . . . 8 5.1.2. xTC decapsulate packets . . . . . . . . . . . . . . . 9 5.2. xTS behaviors . . . . . . . . . . . . . . . . . . . . . . 9 5.2.1. xTS decapsulate packets . . . . . . . . . . . . . . . 9 5.2.2. xTS encapsulate packets . . . . . . . . . . . . . . . 9 6. The whole procedures description . . . . . . . . . . . . . . . 11 7. NAT Keepalive Procedure . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 11.2. Informative References . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Wu Expires March 25, 2006 [Page 2] Internet-Draft UDP enhanced tunnel for traversing NAT September 2005 1. Introduction RFC3948 [3] has given a method to solve the NAT (Network Address Translators) traversal problem of IPSec ESP packets, it uses a UDP encapsulation. This protocol specification describes a more generic method to encapsulate and decapsulate packets inside a UDP enhanced tunnel for traversing Network Address Translators (NATs). Some signaling protocol, such as h.323, use multi protocols (RAS(Registration,Admission and Status), h.225.0, etc) in it's signaling procedures. The previous procedure (RAS) negotiates/ allocates transport address that will be used in subsequence procedures. And often, the negotiated/allocated transport address is different than the initial protocol uses. If a network element in internal of NAT allocates a transport address and notifies it to the external network element, the external element can connect to it for subsequence procedure continues. But cause the hindrance of NAT, this inbound connection to internal element will be forbidden by NAT in generally. To cope with this situation, we introduce a UDP enhanced tunnel between internal element and external element. In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC2119 [2] and indicate requirement levels for compliant implementations. Wu Expires March 25, 2006 [Page 3] Internet-Draft UDP enhanced tunnel for traversing NAT September 2005 2. Terminology and Notation The following terms are used throughout the document. UDP enhanced tunnel a logical tunnel created between xTC and xTS, which use UTH encapsulation UTH UDP enhanced Tunnel Header, the encapsulation format for UDP enhanced tunnel xTC traversal Tunnel Client; it is the client side of a logical tunnel which use UTH encapsultion, the tunnel is initiated from xTC to xTS xTS traversal Tunnel Server; it is the server side of a logical tunnel which use UTH encapsultion, the tunnel is terminated on xTS ALG Application Level Gateway Wu Expires March 25, 2006 [Page 4] Internet-Draft UDP enhanced tunnel for traversing NAT September 2005 3. Basic technique To aid the packet traversing NAT, two logical element are introduced in network(see Figure 1), they located at two sides of NAT. The element located in internal of NAT is referred as Traversal Tunnel Client (xTC), and the element located in external of NAT is referred as Traversal Tunnel Server (xTS). A tunnel that used between xTC and xTS is referred as UDP enhanced tunnel, which use encapsulation and decapsulation techniques described in Section 4, Section 5. network layout before introduction of xTC and xTS ------ -------- ------ | | | | | | | I |<--->| NAT |<--->| E | | | | | | | ------ -------- ------ network layout after introduction of xTC and xTS ------ ------- -------- ------- ------ | | | | | | | | | | | I |<--->| xTC |<--->| NAT |<--->| xTS |<--->| E | | | | | | | | | | | ------ ------- -------- ------- ------ I-internal network element E-external network element xTC-traversal tunnel client xTS-traversal tunnel Server Figure 1: Introduce xTC and xTS to aid traversing NAT A UDP enhanced tunnel (see Section 4, Section 5 for details) establishes from xTC to xTS. When external element sends packet to internal element, to avoid hindrance of NAT, it first send the packet to xTS, xTS sends the packet to xTC via the tunnel. xTC will do the decapsulation and forward the packet to the real destination. If internal element sends packet to a external element, it can select to send the packet directly to NAT, or according pre-configuration, sends the packet to xTC. If xTC receives the packet, it SHOULD encapsulate the packet and sends it to xTS via the enhanced UDP tunnel. When packet arrives xTS, xTS decapsulates the packet and forwards the packet to real destination. Although the packets can traverse through the NAT via UDP enhanced Wu Expires March 25, 2006 [Page 5] Internet-Draft UDP enhanced tunnel for traversing NAT September 2005 tunnel, we still have a problem that the transport addresses hold in payload of packets is private addresses. If xTS don't handle this situation, and forward it to the real destination, then the destination element can't give a correct response. So besides the tunnel function, xTS general needs ALGs function comprised with it, the ALGs do the translation work of payload. The details of ALGs implementation is out the scope of this document. Wu Expires March 25, 2006 [Page 6] Internet-Draft UDP enhanced tunnel for traversing NAT September 2005 4. UDP enhanced tunnel Header (UTH) Format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Orig-protocol | other-fields | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | other-field(cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | body after original IP header | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The UDP enhanced tunnel header is comprised of three parts: a UDP header, a protocol field and a other-fields. The UDP header is a standard RFC0768 [1] header, where o Source port and Destination port are two end ports of the tunnel, o the IPv4 UDP Checksum can be transmitted as a zero value, or non- zero value, if use non-zero value, it should be calculate according to RFC0768 [1], o receivers should verify the Checksum according to RFC0768 [1]. The Orig-protocol field holds the protocol field of original IP header. The other-fields is not defined in this document, it is reserved for extension. Wu Expires March 25, 2006 [Page 7] Internet-Draft UDP enhanced tunnel for traversing NAT September 2005 5. Encapsulation and Decapsulation Procedures xTc and xTS all do the encapsulation and decapsulation in the tunnel procedures. They encapsulate a general packet and send it to it's peer, and decapsulate the packet encapsulated by its peer. 5.1. xTC behaviors 5.1.1. xTC encapsulate packets xTC will encapsulate the packets it receives if: o the packet is sent to xTC, and the packets belong to a specified protocol it should encapsulate according to it's configuration BEFORE APPLYING UTH -------------------------------- IPv4 |orig IP hdr | | | |(any options)| UDP/TCP | Data | -------------------------------- AFTER APPLYING UTH -------------------------------------- IPv4 |orig IP hdr | UTH | | | |(any options)| Hdr | UDP/TCP | Data | -------------------------------------- If it needs to encapsulate the packet, xTC follows this procedure: o A properly formatted UDP enhanced tunnel header(UTH header) is inserted where shown. o The Source, destination address, Total Length, Protocol, and Header Checksum (for IPv4) fields in the new IP header are edited to match the resulting IP packet. o The destination should be one ip address of xTS. o And cause IP header is modified, a map entry should be recorded by xTC for correct processing the packets sent from xTS. o The resulting packet is forwarded to xTS. Wu Expires March 25, 2006 [Page 8] Internet-Draft UDP enhanced tunnel for traversing NAT September 2005 5.1.2. xTC decapsulate packets When xTC receives encapsulated packet, it follow this procedure: o The UTH header is removed from the packet. o The Source, destination address, Total Length, Protocol, and Header Checksum (for IPv4) fields in the new IP header are edited to match the resulting IP packet, in this procedure, the map entry recorded earlier is used to aid the process. o The resulting packet is forwarded to the real destination. 5.2. xTS behaviors 5.2.1. xTS decapsulate packets xTS will decapsulate the packets it receives if: o the packet is sent to xTS and the port receives the packet is used for UDP enhanced tunnel. To decapsulate the packet, xTS follows this procedure: o The UTH header is removed from the packet. o Do the ALG process if needed. o The source, destination address, Total Length, Protocol, and Header Checksum (for IPv4) fields in the new IP header are edited to match the resulting IP packet. o The resulting packet is forwarded to the real destination. The resulting destination address is one ip address of external element. Cause the real destination address is not carried in the packets xTS received, for correctly process, this address should be known to the xTS previously; this requirement may be acheived via pre-configure mechanism. The IP header is modified in this procedure, so a map entry should be recorded in xTS for correctly process the subsequence packets related to this interaction. 5.2.2. xTS encapsulate packets xTS will encapsulate the packets it receives if: o the packet is related to a previous packet it decapsulated, includes Wu Expires March 25, 2006 [Page 9] Internet-Draft UDP enhanced tunnel for traversing NAT September 2005 * the direct response packet or * other packets send to the transport addresses hold in payload of previous packet, etc. To encapsulate the packet, xTS follow this procedure: o A properly formatted UDP enhanced tunnel header(UTH header) is inserted just as section 4.1.1. o Do the ALG process if needed. o The source, destination address, Total Length, Protocol, and Header Checksum (for IPv4) fields in the new IP header are edited to match the resulting IP packet. To accomplish this, the map entry recorded in previously procedure should be used. o The resulting packet is forwarded to xTC. Wu Expires March 25, 2006 [Page 10] Internet-Draft UDP enhanced tunnel for traversing NAT September 2005 6. The whole procedures description Here, we briefly describe the procedures involved in the whole process between xTC and xTS: o internal element sends packet, which should be sent to external element if don't use UTH, to xTC, o xTC encapsulates a packet it receives in UDP enhanced tunnel and sends it to xTS, o xTS decapsulates the packet it receives, cause the transport addresses in the payload are private ones, o xTS does the ALG function if needed, and forwards the packet to real destination, here, the transport addresses have been translated to public addresses, o the real destination responses/connects to the transport address hold in payload, sure this packet is sent to xTS, cause xTS has do a ALG translation work on payload, o xTS does the ALG function if needed, and hands over the packet to tunnel process, o xTS encapsulates the packet in UDP enhanced tunnel and sends it to xTC via the tunnel, o xTC decapsulates the packet and forwards it to real destination. In the procedures, the response/connection from external to internal will be encapsulated in the same tunnel between xTC and xTS, that is created from xTC to xTS in initial procedure, so there aren't any hindrance to forbid the connection from external to internal of NATs. Wu Expires March 25, 2006 [Page 11] Internet-Draft UDP enhanced tunnel for traversing NAT September 2005 7. NAT Keepalive Procedure Because the map entry created in NAT has a time to live limit, we may need a mechanism to keep the entry alive during the interaction of internal and external element. To keep the map entry alive in NAT, a NAT keep-alive packet may be sent between xTC and xTS, the other- fields of UTH header MAY be used to fulfill this function.. Wu Expires March 25, 2006 [Page 12] Internet-Draft UDP enhanced tunnel for traversing NAT September 2005 8. Security Considerations This document just gives a UDP enhanced tunnel mechanism for traversing NAT. No any authentication procedure is addressed here. But we should note that, in realization, a authentication procedure is RECOMMENDED to be used. The other-fields MAY help to fulfill this function. Wu Expires March 25, 2006 [Page 13] Internet-Draft UDP enhanced tunnel for traversing NAT September 2005 9. IANA Considerations None. Wu Expires March 25, 2006 [Page 14] Internet-Draft UDP enhanced tunnel for traversing NAT September 2005 10. Acknowledgments Thanks Xin. Yao for original thoughts on this mechanism. Thanks advices from Zhong. Luo, Peili. Xu, Jincheng. Li, on this document. Wu Expires March 25, 2006 [Page 15] Internet-Draft UDP enhanced tunnel for traversing NAT September 2005 11. References 11.1. Normative References [1] Postel, J., "User Datagram Protocol", RFC 0768, August 1980. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. 11.2. Informative References [3] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005. Wu Expires March 25, 2006 [Page 16] Internet-Draft UDP enhanced tunnel for traversing NAT September 2005 Author's Address Xiangyang Wu Huawei Technologies Bantian Shenzhen, Longgang 518129 China Phone: +86 755 28780808 Email: wuxy@huawei.com Wu Expires March 25, 2006 [Page 17] Internet-Draft UDP enhanced tunnel for traversing NAT September 2005 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. 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 (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Wu Expires March 25, 2006 [Page 18]