NAT Working Group D. Senie INTERNET-DRAFT Amaranth Networks Inc. Category: Informational March 2001 Expires in six months NAT Friendly Application Design Guidelines draft-ietf-nat-app-guide-05.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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." To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (1999-2001). All Rights Reserved. Preface: While many common Internet applications will operate cleanly in the presence of Network Address Translators, others suffer from a variety of problems when crossing these devices. This document discusses those things that application designers might wish to consider when designing new protocols. Guidelines are presented herein to help ensure new protocols and applications will, to the extent possible, be compatible with NAT. 1. Introduction Other documents that describe Network Address Translation (NAT) discuss the Terminology and Considerations [RFC2663] and Protocol Issues [RFC3022], [RFC3027] or discuss the perceived implications of NAT [RFC2993]. All of those relate to various issues with the NAT mechanism and its effects on protocols that already exist. It is the focus of this document to instruct authors of new protocols what to think about when designing new protocols such that special handling is not required at NAT gateway points. Senie [Page 1] Internet-Draft NAT Friendly Application Design February 2001 When a protocol is unable to pass cleanly through a NAT, the use of an Application Level Gateway (ALG) can still permit operation of the protocol. Depending on the encoding used in a protocol, the ALG may be difficult or easy to construct. While adjunct to NAT, the formulation of protocols that cannot directly operate through NAT should be considered such that the ALG design may be simple and automated. ALGs typically operate inside small routers along with the NAT component. Ideally, the ALG should be simple and not require excessive computation or state storage. The same issues in application design that create issues for NAT (and thus can require ALG support) are also issues for firewalls. An application designer would do well to keep this in mind, as any protocol that does require special handling by NAT or firewall products will be more difficult to deploy than those that require no special handling. 2. Discussion Network Address Translation presents a challenge to some existing applications. It should be possible for developers of new applications to avoid problems if they understand the issues involved. This document aims to provide the application designer with information on what to do, and what to avoid, when building applications. The proliferation of NAT, especially in homes and small offices cannot be dismissed. The emerging technologies for providing high bandwidth to these types of locations often allow only a single IP address per location. As such NAT is a clear choice for connecting more than a single system per location. Clearly the most common problem associated with NAT implementations is the passing of addressing data between stations. Where possible, applications should find alternatives to such schemes. Studying a few existing protocols will serve to highlight the different approaches possible. Two common forms of Traditional NAT exist. With Basic NAT, only the IP addresses of packets are altered by the NAT implementation. Many applications will operate correctly with Basic NAT. The other common form is Network Address Port Translation. With NAPT, both the IP addresses and the source and destination ports (for TCP and UDP) are potentially altered by the gateway. As such, applications passing only port number information will work with Basic NAT, but not with NAPT. Application designers should ensure compatibility with NAPT, as this Senie [Page 2] Internet-Draft NAT Friendly Application Design February 2001 form of NAT is the most widely deployed. This is also the form of NAT that will likely see the greatest penetration in homes and small offices. 3. Recommendations and Examples When possible, applications designers should strive to avoid the necessity of ALG functions in NAT implementations. Since the same issues apply to firewalls, application designers have added incentive to consider these recommendations. Applications that work in such fashion as to not need ALG support will be much easier to deploy, and have the greatest chance of operation on a broad spectrum of NAT implementations. Each of the areas called out below are examples of issues to consider when building an application. This list is likely not comprehensive, but does cover a number of important issues and considerations. 3.1 Issues and Recommendations affecting all types of Network Address Translators 3.1.1. Peer-to-Peer Applications Limitations Peer to peer applications are problematic in a NAT world. Client- server applications are more generally workable. Peer-to-peer applications rely on each peer being reachable as a server for the other to connect to. With NAPT, there are likely many machines behind one address. With other types of NAT such as one-to-one mappings, there is a greater chance of making such applications work. Some implementations of NAT can be made to function for UDP-based peer-to-peer applications such as interactive gaming. This capability is dependent on the methodology used to implement the UDP sessions in the NAT device. If the NAT device tracks the tuple (private address, private port, public port) then it is possible for an outbound UDP packet to establish a channel by which incoming traffic can flow from a source other than that originally contacted by the system. NAT devices which track source and destination IP addresses, in addition to port numbers, will not permit third-party packets. The latter implementation is generally more secure. NAT device implementations could be constructed to have a switch within them, permitting the consumer the ability to select whether they want greater security, or greater ability to run peer-to-peer Senie [Page 3] Internet-Draft NAT Friendly Application Design February 2001 applications. 3.1.2. Applications Requiring End-to-End IPSec Will Fail Use of IPSec for end-to-end security will not function in the presence of a NAT implementation. Application designers may want to explore the use of TLS as a mechanism that will traverse NAT cleanly. See [RFC2709] for additional discussion on combining NAT with Tunnel-mode IPSec security on the same device. Some vendors have implemented a pass-through capabilty which permits IPSec tunnel mode from a client in the private realm to communicate with an endpoint in the public realm. 3.1.3. Use DNS Names, Not IP Addresses In Payload Applications should take care to use fully qualified domain names, rather than IP addresses when referring to IP endpoints. When endpoints are across a NAT gateway, private addresses must not be allowed to leak to the other endpoint. An example of where this can happen today is with the HTTP and HTML protocols. It is possible for web pages to be specified with numeric IP addresses, rather than with names, for example http://192.168.1.10/index.html could be used as a URL, but would likely create a problem if this address is on a server located behind a NAT gateway. Users outside the gateway would not be able to reach the address 192.168.1.10, and so would not see the page. Further exacerbating the problem is the possibility of duplicate addresses between realms. If a server offers a link with a private address space IP address embedded within it, such as 192.168.1.10, the page referenced may resolve to a system on the local network the browser is on, but would be a completely different server. The resulting confusion to end-users would be significant. Sessions involving multiple NAT implementations would be exceptionally vulnerable to address reuse issues of this sort. 3.1.4. Multicast Considerations Not all NAT devices implement multicast routing protocols. Application designers should verify whether the devices in their networks are able to process multicast traffic if their applications rely on that capability. 3.1.5. Retention Of Address Mapping With the exception of statically configured NAT bindings, applications should not assume address mapping will be maintained Senie [Page 4] Internet-Draft NAT Friendly Application Design February 2001 from one session to another. An example of this is RSVP, which forms one connection to reserve the resources, then the actual session for which resources were reserved is started. The sessions do not necessarily overlap. There is no guarantee that the NAT implementation will keep the binding association. As such, applications that rely on subsequent sessions being mapped to the same destination system may not function without an ALG. 3.2 Recommendations for NAPT As many of the issues specifically address NAPT issues, this section will group these issues. NAPT is the most common form of NAT in actual deployment in routers, especially in smaller offices and home offices. 3.2.1 Realm Specific IP Addresses Avoid the use of IP address and port number information within the payload of packets. While in some cases ALGs will permit such protocols to function, this presupposes every NAT device can be updated in a timely fashion to support a new protocol. Since this is unlikely application writers are urged to avoid addressing information in payloads all together. 3.2.2 Avoid Session Bundles Independent sessions, such as used by HTTP, are preferred to protocols that attempt to manage a bundle of related sessions, such as FTP. In the FTP protocol, port information is passed over one TCP connection and is used to construct a second TCP connection for passing the actual data. Use of a separate connection to transfer the file data makes determination of file end quite simple, however other schemes could be envisioned which could use a single connection. The HTTP protocol, for example, uses a header and content length approach to passing data. In this model, all data is transferred over the single TCP connection, with the header portion indicating the length of the data to follow. HTTP has evolved to allow multiple objects to be passed on a single connection (thereby cutting the connection establishment overhead). Clearly a new file transfer function could be built that would perform most of the functions of FTP without the need for additional TCP connections. The goal is to keep to single connections where possible. This keeps us from needing to pass addressing information of any sort Senie [Page 5] Internet-Draft NAT Friendly Application Design February 2001 across the network. 3.2.3. Session Bundles Originate From Same End Origination of connections is an important consideration. Where possible, the client should originate all connections. The FTP protocol is the most obvious example, where by default the server opens the data connection to a port on the client (the client having specified the port number via a PORT command over the control TCP session). As pointed out in [RFC1579], the use of the passive open option in FTP (PASV) remedies this situation as the client is responsible for opening the connection in this case. With client-opened connections, the standard functions of NAPT will process the request as it would any other simple TCP connection, and so an ALG is not required. In cases where session bundles are unavoidable, each session in the bundle should originate from the same end station. 3.2.4. TCP preferred over UDP NAPT gateways must track which sessions are alive, and flush old sessions. TCP has clear advantages in this area, since there are specific beginning and end of session indicators in the packets (SYN and FIN packets). While UDP works for some types of applications with NAT, there can be issues when that data is infrequent. Since there is no clean way to know when an end station has finished using a UDP session, NAT implementations use timeouts to guess when a UDP session completes. If an application doesn't send data for a long period of time, the NAT translation may time out. Protocols other than TCP and UDP are workable with Traditional NAT in many cases, provided they are not carrying addressing information. For NAPT implementations Use of any protocols other than TCP and UDP should be discouraged. It's important to note that NAT deployments are based on the assumption of a client-server application model, with the clients in the private realm. 3.2.5. IP Fragmentation Applications should attempt to avoid fragmentation when packets pass over NAPT devices. While not always practical or possible, there are failures that can occur with NAPT. Specifically, if two Senie [Page 6] Internet-Draft NAT Friendly Application Design February 2001 stations in the private realm pick matching fragmentation identifiers, and talk to the same remote host, it will be impossible to determine which fragments belong to which session. Ideally, applications should limit packet size, use Path MTU Discovery or both. Some implementations of NAT may implement fragment reassembly prior to Forwarding, however many do not. Application designers are advised to examine the devices they plan to deploy, or to design assuming the devices do not Reassemble fragments. 3.3 Issues and recommendations for Basic NAT If only Basic NAT implementations are involved, not NAPT, then many of the issues above do not apply. This form of NAT is not a panacea. In this case many of the issues still remain, and many protocols will not function correctly without assistance. 3.3.1. Use IP and TCP/UDP Headers Alone Applications that use only the information in the IP and TCP or UDP headers for communication (in other words, do not pass any additional addressing information in the payload of the packets), are clearly easier to support in a NAT environment. Where possible, applications designers should try to limit themselves in this area. The X windowing system, for example, uses fixed port numbers to address X servers. With X, the server (display) is addressed via ports 6000 through 6000 + n. These map to hostname:0 through hostname:n server displays. Since only the address and port are used, the NAT administrator could map these ports to one or more private addresses, yielding a functioning solution. The X example, in the case of NAPT, requires configuration of the NAT implementation. This results in the ability for no more than one station inside the NAT gateway to use such a protocol. This approach to the problem is thus OK for NAT but not recommended for NAPT environments. 3.3.2. Avoid Addressing In Payload As with NAPT, transporting IP address and/or port number information in the payload is likely to cause trouble. The IP address and/or port information valid in the realm on one side of a NAT may well be invalid or even refer to different resources on the other side of a NAT gateway. Senie [Page 7] Internet-Draft NAT Friendly Application Design February 2001 3.4 Bi-directional NAT Bi-directional NAT makes use of DNS mapping of names to point sessions originating outside the private realm to servers in the private realm. Through use of a DNS-ALG [RFC2694], lookups are performed to find the proper host and packets are sent to that host. Requirements for applications are the same as for Basic NAT. Addresses are mapped one-to-one to servers. Unlike Traditional NAT devices, Bi-directional NAT devices (in conjunction with DNS-ALG) are amenable to peer-to-peer applications. 3.5 Twice NAT Twice NAT is address translation where both source and destination IP addresses are modified due to addressing conflicts between two private realms. Two bi-directional NAT boxes connected together would essentially perform the same task, though a common address space that is not otherwise used by either private realm would be required. Requirements for applications to work in the Twice NAT environment are the same as for Basic NAT. Addresses are mapped one to one. 3.6 Multi-homed NAT Multi-homed NAT is the use of multiple NAT implementations to provide redundancy. The multiple implementations share configuration information so that sessions might continue in the event of a fail-over. Unless the multiple implementations share the same external addresses, sessions will have to restart regardless. Requirements for multi-homed NAT are the same as for Basic NAT or NAPT, depending on how the multi-homed NAT is implemented and configured. 3.7 Realm Specific IP (RSIP) Realm Specific IP is described in [RFC2663] and defined in [RSIP] and related documents. Clients within a private realm using RSIP are aware of the delineation between private and public, and access a server to allocate address (and optionally port) information for use in conversing with hosts in the public realm. By doing this, clients create packets that need not be altered by the RSIP server on their way to the remote host. This technique can permit IPSec to function, and potentially makes any Senie [Page 8] Internet-Draft NAT Friendly Application Design February 2001 application function as if there were no special processing involved at all. 3.8 Performance Implications of Address Translation Implementations Resource utilization on the NAT gateway should be considered. An application that opens and closes many TCP connections, for example, will use up more resources on the NAT router than an application performing all transfers over a single TCP connection. HTTP 1.0 opened a connection for each object on a web page, whereas HTTP 1.1 permits the TCP session to be held open for additional objects that may need to be transferred. Clearly the latter imposes a lower overhead on the NAT gateway, as it is only maintaining state on a single connection instead of multiple connections. New session establishment will typically remain a software function even in implementations where the packet-by-packet translation work is handled by hardware forwarding engines. While high-performance NAT boxes may be built, protocols that open many sessions instead of multiplexing will be slower than those that do not. Applications with different types of data, such as interactive conferencing, require separate streams for the different types of data. In such cases the protocol needs of each stream must be optimized. While the goal of multiplexing over a single session is preferred, clearly there are cases where this is impractical. The latency of NAT translation overhead is implementation dependent. On a per-packet basis, for established sessions only the source or destination IP address is replaced, the source or destination port (for NAPT) and the checksums for IP, and TCP or UDP are recalculated. The functionality can be efficiently implemented in hardware or software. 4. Security Considerations Network Address Translators have implications for IPSec, as noted above. When application developers are considering whether their applications function with NAT implementations, care should be given to selection of security methodology. Transport Layer Security (TLS) [RFC2246] operates across translation boundaries. End-to-end IPSec will prove problematic in many cases. 5. References Senie [Page 9] Internet-Draft NAT Friendly Application Design February 2001 [RFC1579] S. Bellovin, "Firewall Friendly FTP," RFC 1579, February 1994. [RFC2246] T. Dierks, C. Allen, "The TLS Protocol Version 1.0," RFC 2246, January 1999. [RFC2993] T. Hain, "Architectural Implications of NAT," RFC 2993, November 2000. [RFC3027] M. Holdrege, P. Srisuresh, "Protocol Complications with the IP Network Address Translator (NAT)," RFC 3027, January 2001. [RFC2663] P. Srisuresh, M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations," RFC 2663, August 1999. [RFC2709] P. Srisuresh, "Security Model with Tunnel-mode IPsec for NAT Domains," RFC 2709, October 1999. [RSIP] M. Borella, et. al., "Realm Specific IP: Framework," - Work In Progress. [RFC3022] P. Srisuresh, K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)," RFC 3022, January 2001. [RFC2694] P. Srisuresh, et. al., "DNS extensions to Network Address Translators (DNS_ALG)," RFC 2694, September 1999. 6. Acknowledgements I'd like to thank Pyda Srisuresh for his invaluable input and feedback. 7. Author's Address Daniel Senie Amaranth Networks Inc. 324 Still River Road Bolton, MA 01740 Phone: (978) 779-6813 EMail: dts@senie.com Senie [Page 10]