IAB T. Hain Internet Draft Microsoft Document: draft-iab-nat-implications-03.txt February 1999 Category: Informational Architectural Implications of NAT Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026 [1]. 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 memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited." Abstract In light of the growing interest in, and deployment of network address translation (NAT) RFC-1631, this paper will discuss some of the architectural implications and guidelines for implementations. It is assumed the reader is familiar with the address translation concepts presented in RFC-1631. Table of Contents Abstract ............................................................1 Definitions .........................................................4 Terminology ........................................................4 Advantages of NATs ..................................................7 Disadvantages of NATs ...............................................8 Illustrations ......................................................10 Considerations .....................................................16 IPv6 ..............................................................16 Security ..........................................................16 Deployment Guidelines .............................................18 Summary ............................................................19 References .........................................................21 Acknowledgments ...................................................22 Author's Addresses ................................................22 Copyright .........................................................22 Hain Informational - Expires August 1999 1 Architectural Implications of NAT February 1999 Introduction In May 1994, K. Egevang and P. Francis RFC-1631 [2] defined NAT as one means to ease the growth rate of IPv4 address use. Several places in the document they recognized the need to experiment and see what applications may be adversely affected by NAT's header manipulations, even before there was any significant operational experience. This is further evidenced in a quote from the conclusions: 'NAT has several negative characteristics that make it inappropriate as a long term solution, and may make it inappropriate even as a short term solution.' Nearly five years later, we find arguments that NAT is 'THE' short *AND* long-term solution, while questioning the strategy or continued effort at developing IPv6 as a replacement protocol. At the same time, the artificial shortage of IPv4 addresses, caused by the current stringent allocation guidelines, creates a perceived need to promote private address use via NAT. This increase in popularity of private addresses has resulted in additional experience, further exposing NAT's shortcomings. Unfortunately even as the failings of NAT are exposed, the technology is widely promoted as if it 'just works' with no serious effects except on a few legacy applications. The arguments pro & con frequently take on religious tones, with each side passionate about its position. - Proponents bring enthusiasm and frequently cite the most popular applications of Mail & Web services as shining examples of their cause. They will also point out that NAT is the feature that finally breaks the semantic overload of the IP address as both a locator and the global endpoint identifier (EID). - The opposing view of NAT is that of a malicious technology, where there is a concern that NAT is the weed which is destined to choke out continued Internet development. While recognizing there are perceived address shortages, the opponents of NAT view it as operationally inadequate at best, bordering on a sham as an Internet access solution. With reality somewhere in between these extreme viewpoints, it is clear NAT affects the transparency of end-to-end connectivity for transports relying on consistency of the IP header. Using a patchwork of mutually configured application specific gateways (ALG's), endpoints can work around some of the operational challenges of NAT. When there are two endpoints in a conversation this effort is straightforward, but for applications with more distributed and multi-point expectations it can be a significant ordeal. The complexity of coordinating the updates necessary to work around NAT grows geometrically with the number of endpoints. In a large environment, this may require concerted effort to simultaneously upgrade all endpoints of a given application or service. Hain Informational - Expires August 1999 2 Architectural Implications of NAT February 1999 The architectural role of NAT is to divide the Internet into independent address administrations, specifically facilitating casual use of private address assignments RFC-1918 [3]. As noted by Carpenter, et al RFC-2101 [4], once private use addresses were deployed in the network, addresses were guaranteed to be ambiguous. At the same time when NATs are attached to the network, the process of resolving names to or from addresses gains a dependency on where the question was asked. As NAT concatenates existing stand-alone name spaces, both names and addresses become globally ambiguous. A significant factor in the success of the Internet is the flexibility derived from a few basic tenets. Foremost is the End-to- End principle, which assumes the endpoints are in control of the communication and the network simply moves bits between these points. Restated, the data stream delivered by the transport protocol of the endpoints is of no concern to the lower layer packet routing devices, and therefore may contain anything the endpoint applications consider appropriate. (Note: while firewalls also break the end-to-end model, they are installed with the explicit intent to prevent access, where NAT claims to be transparent.) Another is that the network does not maintain per connection state information, which allows fast rerouting around failures through alternate paths. Lack of state also removes any requirement for the network nodes to notify each other as endpoint connections are formed or dropped. Furthermore, the endpoints are not, and need not be, aware of any network components other than the first hop router(s), name resolution service, and destination. Packet integrity is preserved through the network, and transport checksums are valid end-to-end. NATs (particularly the NAPT variety) break most of these, reducing overall flexibility, while increasing operational complexity and impeding diagnostic capabilities. The HNAT [5] and RSIP [6] variants have recently been proposed to address the end-to-end concerns. While they may be effective at providing the private node with a public address (if ports are available), they do not deal with the issues of; network state management, upper layer constraints like TCP TIME_WAIT state, or well-known-port sharing. Their port multiplexing variants also share the same neighbor DNS visibility concerns of NAPT, and each host requires significant stack modifications to enable the technology. Hain Informational - Expires August 1999 3 Architectural Implications of NAT February 1999 Definitions Terminology NAT - Network Address Translation in simple form is a method by which IP addresses are mapped from one address administration to another. ALG/NAT - combines ALG functions with simple NAT. Generally more useful than pure NAT, because it embeds a work around to specific applications that NAT breaks. DNS/ALG - special case of ALG/NAT, where an ALG for the DNS service interacts with the NAT component to manage DNS response contents. Static NAT - provides stable one-to-one mapping between address spaces. Dynamic NAT - provides many-to-few mapping from a relatively large number of addresses on one side to a few addresses on the other. NAPT - Network Address Port Translation accomplishes translation by multiplexing transport level identifiers of multiple addresses from one side, simultaneously into the transport identifiers of a single address on the other. HNAT - Host NAT allows endpoints to acquire and use their public address and port number at the source. The public / private process only allocates public addresses and forwards unmodified packets. This approach requires significant changes to the host stack implementation to dynamically manage tunnels to the HNAT server. RSIP - Realm Specific IP is a generalization of HNAT, including mechanisms for the private node to request multiple resources at once. This has the same requirement to modify Hosts as HNAT. ALG - Application Gateway is inserted between application peers to simulate a direct connection, when some intervening protocol or device prevents direct access. It terminates the transport protocol, and may modify the data stream before forwarding. Firewall - Special case of an ALG or routing filter, which implements access controls. Proxy - Special case of an ALG that is a simple relay service designed into a protocol, rather than capriciously inserted. VPN - Virtual Private Networks technically treat an IP infrastructure as a multiplexing substrate, allowing the endpoints to build virtual transit pathways, over which they run another instance of IP. Hain Informational - Expires August 1999 4 Architectural Implications of NAT February 1999 Address administration - coordinator of an address pool assigned to a collection of routers and end systems. Routing realm - collection of routers and end systems exchanging locally unique location knowledge (potentially in a hierarchical arrangement). NAT proponents define the NAT function as providing routing realms [7], where each domain is responsible for finding addresses within its boundaries. This work-around to the limitations NAT creates, hides them behind the well-understood need for routing management. Compartmentalization of routing information is really a function of routing protocols and their scope of application. NAT is simply a means to distribute address allocation authority and provide a mechanism to map one administrations addresses into those of another administration. The fact that experienced operators limit network topology, and don't leak addresses across a NAT, does not mean NAT itself provides any routing isolation services. In fact, if someone were to define an OSPF ALG it would be technically possible to route across a NAT boundary. Using a routing ALG, in combination with the fact that NAT breaks IPsec, could allow a private network to enforce which endpoints are even capable of attempting secure access while allowing non-secure access to other services. Hain Informational - Expires August 1999 5 Architectural Implications of NAT February 1999 Scope RFC-1631 limited the scope of NAT discussions to stub appendages of a public Internet. Therefore, in discussing the architectural impact of NATs on the Internet, the first task is defining the scope of the Internet. The most basic definition is; a concatenation of networks built using IETF defined technologies. This simple description does not distinguish between the public network known as the Internet, and the private networks built using the same technologies (including those connected via NAT). An approach resolving this would be including the resources of Names or Addresses administered through IANA or its delegates. While this is more accurate, it still includes many private networks that have coordinated their names or addresses with the public Internet. Rekhter, et al RFC-1918 defined hosts as public when they need network layer access outside the enterprise, using a globally unambiguous address. Those that need limited or no access are defined as private. Another way to view this is the transparency of the connection between any given node and the rest of the Internet. The ultimate resolution of public or private is found in the intent of the network in question. Generally, networks that do not intend to be part of the greater Internet will use some screening technology to insert a barrier. Historically barrier devices between the public and private networks were known as Firewalls or Application Gateways, and were managed to allow approved traffic while blocking everything else. Increasingly the screening technology is becoming a simple NAT, which manages the network locator between the public and private-use address spaces, and then using ALGs attempts to be transparent to protocols incompatible with NAT. (Use of NAT within a private network is possible, and is only addressed here in the context that some component of the private network is used as a common transit service between the NAT attached stubs.) The primary distinction between a Firewall and NAT in this context is the intent to block, or facilitate traffic flow. Hain Informational - Expires August 1999 6 Architectural Implications of NAT February 1999 Advantages of NATs A quick look at the popularity of NAT as a technology shows that it tackles several real world problems. - Masking the address changes that take place, from either dial- access or provider changes, minimizes impact on the local network by avoiding renumbering. - Globally routable addresses can be reused for intermittent access customers. This lowers the demand and utilization of addresses to the number of active nodes rather than the total number of nodes. - There is a potential that ISP provided and managed NATs would lower support burden since there could be a consistent, simple device with a known configuration at the customer end of the access interface. - Breaking the Internet into a collection of address authorities limits the need for continual justification of allocations. - For applications that don't rely on the integrity of the packet header, changes in the hosts may not be necessary. - Like route filtering Firewalls, NAPT, HNAPT, & RSIP block inbound connections to all ports until they are administratively mapped. Taken together these explain some of the strong motivations for moving quickly with NAT deployment. Removing hosts that are not currently active, lowers address demands of the public Internet. In cases where providers would end up with address allocations that could not be aggregated, this improves the load on the routing system as well as lengthens the lifetime of the IPv4 address space. While removing idle addresses is a natural byproduct of the existing dynamic allocation, dial-access devices, in the dedicated connection case this service could be provided through a NAT. In the case of a NAPT, the aggregation potential is even greater as multiple end systems share a single public address. By reducing the options and minimizing the potential support matrix, there is a potential that ISP provided NATs would lower support costs. (These savings may be more than offset by the additional support costs created when NAT breaks various applications.) Part of the motivation here is to avoid the high cost of renumbering inherent in the current IPv4 Internet. Localizing address administration minimizes those costs, and simultaneously provides for a much larger local pool of addresses than is available under current allocation guidelines. (The registry guidelines are intended to prolong the lifetime of the IPv4 address space until IPv6 is ready, by managing allocations to match actual demand. They may end up hampering growth in areas where it is difficult to sort out real need from potential hoarding.) Until IPv6 provides a simpler solution, NAT is effective at masking provider switching or other requirements to change addresses. Hain Informational - Expires August 1999 7 Architectural Implications of NAT February 1999 NAT deployments have been raising the awareness of protocol designers who are interested in ensuring that their protocols work end-to-end. Breaking the semantic overload of the IP address will force applications to find a more appropriate mechanism for endpoint identification and discourage carrying the locator in the data stream. Since this will not work for legacy applications, RFC-1631 discusses how to look into the packet and make NAT transparent to the application (ie: create an application gateway). This may not be possible for all applications, and even with application gateways in the path, it may be necessary to modify the end host to be aware there may be intermediaries modifying the data. Another popular practice is hiding a collection of hosts that provide a combined service behind a single IP address (ie: web host load sharing). In many implementations this is architecturally a NAT, since the addresses are mapped to the real destination on the fly. When packet header integrity is not an issue, this type of virtual host requires no modifications to the remote applications since the end client is unaware of the mapping activity. While the virtual host has the CPU performance characteristics of the total set of machines, the overall performance is bounded by the processing and I/O capabilities of the NAT device as it funnels the packets back and forth. Disadvantages of NATs - NATs break the flexible end-to-end model of the Internet. - NATs create a single point where fates are shared, in the device maintaining connection state and dynamic mapping information. - NATs inhibit implementation of security at the IP level. - NATs facilitate concatenating existing name spaces with the DNS. - NATs enable address collisions when VPNs traverse multiple NATs along a path. - NAPT, HNAPT, & RSIP increase operational complexity when published services reside on the private side. This includes the restriction that only one private side system can be accessed through a given public side well-known-port. As noted earlier, NATs break the basic tenet of the Internet that the endpoints are in control of the communication. The original design put state control in the endpoints so there would be no other inherent points of failure. Moving the state from the endpoints to specific nodes in the network reduces flexibility, while it increases the impact of a single point failure. In addition, NATs are not transparent to all applications, and managing simultaneous updates to a large array of ALGs may exceed the cost of acquiring additional globally routable addresses. While RSIP addresses the transparency and ALG issues, for the specific case of individual private to public, there is still a node with specific state required to maintain the connection. Hain Informational - Expires August 1999 8 Architectural Implications of NAT February 1999 Dynamic NAT, HNAT, and RSIP will eventually violate higher layer assumptions about address/port number reuse RFC-793 [8] RFC-1185 [9]. The TCP state, TIME_WAIT, is specifically designed to prevent replay of packets between the 4-tuple of IP & port for a given IP address pair. Since the TCP state machine of a second private side node is unaware of any previous use, its attempts to connect to the same service as its neighbor, which is still in TIME_WAIT, will fail. The full range of upper layer architectural assumptions that are broken by NAT technologies may not be well understood without a very large-scale deployment. One of the greatest concerns from the explosion of NATs is the impact on the fledgling efforts at deploying IP security. One fundamental issue for IPSec is that with both AH and ESP, the authentication check covers the TCP/UDP checksum (which in turn covers the IP address). When a NAT changes the IP address, the checksum calculation will fail, and therefore authentication will fail. This combination of required global uniqueness of the address, and assured ambiguity by NAT leaves the IPsec effort without a workable solution. In a statement about the use of IPv4 today, RFC-2101 details architectural issues and notes: "... it has been considered more useful to deliver the packet, then worry about how to identify the endpoints, than to provide identity in a packet that cannot be delivered." This argument presumes that delivering the packet has an inherent value, even if the endpoints cannot be identified. In a self- fulfillment of that prophecy, many applications developed to date are structured to assume packets will be delivered and identity is only assured in controlled environments. In another note from RFC-2101: "Since IP Security authentication headers assume that the addresses in the network header are preserved end-to-end, it is not clear how one could support IP Security-based authentication between a pair of hosts communicating through either an ALG (ed: Application Level Gateway) or a NAT." There are distributed applications that assume that IP addresses are globally scoped, globally unique, globally routable, and all hosts have the same view of those addresses. NATs break these applications. There are other applications that assume that all upper layer ports from a given IP address map to the same endpoint, and port multiplexing technologies like NAPT, HNAPT, and RSIP breaks those. NATs place constraints on the deployment of applications that carry IP addresses (or derivatives), in the data stream. Applications or protocols that assume end-to-end integrity of the address will fail when traversing a NAT. (TCP was specifically designed to take advantage of, and reuse the IP address for use as a transport address.) To resolve this, an Application Level Gateway needs to Hain Informational - Expires August 1999 9 Architectural Implications of NAT February 1999 exist within each NAT. An additional gateway service is necessary for each application that may imbed an address. Even this approach will fail when requirement is end-to-end encryption since only the endpoints have access to the keys. Finally, while the port multiplexing variants of NAT (popular because they allow Internet access through a single address) work modestly well for connecting private hosts to public services, they create management problems for applications connecting from public toward private. The concept of a well-known-port is undermined because only one private side system can be mapped through the single public-side port number. This will affect home networks, when applications like multi-player Internet games can only be played on one system at a time. It will also affect small businesses when only one system at a time can be operated on the standard port to provide web services. The issue is that the public toward private usage requires administrative mapping for each target prior to connection. Illustrations A feature of stateful devices like NATs is the creation of a single point of failure. Attempts to avoid this by establishing redundant NATs, creates a new set of problems related to timely communication of the state, and routing related failures. This encompasses several issues such as update frequency, performance impact of frequent updates, reliability of the state update transaction, a-priori knowledge of all nodes needing this state information, and notification to end nodes of alternatives. (This last point could be accomplished with a routing protocol, which might require modifications to the hosts so they will listen.) It has been observed that operational management of networks incorporating stateful packet modifying device is considerably easier if inbound and outbound packets traverse the same path. While easy to say, it is difficult to manage using a connectionless protocol, even with careful planning. The problem is ensuring that routes advertised to the private side reach the end nodes and map to the same device as the public side route advertisements. This state needs to persist throughout the lifetime of sessions traversing the NAT. A point to bear in mind is the frequency of simultaneous internal and external topology churn. Consider the following case where the -X- links are broken, or flapping. Hain Informational - Expires August 1999 10 Architectural Implications of NAT February 1999 -------- -------- | Host A | | Host B | | Foo | | Bar | -------- -------- | | ---- ---- |Rtr1|---X----|Rtr2| ---- ---- | | ---- ---- |NAT1| |NAT2| ---- ---- | | -------------- |Rtr Rtr| | / Internet \ | --- |Rtr----X----Rtr|----|DNS| -------------- --- | | | | -------- -------- | Host C | | Host D | -------- -------- To maintain sanity with external routing, the default path for Routers 1 & 2 is via NAT1. When the path between Router 1 & 2 breaks, Router 2 would attempt to switch to NAT2, but the external return path would still be through NAT1. In this case, redundancy was useless. While this scenario is strictly a routing failure, the normal routing tools for resolving it are not available because the connection to the Internet is via NATs. Consider the case that the path between Router 1 & 2 is up, and some remote link in the network is down. When Host D tries to contact Host B, the request goes through NAT2, but the reply is through NAT1. Since the state information for this connection is in NAT2, NAT1 will provide a new mapping. Even if the remote path is restored, the connection will not be made because the requests are to the public IP of NAT2, while the replies are from the public IP of NAT1. In another case, both Host A & B want to contact Host D, when some remote link in the Internet breaks. As long as the path between Router 1 & 2 is still down, Host B is able to connect, but Host A is cut off. In addition, Host A is unable to contact DNS to even find the address of Host D. Without a thorough understanding of the remote topology (unlikely since that tends to be sensitive proprietary information), the administrator of Hosts A & B would have no clue why one worked and the other didn't. As far as he can tell both paths are up and the redundancy is covering the local outage, but only one connection works. Hain Informational - Expires August 1999 11 Architectural Implications of NAT February 1999 In any network topology, individual router or link failures may present problems with insufficient redundancy, but the state maintenance requirements of NAT present an additional burden that is not as easily resolved. By facilitating concatenation of multiple name spaces, NAT exaggerates a problem in the process of resolving addresses from names, or names from addresses. (This occurs when an existing stand- alone site attaches to the Internet through a NAT, without renaming all hosts.) When the public DNS is required to resolve a given host name on both sides of a NAT there is no obviously correct answer. In the example below it is not clear what answer DNS should return for Host D. Returning the local address will assure global invisibility, while returning the global address will prevent local access from Host C. If DNS were to return both, the results would be unpredictable. By knowing which side the request came from the DNS server could provide the correct answer, but significant development would be required to add the capability to DNS for source specific responses. (note: since Host A has no access to the Internet (therefore the DNS service), it is required to maintain a local table, but the others may be expecting DNS to provide the appropriate resolution.) In the case where Hosts C & D share an address (either time-shared or port multiplexed), there is no way Host B could know which it was connecting to. DNS would return a public side address for either, then it is up to the NAT to decide where the packets are eventually directed. Since Host B cannot tell, it may end up connecting to a very different service than it expected for the name used. (This would also be true for connections from C or D to the other.) For connections originating from C or D toward B, B would not be able to resolve which system was really trying to connect, and might inadvertently allow access to the wrong system. -------- --- --- -------- | Host A |--|NAT|------|NAT|--| Host B | -------- --- --- -------- \ \ --- -------- --- |NAT|---|Internet|----|DNS| --- -------- --- | ----------------- | | -------- -------- | Host C | | Host D | -------- -------- Even if forward mappings are working, implementations that require an unambiguous reverse mapping from the in-addr.arpa tree will fail. Discussions about an arbitrary mesh of NAT connections will ultimately exaggerate the issue of name space integration with the routing infrastructure. It will show that the only resolution to Hain Informational - Expires August 1999 12 Architectural Implications of NAT February 1999 appropriately answer name queries in a NAT environment is to locate the DNS service within each NAT. One proposal to deal with locating the DNS service in each NAT is the DNS/ALG [10]. Rather than running the full DNS server in the NAT, it provides a mapping service by intercepting DNS messages and modifying the contents appropriately. This method presents a requirement that the DNS response traverse the node with the mapping state for the final connection. Note the first example for operational failure potential of finding the correct NAT. DNS/ALG specifically avoids discussion of private nodes finding each other when the DNS server is on the far side of a NAPT. The primary feature of NATs is the 'simple' ability to connect private networks to the public Internet. When the private network exists prior to installing the NAT, it is unlikely and unnecessary that its name resolver would use a registered domain. Connecting the NAT device, and reconfiguring the resolver to proxy for all external requests allows access to the public network by hosts on the private network. Configuring the public DNS for the set of private hosts that need inbound connections would require a registered domain (either private, or from the connecting ISP) and a unique name. At this point the partitioned name space is concatenated and hosts would have different names based on inside vs. outside queries. -------- -------- | Host A | | Host B | | Foo |-----| Bar | -------- | -------- --- |-------------|DNS| --- --- |NAT| --- | -------- --- |Internet|----|DNS| -------- --- | --- |NAT| --- --- |-------------|DNS| -------- | -------- --- | Host C |-----| Host D | | Foo | | Bar | -------- -------- Everything in this simple example will work until an application embeds a name. For example, a Web service running on Host D might present embedded URL's of the form http://bar/*.html, which would work from Host C, but would thoroughly confuse Host A. If the embedded name resolved to the public address, Host A would be happy, but Host C would be looking for some remote machine. Using the public FQDN resolution to establishing a connection from Host C to D, the NAT would have to look at the destination rather than simply Hain Informational - Expires August 1999 13 Architectural Implications of NAT February 1999 forwarding the packet out to the router. (Normal operating mode for a NAT is translate & forward out the other interface, while routers do not send packets back on the same interface they came from). The NAT did not create the name space fragmentation, but it facilitates attempts to merge networks with independent name administrations. The recent mass growth of the Internet has been driven by support of low cost publication via the web. The next big push appears to be support of Virtual Private Networks (VPNs). Technically VPNs treat an IP infrastructure as a multiplexing substrate allowing the endpoints to build what appear to be clear pathways from end-to-end. VPNs redefine network visibility and increase the likelihood of address collision when traversing multiple NATs. Address management in the private space behind NATs will become a significant burden, as there is no central body capable of, or willing to do it. The lower burden for the ISP is actually a transfer of burden to the local level, because administration of addresses and names becomes both distributed and more complicated. As noted in RFC-1918, the merging of private address spaces can cause an overlap in address use, creating a problem. VPNs will increase the likelihood and frequency of that merging through the simplicity of their establishment. There are several configurations of address overlap which will cause failure, but in the simple example shown below the private use address of Host B matches the private use address of the VPN pool used by Host A for inbound connections. When Host B tries to establish the VPN, Host A will assign it an address from its pool for inbound connections, and identify the gateway for Host B to use. In the example, Host B will not be able to distinguish the remote VPN address of Host A from its own address, so the connection will fail. Since private use addresses are by definition not publicly coordinated, as the complexity of the VPN mesh increases so does the likelihood that there will be a collision which cannot be resolved. --------------- ---------------- | 10.10.10.10 |--------VPN--------| Assigned by A | | Host A | --- --- | Host B | | 10.1.1.1 |--|NAT|-----|NAT|--| 10.10.10.10 | --------------- --- --- ---------------- Hain Informational - Expires August 1999 14 Architectural Implications of NAT February 1999 Another potential use of NAT is reusing a range of allocated addresses at multiple sites within an organization. In the following example, the network manager has chosen to use time-shared traditional NAT, with /8 of the corporate allocation on the public side at each site. To avoid any problems with private addresses, the upper half of the publicly allocated address block is assigned to the local DHCP service, at each site. -------- -------- | Host A |-----| Host B | -------- | -------- | 1.1.128.x /15 --- |----------------|DNS| --- --- |NAT| --- | 1.1.2.x /8 -------- --- | ISP |----|DNS| -------- --- | 1.1.3.x /8 --- |NAT| --- | 1.1.128.x /15 --- |----------------|DNS| -------- | -------- --- | Host C |-----| Host D | -------- -------- While the addresses used are from publicly assigned space, the NAT in the path puts them in the same class as private allocations. NAT used in this instance has all the same characteristics as the implementations using any of the private ranges. This example shows that that NAT is the source of the concerns, not the use of private addresses. Hain Informational - Expires August 1999 15 Architectural Implications of NAT February 1999 Considerations IPv6 It has been argued that IPv6 is no longer necessary because NATs relieve the address space constraints and allow the Internet to continue growing. The reality is they point out the need for IPv6 more clearly than ever. People are trying to connect multiple machines through a single access line to their ISP and have been willing to give up some functionality to get that at minimum cost. Frequently the reason for cost increases is the perceived scarcity (therefore increased value) of IPv4 addresses, which would be eliminated through deployment of IPv6. This crisis mentality is creating a market for a solution to a problem already solved with greater flexibility by IPv6. Beyond all of the above issues, the existence of NATs will complicate the integration of IPv6 in the Internet as the name space and endpoint addresses attempt to become consistent and globally unique. While multiple addresses are explicitly supported by an IPv6 node, the disjoint name space will certainly make management interesting. If IPv6 nodes are willing to continue in private networks behind a NAT, they will only need a site local address and all of the issues become the same as IPv4. If the intent is to move into a public address allocation as a feature of moving to IPv6, any independent name administrations will require explicit effort to merge with the public DNS as well. Security NAT (particularly NAPT) lowers overall security because it creates the illusion of a security barrier. Appropriate security mechanisms are implemented in the end host, without reliance on assumptions about routing hacks, firewall filters, or missing NAT translations, which may change over time to enable a service to a neighboring host. In general, defined security barriers assume that any threats are external, leading to practices which make internal breaches that much easier. NATs break the defined implementation modes of IPsec, and therefore may stall further deployment of enhanced security across the Internet. It is difficult to identify all the combinations of header orderings and options that are possible using NATs, VPNs, and IPsec. It is even more difficult to clearly state which of those are applicable, or workable in any given context. For example; - Use of AH is not possible via NAT as the hash protects the IP address in the header. - Authenticated certificates may contain the IP address as part of the subject name for authentication purposes. - Encrypted Quick Mode structures may contain IP addresses and ports for policy verifications. Hain Informational - Expires August 1999 16 Architectural Implications of NAT February 1999 - The Revised Mode of public key encryption includes the peer identity in the encrypted payload. It may be possible to engineer and work around NATs for IPsec on a case by case basis. With all of the restrictions placed on deployment flexibility, NATs present a significant obstacle to security integration being deployed in the Internet today. As noted in the DNS/ALG draft, the DNS/ALG cannot support secure DNS name servers in the private domain. Zone transfers between DNSsec servers will be rejected when necessary modifications are attempted. It is also the case that DNS/ALG will break any modified, signed responses. This would be the case for all public side queries of private nodes, when the DNS server is on the private side. It would also be true for any private side queries for private nodes, when the DNS server is on the public side. Digitally signed records could be modified by the DNS/ALG if it had access to the source authentication key. DNSsec has been specifically designed to avoid distribution of this key, to maintain source authenticity. So NATs that use DNS/ALG to repair the namespace resolutions will either; break the security when modifying the record, or will require access to all source keys to requested resolutions. Security mechanisms that do not protect or rely on IP addresses as identifiers, such as TLS [11], SSL [12], or SSH [13] may operate in environments containing NATs. For applications that can establish and make use of this type of transport connection, NATs do not create any additional complications. These technologies may not provide sufficient protection for all applications as the header is exposed, allowing subversive acts like TCP resets. RFC-2385 [14] discusses the issues in more detail. Hain Informational - Expires August 1999 17 Architectural Implications of NAT February 1999 Deployment Guidelines Given that NAT devices are being deployed at a fairly rapid pace, some guidelines are in order. Most of these amount to 'think before you leap', then think again, then make sure you really want to start down this path. - Determine the mechanism for name resolution, and ensure the appropriate answer is given for each address administration. Embedding the DNS server, or a DNS ALG in the NAT device will likely be more manageable than trying to synchronize independent DNS systems across realms. - Is the NAT configured for static one to one mappings, or will it dynamically manage them? If dynamic, make sure the TTL of the DNS responses is set to 0, and that the clients pay attention to the don't cache notification. - Will there be a single NAT device, or parallel with multiple paths? If single, consider the impact of a device failure. If multiple, consider how routing on both sides will insure the packets flow through the same box over the connection lifetime of the applications. - Examine the applications that will need to traverse the NAT and verify their immunity to address changes. If necessary provide an appropriate ALG or establish a VPN to isolate the application from the NAT. - Determine need for public toward private connections, variability of destinations on the private side, and potential for simultaneous use of public side port numbers. NAPTs increase administration if these apply. - Determine if the applications traversing the NAPT, HNAPT, or RSIP expect all ports from the public IP address to be the same endpoint. Administrative controls to prevent simultaneous access from multiple private hosts will be required if this is the case. - If there are encrypted payloads, the contents cannot be modified unless the NAT is a security endpoint, acting as a gateway between security realms. This precludes end-to-end confidentiality, as the path between the NAT and endpoint is exposed. - Determine the path for name resolutions. If hosts on the private side of a NAPT, HNAPT, or RSIP server need visibility to each other, a private side DNS server may be required. - If the environment uses secure DNS records, the DNS/ALG will require access to the source authentication keys for all records to be translated. - When using VPNs over NATs, identify a clearinghouse for the private side addresses to avoid collisions. - Assure that applications used both internally and externally avoid embedding names, or use globally unique ones. - When using HNAT or RSIP, recognize the scope is limited to individual private network connecting to the public Internet. If other NATs are in the path (including web-server load-balancing devices), the advantage is lost. In addition, the port multiplexing versions of these carry the same well-known-port sharing problem of NAPT. Hain Informational - Expires August 1999 18 Architectural Implications of NAT February 1999 Summary Over the 5-year period since RFC-1631, the experience base has grown, further exposing concerns raised by the original authors. NAT breaks a fundamental assumption of the Internet design; the endpoints are in control. Another design principle, 'keep-it-simple' is being overlooked as more features are added to the network to work around the complications created by NATs. In the end, overall flexibility and manageability are lowered, and support costs go up to deal with the problems introduced. Evangelists, for and against the technology, present their cases as righteous while downplaying any rebuttals. - NATs are a 'fact of life', and will proliferate as an enhancement that sustains the existing IPv4 infrastructure. - NATs are a 'necessary evil' and create an administrative burden that is not easily resolved. More significantly, they inhibit the roll out of IPsec, which will in turn slow growth of applications that require a secure infrastructure. In either case, NATs require strong applicability statements, clearly declaring what works and what does not. An overview of the pluses and minuses: NAT advantages NAT disadvantages -------------------------------- -------------------------------- Masks global address changes Breaks end-to-end model Stateful points of failure Breaks IPsec Facilitates concatenation of multiple name spaces Address administrations avoid Requires source specific DNS reply justifications to registries or DNS/ALG DNS/ALG breaks DNSsec replies Lowers address utilization Enables end-to-end address conflicts Lowers ISP support burden Increases local support burden and complexity Transparent to end systems in some Unique development for each app cases Load sharing as virtual host Performance limitations with scale Delays need for IPv4 replacement May complicate integration of IPv6 There have been many discussions lately about the value of continuing with IPv6 development when the market place is widely deploying IPv4 NATs. A short sighted view would miss the point that both have a role, because NATs address some real-world issues today, while IPv6 is targeted at solving fundamental problems, as well as moving forward. It should be recognized that there will be a long co-existence as applications and services develop for IPv6, while the lifetime of the existing IPv4 systems will likely be measured in decades. At their best, NATs are a diversion from forward motion, but they do enable wider participation at the present state. At Hain Informational - Expires August 1999 19 Architectural Implications of NAT February 1999 their worst, they break a class of applications, which creates the need for complex work-arounds. Efforts to enhance general security in the Internet include IPsec and DNSsec. These technologies provide a variety of services to both authenticate and protect information during transit. By breaking these technologies, NAT and the DNS/ALG work-around, hinder deployment of enhanced security throughout the Internet. There have also been many questions about the probability of VPNs being established that might raise some of the listed concerns. While it is hard to predict the future, one way to avoid ALGs for each application is to establish a VPN over the NATs. This restricts the NAT visibility to the headers of the tunnel packets, and removes its effects from all applications. While this solves the ALG issues, it raises the likelihood that there will be address collisions as arbitrary connections are established between uncoordinated address spaces. It also creates a side concern about how an application establishes the necessary VPN. The original IP architecture is powerful because it provides a general mechanism on which other things (yet unimagined) may be built. While it is possible to build a house of cards, time and experience have lead to building standards with more structural integrity. IPv6 is the long-term solution that retains end-to-end transparency as a principle. NAT is a technological diversion to sustain the lifetime of IPv4. Everyone needs to focus on the goal, which is continued evolution of the Internet, and recognize continued development of IP (in all current and future versions) is the path. It has been noted that the success of the Internet is based on the 'living' characteristic of IP. As in life, when growth, evolution, and forward progress stops, decay overtakes and destroys. History has shown that protocols that were 'complete and finished' as presented, have had very short lifetimes while those still 'a work in progress' manage to survive and continue moving ahead. All parties need to understand the significant role they are playing in pursuing the goal, and that none can get there without all the others. Hain Informational - Expires August 1999 20 Architectural Implications of NAT February 1999 References 1 RFC-2026 Bradner, S., " The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 RFC-1631 Egevang, K., Francis, P., "The IP Network Address Translator", RFC 1631, May 1994 3 RFC-1918, Rekhter, et al, "Address Allocation for Private Internets", RFC 1918 February 1996 4 RFC-2101, Carpenter, et al, "IPv4 Address Behavior Today", RFC 2101, February 1997 5 draft-ietf-nat-hnat-00.txt, Jeffrey LoCategory, K.Taniguchi, "IP Host Network Address (and Port) Translation", November 1998 6 draft-ietf-nat-rsip-protocol-00.txt, M. Borella, D. Grabelsky, J.lo, K. Tuniguchi, "Realm Specific IP: Protocol Specification", February 1999 7 draft-ietf-nat-terminology-01.txt, P. Srisuresh, Matt Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", October 1998 8 RFC-793, J. Postel, "Transmission Control Protocol", RFC 793, September 1981 9 RFC-1185, V. Jacobson, R. Braden, L. Zhang, "TCP Extension for High-Speed Paths", RFC 1185, October 1990 10 draft-ietf-nat-dns-alg-01.txt, P. Srisuresh, G. Tsirtsis, P. Akkiraju, A. Heffernan "DNS extensions to Network Address Translators", October 1998 11 draft-ietf-tls-protocol-05.txt, T. Dierks, C. Allen, "The TLS Protocol", November 1997 12 http://home.netscape.com/eng/ssl3/ssl-toc.html March 1996 13 draft-ietf-secsh-architecture-02.txt, T. Ylonen, et al, "SSH Protocol Architecture", August 1998 14 RFC-2385, A. Heffernan, "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998 Hain Informational - Expires August 1999 21 Architectural Implications of NAT February 1999 Acknowledgments Valuable contributions to this draft came from the IAB, Vern Paxson (lbl), Keith Moore (utk), Thomas Narten (ibm), Yakov Rekhter(cisco) and Eliot Lear (cisco). Author's Addresses Tony Hain Microsoft One Microsoft Way Phone: 1-425-703-6619 Redmond, Wa. USA Email: tonyhain@microsoft.com Copyright "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Hain Informational - Expires August 1999 22
Datatracker
draft-iab-nat-implications-03
Internet-Draft
