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 NAT devices   within private network.6.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.  Note, there is no address translation   in the process; merely transfer of private network packets over an   external network tunnel backbone.Srisuresh & Holdrege         Informational                     [Page 22]RFC 2663           NAT Terminology and Considerations        August 19997.0. NAT operational characteristics   NAT devices are application unaware in that the translations are   limited to IP/TCP/UDP/ICMP headers and ICMP error messages only.  NAT   devices do not change the payload of the packets, as payloads tend to   be application specific.   NAT devices (without the inclusion of ALGs) do not examine or modify   transport payload. For this reason, NAT devices are transparent to   applications in many cases. There are two areas, however, where NAT   devices often cause difficulties: 1) when an application payload   includes an IP address, and 2) when end-to-end security is needed.   Note, this is not a comprehensive list.   Application layer security techniques that do not make use of or   depend on IP addresses will work correctly in the presence of NAT   (e.g., TLS,  SSL and ssh). In contrast, transport layer techniques   such as IPSec transport mode or the TCP MD5 Signature Option RFC 2385   [Ref 17] do not.   In IPSec transport mode, both AH and ESP have an integrity check   covering the entire payload. When the payload is TCP or UDP, the   TCP/UDP checksum is covered by the integrity check. When a NAT device   modifies an address the checksum is no longer valid with respect to   the new address. Normally, NAT also updates the checksum, but this is   ineffective when AH and ESP are used.  Consequently, receivers will   discard a packet either because it fails the IPSec integrity check   (if the NAT device updates the checksum), or because the checksum is   invalid (if the NAT device leaves the checksum unmodified).   Note that IPsec tunnel mode ESP is permissible so long as the   embedded packet contents are unaffected by the outer IP header   translation. Although this technique does not work in traditional NAT   deployments (i.e., where hosts are unaware that NATs are present),   the technique is applicable to Realm-Specific IP as described in   Section 5.0.   Note also that end-to-end ESP based transport mode authentication and   confidentiality are permissible for packets such as ICMP, whose IP   payload content is unaffected by the outer IP header translation.   NAT devices also break fundamental assumptions by public key   distribution infrastructures such as Secure DNS RFC 2535 [Ref 18] and   X.509 certificates with signed public keys. In the case of SecureSrisuresh & Holdrege         Informational                     [Page 23]RFC 2663           NAT Terminology and Considerations        August 1999   DNS, each DNS RRset is signed with a key from within the zone.   Moreover, the authenticity of a specific key is verified by following   a chain of trust that goes all the way to the DNS root.  When a DNS-   ALG modifies addresses (e.g., as in the case of Twice-NAT),   verification of signatures fails.   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 one realm and not the   other. Given that IKE is used to setup IPSec associations, and there   are at present no known ways of making IPSec work through a NAT   function, it is a future work item to take advantage of IKE through a   NAT box.   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 may   choose to include additional ALGs to custom support other   applications on the NAT device.7.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.   The sequence number and acknowledgement correction will need to be   performed on all future packet of the connection.Srisuresh & Holdrege         Informational                     [Page 24]RFC 2663           NAT Terminology and Considerations        August 19998.0. NAT limitations8.1. Applications with IP-address Content   Not All applications lend themselves easily to address translation by   NAT devices. 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 NAT functionality and   ALGs will not provide end-to-end security assured by IPsec.  However,   tunnel mode IPsec can be accomplished with NAT router 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.8.2. Applications with inter-dependent control and data sessions   NAT devices 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.8.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.Srisuresh & Holdrege         Informational                     [Page 25]RFC 2663           NAT Terminology and Considerations        August 19998.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. NAT router would need to   assemble the fragments together 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. Of course, the   application will fail if the payload needed to be altered. The   application could still work in a few cases, where the payload   contents can be valid in both realms, without modifications enroute.   For example, FTP originated from a private host would still work   while traversing a traditional NAT or bi-directional NAT device, so   long as the FTP control session employed PASV command to establish   data sessions. The reason being that the address and port number   specified by FTP server in the PASV response (sent as multiple   unfragmented packets) is valid to the private host, as is. The NAT   device will simply view the ensuing data session (also originating   from private host) as an independent TCP session.8.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 processing capacity   of the NAT device exceeds line processing rate, this should not be a   problem.9.0. Security Considerations   Many people view traditional NAT router as a one-way (session)   traffic filter, restricting sessions from external hosts into their   machines. In addition, when address assignment in NAT router is done   dynamically, that makes it harder for an attacker to point to any   specific host in the NAT domain. NAT routers may be used in   conjunction with firewalls to filter unwanted traffic.   If NAT devices 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 RSIP,   end-to-end IP network level security assured by current IPsecSrisuresh & Holdrege         Informational                     [Page 26]RFC 2663           NAT Terminology and Considerations        August 1999   techniques is not attainable with NAT devices in between. One of the   ends must be a NAT box. Refer section 7.0 for a discussion on why   end-to-end IPsec security cannot be assured with NAT devices along   the route.   The combination of NAT functionality, ALGs and firewalls will provide   a transparent working environment for a private networking domain.   With the exception of RSIP, end-to-end network security assured by   IPsec cannot be attained for end-hosts within the private network   (Refer section 5.0 for RSIP 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 NAT devices are part of a   trusted boundary, tunnel mode IPsec can be accomplished with NAT   router (or a combination of NAT, ALGs and firewall) serving as tunnel   end point.   NAT devices, 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 NAT, ALG and firewall functions co-exist to provide security   at the borders o