NAT Working Group P. Srisuresh INTERNET-DRAFT Lucent Technologies Category: Informational Matt Holdrege Expire in six months Ascend Communications October 1998 IP Network Address Translator (NAT) Terminology and Considerations Status of this Memo This document is an Internet-Draft. 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 entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Preface The motivation behind this document is to provide clarity to the terms used in conjunction with Network Address Translators. The term "Network Address Translator" means different things in different contexts. The intent of this document is to define the various flavors of NAT and standardize the meaning of terms used. The authors listed are editors for this document and owe the content to contributions from members of the working group. Large chunks of the draft, titled "IP Network Address Translator (NAT)" were extracted almost as is, to form the initial basis for this document. The editors would like to thank the authors Pyda Srisuresh and Kjeld Egevang for the same. The editors would like to thank Praveen Akkiraju for his contributions in describing NAT deployment scenarios. The editors would also like to thank the ADs, Scott Bradner and Vern Paxson, for their detailed review of the document. Srisuresh & Holdrege [Page 1] Internet Draft NAT Terminology and Considerations October 1998 Abstract Network Address Translation is a method by which IP addresses are mapped from one realm to another, providing transparent routing to hosts. Traditionally, NATs are used to connect an isolated routing realm with private unregistered addresses to an external routing realm with globally unique registered addresses. This document attempts to describe the operation of NATs in general and to define the terminology used to identify various flavors of NAT. 1. Introduction and Overview The need for IP Address translation arises when a network's internal IP addresses cannot be used outside the network either for privacy reasons or because they are invalid for use outside the network. Address translation would allow hosts in a private network to transparently access an external network and vice versa. There are a variety of flavors of NAT and terms to match them. This document attempts to define the terminology used and to identify various flavors of NAT. The document also attempts to describe other considerations applicable to NATs in general. Note, however, this document is not intended to describe the operations of individual NAT variations or the applicability of NATs. NATs provide transparent routing solution to end hosts trying to communicate from disparate routing realms. This transparent routing is achieved by modifying end node addresses en-route and maintaining state for these updates so that datagrams pertaining to a session are transparently routed to the right end-node in either realm. This solution works best when the end user identifier (such as host name) is different from the address used to locate the end user. IPsec techniques which are intended to guarantee the end-to-end security of an IP packet cannot be assumed to transit NAT. Techniques such as AH and ESP secure IP header address contents of the end host packets. Yet, NAT's fundamental role is to alter the addresses in the IP header of a packet. NATs cannot by themselves support all applications transparently and often must co-exist with application level gateways(ALGs) for this reason. People looking to deploy NAT based solutions need to determine their application requirements first and assess the NAT extensions (i.e., ALGs) necessary to provide application transparency for their environment. Srisuresh & Holdrege [Page 2] Internet Draft NAT Terminology and Considerations October 1998 2. Terminology and concepts used 2.1. NAT terminology Terms most frequently used in the context of NATs are defined here for reference. 2.1.1. Session flow vs. Packet flow Connection or session flows are different from packet flows. A session flow indicates the direction in which the session was initiated with reference to a network interface. Packet flow is the direction in which the packet has traveled with reference to a network interface. Take for example, an outbound telnet session. The telnet session consists of packet flows in both inbound and outbound directions. Outbound telnet packets carry terminal keystrokes and inbound telnet packets carry screen displays from the telnet server. For purposes of discussion in this document, a session is defined as the set of traffic that is managed as a unit for translation. TCP/UDP sessions are uniquely identified by the tuple of (source IP address, source TCP/UDP port, target IP address, target TCP/UDP port). ICMP query sessions are identified by the tuple of (source IP address, ICMP query ID, target IP address). All other sessions are characterized by the tuple of (source IP address, target IP address, IP protocol). Address translations performed by NAT are session based and would include translation of incoming as well as outgoing packets belonging to that session. Session direction is identified by the direction of the first packet of that session (see sec 2.1.3). 2.1.2. TU ports, Server ports, Client ports For the reminder of this document, we will refer TCP/UDP ports associated with an IP address simply as "TU ports". For most TCP/IP hosts, TU port range 0-1023 is used by servers listening for incoming connections. Clients trying to initiate a connection typically select a TU port in the range of 1024-65535. However, this convention is not universal and not always followed. Some client stations initiate connections using a TU port number in the range of 0-1023, and there are servers listening on TU port numbers in the range of 1024-65535. Srisuresh & Holdrege [Page 3] Internet Draft NAT Terminology and Considerations October 1998 A list of assigned TU port services may be found in [Ref 2]. 2.1.3. Start of session for TCP, UDP and others The first packet of every TCP session tries to establish a session and contains connection startup information. The first packet of a TCP session may be recognized by the presence of SYN bit and absence of ACK bit in the TCP flags. All TCP packets, with the exception of the first packet, must have the ACK bit set. However, there is no deterministic way of recognizing the start of a UDP based session or any non-TCP session. A heuristic approach would be to assume the first packet with hitherto non-existant session parameters (as defined in section 2.1.1) as constituting the start of new session. 2.1.4. End of session for TCP, UDP and others The end of a TCP session is detected when FIN is acknowledged by both halves of the session or when either half sets RST bit in TCP flags field. Within a short period (say, a couple of seconds) after one of the session partners sets RST bit, the session can be safely assumed to have been terminated. However, it is possible to have TCP sessions hung forever. As for non-TCP sessions, there is no deterministic way of identifying session end unless you know the application protocol. Many heuristic approaches are used to terminate sessions. You can make the assumption that TCP sessions that have not been used for say, 24 hours, and non-TCP sessions that have not been used for say, 1 minute, are terminated. Often this assumption works, but sometimes it doesn't. These idle period session timeouts may vary considerably across the board and may be made user configurable. Another way to handle session terminations is to timestamp entries and keep them as long as possible and retire the longest idle session when it becomes necessary. 2.1.5. Routing realm A routing realm is a network domain in which the network addresses are uniquely assigned to entities such that datagrams can be routed to them. Routing protocols used within the network domain are responsible for finding routes to entities given their network addresses. Although NATs may be used with IPv6, this document is limited to describing NATs in a IPv4 environment. 2.1.6. Public/Global/External network Srisuresh & Holdrege [Page 4] Internet Draft NAT Terminology and Considerations October 1998 A Global or Public Network is a routing realm with unique network addresses assigned by Internet Assigned Numbers Authority (IANA) or an equivalent address registry. This network is also referred as External network during NAT discussions. 2.1.7. Private/Local network A private network is a routing realm independent of external routing network. Private network may also be referred alternately as Local Network. Transparent routing between hosts in private realm and external realm is facilitated by a NAT device. RFC 1918 [Ref 1] has recommendations on address space allocation for private networks. Internet Assigned Numbers Authority (IANA) has three blocks of IP address space, namely 10/8, 172.16/12, and 192.168/16 set aside for private internets. In pre-CIDR notation, the first block is nothing but a single class A network number, while the second block is a set of 16 contiguous class B networks, and the third block is a set of 256 contiguous class C networks. An organization that decides to use IP addresses in the address space defined above can do so without coordination with IANA or any other Internet registry such as APNIC, RIPE and ARIN. The address space can thus be used privately by many independent organizations at the same time, with NAT enabled on their border routers. 2.1.8. Application Level gateway (ALG) Not all applications lend themselves easily to translation by NATs; especially those that include IP addresses and TCP/UDP ports in the payload. Application Level Gateways (ALGs) are application specific translation agents that allow an application on a host in one routing realm to connect to its counterpart running on a host in different realm. An ALG may interact with NAT to set up state, use NAT state information, modify application specific payload and perform whatever else is required to get the application running across disparate routing realms. ALGs may not always utilize NAT state information. They may glean application payload and simply notify NAT to add additional state information in some cases. ALGs are similar to Proxies, in that, both ALGs and proxies facilitate Application specific communication between clients and servers. Just as with proxies, ALGs could be transparent as well as non-transparent. Proxies relay client data to servers and vice versa, by using a special protocol to communicate with proxy clients. Unlike Proxies, ALGs Srisuresh & Holdrege [Page 5] Internet Draft NAT Terminology and Considerations October 1998 do not use a special protocol to communicate with application clients and do not require changes to application clients. 3. What is NAT? Network Address Translation is a method by which IP addresses are mapped from one routing realm to another, providing transparent routing to end hosts. There are many variations of address translation that lend themselves to different applications. However, all flavors of NATs should share the following characteristics. a) Transparent Address assignment. b) Transparent routing through address translation. (routing here refers to forwarding packets, and not exchanging routing information) c) ICMP error packet payload translation. Below is a diagram illustrating a scenario in which NAT is enabled on a stub domain border router, connected to the Internet through a regional router made available by a service provider. \ | / . / +---------------+ WAN . +-----------------+/ |Regional Router|----------------------|Stub Router w/NAT|--- +---------------+ . +-----------------+\ . | \ . | LAN . --------------- Stub border Figure 1: A typical NAT operation scenario 3.1. Transparent Address Assignment NAT binds addresses in private network with addresses in global network and vice versa to provide transparent routing for the datagrams traversing between routing realms. The binding in some cases may extend to transport level identifiers (such as TCP/UDP ports). Address binding is done at the start of a session. The following sub-sections describe two types of address assignments. 3.1.1. Static Address assignment In the case of static address assignment, there is one-to-one address mapping for hosts between a private network address and an external network address for the lifetime of NAT operation. Srisuresh & Holdrege [Page 6] Internet Draft NAT Terminology and Considerations October 1998 Static address assignment ensures that NAT does not have to administer address management with session flows. 3.1.2. Dynamic Address assignment In this case, external addresses are assigned to private network hosts or vice versa, dynamically based on usage requirements and session flow detected by NAT. When the last session using an address binding is terminated, NAT would free the binding so that the global address could be recycled for later use. The exact nature of address assignment is specific to individual NAT implementations. 3.2. Transparent routing NATs translate addresses in IP header to contain routable addresses, so that each routing realm can use routing protocols appropriate to the realm to route datagrams. NATs should be careful to not advertise networks in a routing realm, where such an advertisement would be deemed unacceptable. There are three phases to Address translation, as follows. Together these phases result in creation, maintenance and terminations of soft state for sessions passing through NATs. 3.2.1. Address binding: Address binding is the phase in which a local node IP address is associated with an external address or vice versa, for purposes of translation. Address binding is fixed with static address assignments and dynamic at session startup time with dynamic address assignments. Once the binding between two addresses is in place, all subsequent sessions originating from or to this host will use the same binding for session based packet translation. New address bindings are made at the start of a new session, if such an address bind didn't already exist. Once a local address is bound to an external address, all subsequent sessions originating from the same local address or directed to the same local address will use the same binding. Start of each new session will result in the creation of a state to facilitate translation of datagrams pertaining to the session. There can be many simultaneous sessions originating from the same host, based on a single address binding. 3.2.2. Address lookup and translation: Once a state is established for a session, all packets belonging Srisuresh & Holdrege [Page 7] Internet Draft NAT Terminology and Considerations October 1998 to the session will be subject to address lookup (and transport identifier lookup, in some cases) and translation. Address or transport identifier translation for a datagram will result in the datagram forwarding from the origin routing realm to the destination routing realm with network addresses appropriately updated. 3.2.3. Address unbinding: Address unbinding is the phase in which a private address is no longer associated with a global address for purposes of translation. When the last session using an address bind is terminated, it is safe to do the address unbinding. Refer section 2.1 for some heuristic ways to handle session terminations. 3.3. ICMP error packet translation All ICMP error messages (with the exception of Redirect message type) will need to be modified, when passed through NAT. The ICMP error message types needing NAT modification would include Destination-Unreachable, Source-Quench, Time-Exceeded and Parameter-Problem. NAT should not attempt to modify a Redirect message type. Changes to ICMP error message will include changes to the original IP packet (or portions thereof) embedded in the payload of the ICMP error message. In order for NAT to be completely transparent to end hosts, the IP address of the IP header embedded in the payload of the ICMP packet must be modified, the checksum field of the same IP header must correspondingly be modified, and the accompanying transport header. The ICMP header checksum must also be modified to reflect changes made to the IP and transport headers in the payload. Furthermore, the normal IP header must also be modified. 4.0. Various flavors of NAT There are many variations of address translation that lend themselves to different applications. NAT flavors listed in the following sub-sections are by no means exhaustive, but they do capture the significant differences that abound. The following diagram will be used as a base model to illustrate NAT flavors. Host-A, with address Addr-A is located in a private realm, represented by the network N-Pri. N-Pri is isolated from external network through a NAT router. Host-X, with address Addr-X Srisuresh & Holdrege [Page 8] Internet Draft NAT Terminology and Considerations October 1998 is located in external realm, represented by the network N-Ext. NAT router with two interfaces, each attached to one of the realms provides transparent routing between the two realms. The interface to the external realm is assigned an address of Addr-Nx and the interface to private realm is assigned an address of Addr-Np. Further, it may be understood that addresses Addr-A and Addr-Np correspond to N-Pri network and the addresses Addr-X and Addr-Nx correspond to N-Ext network. ________________ ( ) ( External ) +--+ ( Routing Realm )-- |__| ( (N-Ext) ) /____\ (________________) Host-X | (Addr-X) |(Addr-Nx) +--------------+ | | | NAT router | | | +--------------+ |(Addr-Np) | ---------------- ( ) +--+ ( Private ) |__|------( Routing Realm ) /____\ ( (N-pri) ) Host-A (________________) (Addr-A) Figure 2: A base model to illustrate NAT terms. 4.1. Traditional NAT Traditional NAT would allow hosts within a private network to transparently access hosts in the external network. In a traditional NAT, sessions are uni-directional, outbound from the private network. Sessions in the opposite direction may be allowed on an exceptional basis using static address maps for pre-selected hosts. In this setup, network address of hosts in external network are unique and valid in external as well as private networks. However, the addresses of hosts in private network are unique Srisuresh & Holdrege [Page 9] Internet Draft NAT Terminology and Considerations October 1998 within the private network and may not be valid in the external network. In other words, NAT would not advertise private networks to the external realm. But, networks from the external realm may be advertised within the private network. The addresses used within private network must not overlap with the external addresses. Any given address must either be a private address or an external address; not both. A traditional NAT router in figure 2 would allow Host-A to initiate sessions to Host-X, but not the other way around. Also, N-Ext is routable from within N-Pri, whereas N-Pri may not be routable from N-Ext. Traditional NAT is primarily used to connect to the Internet sites which are RFC1918 addressed or sites with addresses that have private enterprise significance. This is also used to avoid address renumbering when changing service providers, even as the addressing within the private network is IANA assigned. There are two variations to traditional NAT, namely Basic NAT and NAPT (Network Address Port Translation). These are discussed in the following sub-sections. 4.1.1. Basic NAT With Basic NAT, a block of external addresses are set aside for translating addresses of hosts in a private domain as they originate sessions to the external domain. For packets outbound from the private network, the source IP address and related fields such as IP, TCP, UDP and ICMP header checksums are translated. For inbound packets, the destination IP address and the checksums as listed above are translated. A Basic NAT router in figure 2 may be configured to translate N-Pri into a block of external addresses, say Addr-i through Addr-n, selected from the external network N-Ext. 4.1.2. Network Address Port Translation (NAPT) With NAPT, a single external address is set aside for translating sessions originated by hosts in a private domain. This is made possible by multiplexing transport level identifiers of multiple private hosts simultaneously into the transport identifiers of a single assigned external address. For this reason, only the applications supported by transport protocols TCP, UDP and ICMP are supported by NAPT. TCP and UDP protocols contain source and destination port numbers. ICMP query based applications are also supported as the queries contain a Query Identifier to correlate Srisuresh & Holdrege [Page 10] Internet Draft NAT Terminology and Considerations October 1998 responses with requests. For packets outbound from the private network, NAPT would translate the source IP address, source transport identifier and related fields such as IP, TCP, UDP and ICMP header checksums. Transport identifier can be one of TCP/UDP port or ICMP query ID. For inbound packets, the destination IP address, destination transport identifier and the IP and transport header checksums are translated. A NAPT router in figure 2 may be configured to translate sessions originated from N-Pri into a single external address, say Addr-i. Very often, the external interface address Addr-Nx of NAPT router is used as the address to map N-Pri to. 4.2. Two-Way NAT or Bi-directional NAT With a Bi-directional NAT, sessions can be initiated from hosts in the public network as well as the private network. Private network addresses are bound to globally unique addresses, statically or dynamically as connections are established in either direction. The name space (i.e., their Fully Qualified Domain Names) between hosts in private and external networks is assumed to be unique. The address space requirements outlined for traditional NATs are applicable here as well. A Bi-directional NAT router in figure 2 would allow Host-A to initiate sessions to Host-X, and Host-X to initiate sessions to Host-A. Just as with traditional NAT, N-Ext is routable from within N-Pri, but N-Pri may not be routable from N-Ext. 4.3. Twice NAT Twice NAT is a variation of NAT in that both the source and destination addresses are modified by NAT as a datagram crosses routing realms. Typically, twice NAT would be deployed on an interface that attempts to "address isolate" private space from the public Internet. In this setup, the network address of hosts in external network are unique in external networks, but not within private network. Likewise, the network address of hosts in private network are unique only within the private network. In other words, the address space used in private network to locate hosts in private and public networks is unrelated to the address space used in public network to locate hosts in private and public networks. Twice NAT would not be allowed to advertise local networks to the external network Srisuresh & Holdrege [Page 11] Internet Draft NAT Terminology and Considerations October 1998 or vice versa. Sessions are allowed to be initiated from hosts in private network to hosts in public network or vice versa. The name space (i.e., Fully Qualified Domain Names) between hosts in private and external networks is assumed to be unique. A Twice NAT router in figure 2 would allow Host-A to initiate sessions to Host-X, and Host-X to initiate sessions to Host-A. However, N-Ext (or a subset of N-Ext) is not routable from within N-Pri, and N-Pri is not routable from N-Ext. Twice NAT is typically used when address space used in a Private network overlaps with addresses used in the Public space. For example, say a private site uses the 200.200.200.0/24 address space which is officially assigned to another site in the public internet. Host_A (200.200.200.1) in Private space seeks to connect to Host_X (200.200.200.100) in Public space. In order to make this connection work, Host_X's address is mapped to a different address for Host_A and vice versa. The twice NAT located at the Private site border may be configured as follows : Private to Public : 200.200.200.0/24 -> 138.76.28.0/24 Public to Private : 200.200.200.0/24 -> 172.16.1.0/24 Datagram flow : Host_A(Private) -> Host_X(Public) a) Within private network DA: 172.16.1.100 SA: 200.200.200.1 b) After twice-NAT translation DA: 200.200.200.100 SA: 138.76.28.1 Datagram flow Host_X (Public) -> Host_A (Private) a) Within Public network DA: 138.76.28.1 SA: 200.200.200.100 b) After twice-NAT translation, in private network SA: 200.200.200.1 DA: 172.16.1.100 Srisuresh & Holdrege [Page 12] Internet Draft NAT Terminology and Considerations October 1998 4.4. Host NAT A "Host NAT Client" is a host in private network that adopts an address in external realm when connecting to hosts in that realm to pursue end-to-end communication. Packets generated by hosts on either end in such a setup would be based on addresses that are end-to-end unique in the external realm and do not require translation by an intermediary process. However, a routing mechanism would be required to deliver the end-to-end packets within private realm. One approach would be to embed these packets within an IP packet such that the outer packet is addressed between Host-NAT-Client's private address and the external peer. In such a case, NAT router in between could provide transparent routing of the outer packet by translating the outer IP header en-route. Another approach would be to embed the end-to-end packet inside a tunnel while traversing in the private network, such that the tunnel is addressed between Host-NAT-Client's private address and a router resident on both realms. As an example, Host-A in figure 2 above, could assume an address Addr-k from the external realm and act as Host-NAT-Client to allow end-to-end sessions between Addr-k and Addr-X. Traversal of end-to-end packets within private realm may be illustrated as follows: First method, using NAT router enroute to translate: =================================================== Host-A NAT router Host-X ------ ----------- ------ , embedding -----------------------------> , embedding ---------------------------> . Srisuresh & Holdrege [Page 13] Internet Draft NAT Terminology and Considerations October 1998 . . , embedding <--------------------------------- , embedding <-------------------------------------- Second method, using a tunnel within private realm: ================================================== Host-A NAT router Host-X ------ ----------- ------ , embedding -----------------------------> -------------------------------> . . . <-------------------------------- , embedding <---------------------------------- Srisuresh & Holdrege [Page 14] Internet Draft NAT Terminology and Considerations October 1998 There may be other approaches to pursue. Common to all, suffices to say, there exists a need for a node that is resident on both private and external realms that can facilitate routing of external realm packets within private realm. Such a node is termed, "Host NAT Server". Host-NAT-Server could also be the same node that assigns external addresses to Host-NAT-Clients. A Host-NAT-Client has the following characteristics. The collective set of operations performed by Host-NAT-Client is termed "Host-NAT". 1. Aware of the realm to which its peer nodes belong. 2. Assumes an address from external realm when communicating with hosts in that realm. Such an address may be assigned statically or obtained dynamically from a node capable of assigning addresses from external realm. Host-NAT-Server could be the node coordinating external realm address assignment. 3. Route packets to external hosts using an approach amenable to Host-NAT-Server. In all cases, Host-NAT-Client will likely need to act as a tunnel end-point, capable of encapsulating end-to-end packets while forwarding and decapsulating in the return path. A Host-NAT-Server may be described as having the following characteristics. 1. May be configured to assign addresses from external realm to Host-NAT-Clients, either statically or dynamically. 2. Must be a router resident on both the private and external routing realms. 3. Must be able to provide a mechanism to route external realm packets within private realm. Of the two approaches described, the first approach requires Host-NAT-Server to be a NAT router providing transparent routing for the outer header. This approach requires the external peer to be a tunnel end-point. With the second approach, a Host-NAT-Server could be any router (including a NAT router) that can be a tunnel end-point with Host-NAT-Clients. It would detunnel end-to-end packets outbound from Host-NAT-Clients and forward to external hosts. On the return path, it would locate Host-NAT-Client tunnel, based on the destination address of the end-to-end packet and encapsulate the packet in a tunnel to forward to Host-NAT-Client. Srisuresh & Holdrege [Page 15] Internet Draft NAT Terminology and Considerations October 1998 Host-NAT-Clients may pursue any of the IPsec techniques, namely transport or tunnel mode Authentication and confidentiality using AH and ESP headers on the embedded packets. Any of the tunneling techniques may be adapted for encapsulation between Host-NAT-Client and Host-NAT-Server or between Host-NAT-Client and external host. For example, IPsec tunnel mode encapsulation is a valid type of encapsulation that ensures IPsec authentication and confidentiality for the embedded end-to-end packets. 4.4.1. Host NAPT Host Network Address Port Translation (Host NAPT) is a variation of Host-NAT in that multiple private hosts use a single external address, multiplexing on transport IDentifiers (i.e., TCP/UDP port numbers and ICMP Query IDs). "Host NAPT Client" may be defined similar to Host-NAT-Client with the variation that Host-NAPT-Client assumes a tuple of (external address, transport Identifier) when connecting to hosts in external realm to pursue end-to-end communication. As such, communication with external nodes for a Host-NAPT-Client is limited to TCP, UDP and ICMP sessions. "Host-NAPT-Server" is similar to Host-NAT-Server in that it facilitates routing of the end-to-end packets inside private realm. Typically, a Host-NAPT-Server would also be the one to assign transport tuples to Host-NAPT-Clients. A NAPT router enroute could serve as Host-NAPT-Server, when the outer encapsulation is TCP/UDP based (such as PPTP, L2TP tunneling) and is addressed between the Host-NAPT-Client and external peer. This approach requires the external peer to be the end-point of TCP/UDP based tunnel. Using this approach, Host-NAPT-Clients may pursue any of the IPsec techniques, namely transport or tunnel mode authentication and confidentiality using AH and ESP headers on the embedded packets. Note however, IPsec tunnel mode is not a valid type of encapsulation, as a NAPT router cannot provide routing transparency to AH and ESP protocols. Alternately, packets may be tunneled between Host-NAPT-Client and Host-NAPT-Server such that host-NAPT-Server would detunnel packets outbound from Host-NAPT-Clients and forward to external hosts. On the return path, Host-NAPT-Server would locate Host-NAPT-Client tunnel, based on the tuple of (destination address, transport Identifier) and encapsulate the original packet within a tunnel to forward to Host-NAPT-Client. With this approach, there is no limitation on the tunneling technique employed between Srisuresh & Holdrege [Page 16] Internet Draft NAT Terminology and Considerations October 1998 Host-NAPT-Client and Host-NAPT-Server. However, there are limitations to applying IPsec based security on end-to-end packets. Transport mode based authentication and integrity may be attained. But, confidentiality cannot be permitted because Host-NAPT-Server must be able to examine the destination transport Identifier in order to identify the Host-NAPT-tunnel to forward inbound packets to. For this reason, only the transport mode TCP, UDP and ICMP packets protected by AH and ESP-authentication can traverse a Host-NAPT-Server using this approach. As an example, say Host-A in figure 2 above, obtains a tuple of (Addr-Nx, TCP port T-Nx) from NAPT router to act as Host-NAPT-Client to initiate end-to-end TCP sessions with Host-X. Traversal of end-to-end packets within private realm may be illustrated as follows. In the first method, outer layer of the outgoing packet from Host-A uses (private address Addr-A, source port T-Na) as source tuple to communicate with Host-X. NAPT router enroute translates this tuple into (Addr-Nx, Port T-Nxa). This translation is independent of Host-NAPT-Client tuple parameters used in the embedded packet. First method, using NAPT router enroute to translate: ==================================================== Host-A NAPT router Host-X ------ ----------- ------ , embedding -----------------------------> , embedding ---------------------------------------> . . . , embedding <---------------------------------- , embedding <----------------------------------- Second method, using a tunnel within private realm: ================================================== Host-A NAPT router Host-X ------ ----------- ------ , embedding -----------------------------> --------------------------------> . . . <---------------------------------- , embedding <---------------------------------- 4.5. Multihomed NAT There are limitations to using NAT. For example, requests and responses pertaining to a session must be routed via the same NAT router, as a NAT router maintains state information for sessions established through it. For this reason, it is often suggested that NATs be operated on a border router unique to a stub domain, where all IP packets are either originated from the domain or destined to the domain. However, such a configuration would turn a NAT box into a single point of failure. In order for a private network to ensure that connectivity with external networks is retained even as one of the NAT links fail, it is often desirable to multihome the private network to same or multiple service providers with multiple connections from the private domain, be it from same or different NAT boxes. For example, a private network could have links to two different providers and the sessions from private hosts could flow through the NAT router with the best metric for a destination. When one of NATs fail, the other could route traffic for all connections. Multiple NAT boxes or multiple links on the same NAT box, sharing the same NAT configuration can provide fail-safe backup for each other. In such a case, it would be desirable for backup NATs to exchange state information so that a backup NAT can take on session load transparently when the primary NAT fails. NAT backup becomes simpler, when configuration is based on static maps. 5.0. Private Networks and Tunnels Let us consider the case where your private network is connected to the external world via tunnels. In such a case, tunnel encapsulated traffic may or may not contain translated packets depending upon the characteristics of routing realms a tunnel is bridging. The following subsections discuss two scenarios where tunnels are used (a) in conjunction with Address translation, and (b) without translation. Srisuresh & Holdrege [Page 19] Internet Draft NAT Terminology and Considerations October 1998 5.1. Tunneling translated packets All variations of address translations discussed in the previous section can be applicable to direct connected links as well as tunnels and virtual private networks (VPNs). For example, a private network connected to a business partner through a VPN could employ traditional NAT to communicate with the partner. Likewise, it is possible to employ twice NAT, if the partner's address space overlapped with the private network. There could be a NAT device on one end of the tunnel or on both ends of the tunnel. In all cases, traffic across the VPN can be encrypted for security purposes. Security here refers to security for traffic across VPNs alone. End-to-end security requires trusting NATs within private network. 5.2. Backbone partitioned private Networks There are many instances where a private network (such as a corporate network) is spread over different locations and use public backbone for communications between those locations. In such cases, it is not desirable to do address translation, both because large numbers of hosts may want to communicate across the backbone, thus requiring large address tables, and because there will be more applications that depend on configured addresses, as opposed to going to a name server. We call such a private network a backbone-partitioned private network. Backbone-partitioned stubs should behave as though they were a non-partitioned stub. That is, the routers in all partitions should maintain routes to the local address spaces of all partitions. Of course, the (public) backbones do not maintain routes to any local addresses. Therefore, the border routers must tunnel (using VPNs) through the backbones using encapsulation. To do this, each NAT box will set aside a global address for tunneling. When a NAT box x in stub partition X wishes to deliver a packet to stub partition Y, it will encapsulate the packet in an IP header with destination address set to the global address of NAT box y that has been reserved for encapsulation. When NAT box y receives a packet with that destination address, it decapsulates the IP header and routes the packet internally. 6.0. NAT operational characteristics Srisuresh & Holdrege [Page 20] Internet Draft NAT Terminology and Considerations October 1998 NATs are application independent in that the translations are limited to IP/TCP/UDP/ICMP headers and ICMP error messages only. NATs do not change the payload of the packets, as payloads tend to be application specific. Due to their application independence, NATs are not considered a hindrance to applications pursuing end-to-end transport and application layer security. Applications that include IP addresses in payload are an exception to this. However, end-to-end IP network level security assured by current IPsec techniques is not possible for the most part, as NATs modify the IP header contents in transit. As an exception, IPsec tunnel mode encryption and authentication are permissible so long as the embedded packet contents are unaffected by the outer IP header translation. Refer section 4.4 for details on the use of IPsec with Host-NAT. IPsec assumes the traditional IP address as the globally unique ID and requires IP addresses to be unique. Yet, NATs fundamentally operate on the premise of modifying the IP addresses. This strongly restricts the use of IPsec and any other protocol which includes an IP address in an end-to-end security association. NATs also break the same fundamental assumption by public key distribution infrastructures such as secure DNS and X.509 certificates with signed public keys. Integrity of a Security Association (SA), identified by the tuple of (Destination Address, SPI, secure protocol) may be jeopardized by the manipulation of addresses by NAT. Tampering of addresses along the way by NAT could break the authenticity of signed data and confidentiality of encrypted data. For example, altering the IP header would most certainly break the authentication assured by the AH header. It would also break the authentication and confidentiality assured by ESP header for the TCP/UDP packets. However, authentication and confidentiality may be ascertained for non-TCP/UDP packets using ESP header, so long as the payload is routing realm neutral. It may be of interest to note that IKE (Session key negotiation protocol) is a UDP based session layer protocol and is not protected by network based IPsec security. Only a portion of the individual payloads within IKE are protected. As a result, IKE sessions are permissible across NAT, so long as IKE payload does not contain addresses and/or transport IDs specific to a realm and not the other. One of the most popular internet applications "FTP" would not work with the definition of NAT as described. The following sub-section is devoted to describing how FTP is supported on NAT devices. FTP ALG is an integral part of most NAT implementations. Some vendors Srisuresh & Holdrege [Page 21] Internet Draft NAT Terminology and Considerations October 1998 may choose to include additional ALGs to custom support other applications on the NAT device. 6.1. FTP support "PORT" command and "PASV" response in FTP control session payload identify the IP address and TCP port that must be used for the data session it supports. The arguments to the PORT command and PASV response are an IP address and a TCP port in ASCII. An FTP ALG is required to monitor and update the FTP control session payload so that information contained in the payload is relevant to end nodes. The ALG must also update NAT with appropriate data session tuples and session orientation so that NAT could set up state information for the FTP data sessions. Because the address and TCP port are encoded in ASCII, this may result in a change in the size of packet. For instance, 10,18,177,42,64,87 is 18 ASCII characters, whereas 193,45,228,137,64,87 is 20 ASCII characters. If the new size is same as the previous, only the TCP checksum needs adjustment as a result of change of data. If the new size is less than or greater than the previous, TCP sequence numbers must also be changed to reflect the change in length of FTP control data portion. A special table may be used by the ALG to correct the TCP sequence and acknowledge numbers. 7.0. NAT limitations 7.1. Applications with IP-address Content Not All applications lend themselves easily to address translation by NATs. Especially, the applications that carry IP address (and TU port, in case of NAPT) inside the payload. Application Level Gateways, or ALGs must be used to perform translations on packets pertaining to such applications. ALGs may optionally utilize address (and TU port) assignments made by NAT and perform translations specific to the application. The combination of NATs and ALGs will not provide end-to-end security assured by IPsec. However, tunnel mode IPsec can be accomplished with NAT serving as tunnel end point. SNMP is one such application with address content in payload. NAT routers would not translate IP addresses within SNMP payloads. It is not uncommon for an SNMP specific ALG to reside on a NAT router to perform SNMP MIB translations proprietary to the private network. 7.2. Applications with inter-dependent control and data sessions Srisuresh & Holdrege [Page 22] Internet Draft NAT Terminology and Considerations October 1998 NATs operate on the assumption that each session is independent. Session characteristics like session orientation, source and destination IP addresses, session protocol, and source and destination transport level identifiers are determined independently at the start of each new session. However, there are applications such as H.323 that use one or more control sessions to set the characteristics of the follow-on sessions in their control session payload. Such applications require use of application specific ALGs that can interpret and translate the payload, if necessary. Payload interpretation would help NAT be prepared for the follow-on data sessions. 7.3. Debugging Considerations NAT increases the probability of mis-addressing. For example, same local address may be bound to different global address at different times and vice versa. As a result, any traffic flow study based purely on global addresses and TU ports could be confused and might misinterpret the results. If a host is abusing the Internet in some way (such as trying to attack another machine or even sending large amounts of junk mail or something) it is more difficult to pinpoint the source of the trouble because the IP address of the host is hidden in a NAT router. 7.4. Translation of fragmented FTP control packets Translation of fragmented FTP control packets is tricky when the packets contain "PORT" command or response to "PASV" command. Clearly, this is a pathological case. One option would be to drop the fragments and send an ICMP error message to packet originator. Alternately, NAT router could attempt to assemble fragments first and then translate prior to forwarding. Yet another case would be when each character of packets containing "PORT" command or response to "PASV" is sent in a separate datagram, unfragmented. In this case, NAT would simply have to let the packets through, without translating the TCP payload. 7.5. Compute intensive NAT is compute intensive even with the help of a clever checksum adjustment algorithm, as each data packet is subject to NAT lookup and modifications. As a result, router forwarding throughput could be slowed considerably. However, so long as the Srisuresh & Holdrege [Page 23] Internet Draft NAT Terminology and Considerations October 1998 processing capacity of the NAT device exceeds line processing rate, this should not be a problem. 8.0. Security Considerations Many people view traditional NAT as a one-way (session) traffic filter, restricting sessions from external hosts into their machines. In addition, when address assignment in NAT is done dynamically, that makes it harder for an attacker to point to any specific host in the NAT domain. NATs may be used in conjunction with firewalls to filter unwanted traffic. If NATs and ALGs are not in a trusted boundary, that is a major security problem, as ALGs could snoop end user traffic payload. Session level payload could be encrypted end to end, so long as the payload does not contain IP addresses and/or transport identifiers that are valid in only one of the realms. With the exception of Host-NAT, end-to-end IP network level security assured by current IPsec techniques is not attainable with NATs in between. One of the ends must be a NAT box. Refer section 6.0 for a discussion on why end-to-end IPsec security cannot be assured with NAT devices along the route. The combination of NATs, ALGs and firewalls will provide a transparent working environment for a private networking domain. With the exception of Host-NAT, end-to-end network security assured by IPsec cannot be attained for end-hosts within the private network (Refer section 4.4 for Host-NAT operation). In all other cases, if you want to use end-to-end IPsec, there cannot be a NAT device in the path. If we make the assumption that NATs are part of a trusted boundary, tunnel mode IPsec can be accomplished with NAT (or a combination of NAT, ALGs and firewall) serving as tunnel end point. NATs, when combined with ALGs, can ensure that the datagrams injected into Internet have no private addresses in headers or payload. Applications that do not meet these requirements may be dropped using firewall filters. For this reason, it is not uncommon to find that NATs, ALGs and firewalls co-exist to provide security at the borders of a private network. NAT gateways can be used as tunnel end points to provide secure VPN transport of packet data across an external network domain. Below are some additional security considerations associated with NAT routers. 1. UDP sessions are inherently unsafe. Responses to a datagram Srisuresh & Holdrege [Page 24] Internet Draft NAT Terminology and Considerations October 1998 could come from an address different from the target address used by sender ([Ref 4]). NAT implementations that do not track datagrams on a per-session basis but lump states of multiple UDP sessions into a single state could compromise the security even further. 2. Multicast sessions (UDP based) are another source for security weaknesses. Say, a host on private network initiated a multicast session. Datagram sent by the private host could trigger responses in the reverse direction from multiple external hosts. NAT implementations that use a single state to track the multicast responses in a multicast session could potentially be the target of security attacks. This multicast specific security concern, however, is not unique to NAT implementations, and exists across all hosts supporting multicast applications. 3. NATs can be a target for attacks. Since NATs are Internet hosts they can be the target of a number of different attacks, such as SYN flood and ping flood attacks. NATs should employ the same sort of protection techniques as Internet-based servers do. REFERENCES [1] Rekhter, Y., Moskowitz, B., Karrenberg, D., G. de Groot, and, Lear, E. "Address Allocation for Private Internets", RFC 1918 [2] J. Reynolds and J. Postel, "Assigned Numbers", RFC 1700 [3] R. Braden, "Requirements for Internet Hosts -- Communication Layers", RFC 1122 [4] R. Braden, "Requirements for Internet Hosts -- Application and Support", RFC 1123 [5] F. Baker, "Requirements for IP Version 4 Routers", RFC 1812 [6] J. Postel, J. Reynolds, "FILE TRANSFER PROTOCOL(FTP)", RFC 959 [7] "TRANSMISSION CONTROL PROTOCOL (TCP) SPECIFICATION", RFC 793 [8] J. Postel, "INTERNET CONTROL MESSAGE PROTOCOL SPECIFICATION", RFC 792 Srisuresh & Holdrege [Page 25] Internet Draft NAT Terminology and Considerations October 1998 [9] J. Postel, "User Datagram Protocol (UDP)", RFC 768 [10] J. Mogul, J. Postel, "Internet Standard Subnetting Procedure", RFC 950 [11] Brian carpenter, Jon Crowcroft, Yakov Rekhter, "IPv4 Address Behavior Today", RFC 2101 [12] S. Kent, R. Atkinson, "Security Architecture for the Internet Protocol", - Work in progress. [13] S. Kent, R. Atkinson, "IP Encapsulating Security Payload (ESP)", - Work in progress. [14] S. Kent, R. Atkinson, "IP Authentication Header", - Work in progress. [15] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", - Work in progress. [16] D. Piper, "The Internet IP Security Domain of Interpretation for ISAKMP", - Work in progress. Authors' Addresses Pyda Srisuresh Lucent technologies 4464 Willow Road Pleasanton, CA 94588-8519 U.S.A. Voice: (925) 737-2153 Fax: (925) 737-2110 EMail: suresh@ra.lucent.com Matt Holdrege Ascend Communications, Inc. One Ascend Plaza 1701 Harbor Bay Parkway Alameda, CA 94502 Voice: (510) 769-6001 Fax: (510) 814-2300 EMail: matt@ascend.com Srisuresh & Holdrege [Page 26]