IAB T. Hain, Microsoft Internet Draft Document: draft-iab-nat-implications-00.txt March 1998 Architectural Implications of NAT 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). A revised version of this draft document will be submitted to the RFC editor as an Informational RFC for the Internet Community. Discussion and suggestions for improvement are requested. This document will expire before October 1998. Distribution of this draft is unlimited. Abstract In light of the growing interest in, and deployment of network address translation (NAT - RFC 1631), this paper will present some highlights of the architectural implications. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119]. Hain 1 Internet Draft Architectural Implications of NAT March 1998 Issues One view of NAT is that it is the feature which finally breaks the semantic overload of the IP address as both a locator and the end- point identifier (EID). Another view of NAT is that of necessary evil, where there is a real concern that the technology is the weed which is destined to choke out continued development. Since there are valid arguments on multiple points, some of them are listed here in a point-counter point style followed by a highlight of the issues. NAT value add NAT affliction -------------------------------- -------------------------------- Masks Global Address Changes Mandates Multiple Name Spaces Lowers Address Utilization Allows end-to-end address conflicts Lowers ISP support burden Increases local support burden Breaks end-to-end association Breaks end-to-end association Transparent to end systems Unique development for each app Load sharing as virtual host Performance impact with scale Delays need for IPv4 replacement Complicates integration of IPv6 NAT value add - Masking the address changes that take place from either dial-based access, or provider changes improves stability in the local network. - Globally routable addresses can be reused for dial customers, which appears to lower the demand and utilization of addresses. - There is a potential that NAT's would lower an ISPs support burden since there could be a consistent, simple device with a known configuration. Taken together these are strong motivations for moving quickly with NAT deployment. Breaking the semantic overload of the IP address will force applications to find a more appropriate mechanism for end point identification. This will not work for legacy applications, so RFC 1631 discusses how to look into the packet and make NAT transparent to the application. The greatest gain will be making developers of new apps think about what they are doing. Load sharing may be implemented through a function which redirects via packet manipulation, and is architecturally a NAT. This scheme gives the appearance that a service located through a single IP address has the responsiveness that is only possible with a group of machines, but the end client is not aware of actual implementation. Hain Expires October 1998 2 Internet Draft Architectural Implications of NAT March 1998 Some consider it a feature to limit evolution potential through NAT, where integration plans that assume the current address space is globally unique will fail, leaving IPv4 to continue unchallenged. (This viewpoint is not shared by the IAB.) NAT affliction A significant failure of NAT is the name space inconsistency. Very small-scale implementations usually do not see this because DNS is not used on the local side. When DNS is required to resolve a given host name on both sides of a NAT there is no good answer. Returning the local address will assure global invisibility, while returning the global address will prevent local visibility. If DNS were to return both, the results would be unpredictable. While NAT stabilizes the address used by local systems, it allows address collisions for applications that associate the end point IP addresses with the connection. The only way around this is to look into the application data stream and replace the address, then recalculate the checksum. Functionally this becomes an Application Level Gateway, even when it is still called a NAT. 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 the IP infrastructure as a multiplexing substrate allowing the end points to build circuits to run IP over. VPNs redefine network visibility and increase the likelihood of address collision when traversing NATs. Address management in the 'hidden space' behind NAT's 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 is both distributed and more complicated. The greatest concern from the explosion of NAT's is the impact on the fledgling efforts at deploying IP security. For lack of another globally unique EID, the traditional use of the IP address was assumed. This combination of required global uniqueness, and assured reuse by NAT leaves the IPsec effort with a severely restricted working set. 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 end points, 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 end points cant be identified. In a self- fulfillment of that prophecy, the applications developed to date are Hain Expires October 1998 3 Internet Draft Architectural Implications of NAT March 1998 structured to assume packets will be delivered and identity is only assured in controlled environments. In many ways, this fundamental impediment to basic trust has been the stalling factor in deploying security across the Internet. 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." Load sharing through a NAT function has all the scaling properties of the funnel that it is. There is a small but significant overhead involved as checksums are recalculated for every packet, (particularly for apps that include the end point IP address in the data stream). This point is generally glossed over with the line 'throw more hardware at it', but the laws of physics eventually prevail. The existence of NAT's will complicate the integration of IPv6 because the name space and end point addresses are not consistent and globally unique. While multiple addresses are less of a concern to an IPv6 node, the disjoint name space will certainly make management interesting. Security Considerations NAT's break a fundamental assumption of IPsec, and therefore represent a tremendous risk to deployment of enhanced security across the Internet. It is difficult to identify all the combinations of header orderings that are possible using NAT's, VPN's, and IPsec. It is even more difficult to clearly state which of those are applicable, or workable in any given context. IPsec can be made to work over NAT's, some of the time, when it is using certs, but even then there may be IP addresses in the SAs. Even the Null ESP has problems with NATs because IKE currently uses IP addresses that are in encrypted packets. In some implementations there may be work-arounds through the appropriate ordering of NAT's and VPN's, but in the end the lack of address administration behind the NAT's will result in collision and failure. With sufficient thought and advance planning, some of the issues between IPsec and NAT's can be worked around. Attempts to retrofit IPsec over and existing NAT infrastructure can be problematic, so in the generic sense; NAT's are the greatest single threat to security integration being deployed in the Internet today. Hain Expires October 1998 4 Internet Draft Architectural Implications of NAT March 1998 Summary NATs are a 'fact of life', and will proliferate as an enhancement which sustains the existing IPv4 infrastructure. At the same time, they require strong applicability statements, clearly stating what works and what does not. NAT's are a 'necessary evil' as well, and by fragmenting the Name Space, NAT's create an administrative burden that is not easily resolved. It is equivalent to digging a hole where the longer we continue digging, the harder it will be to get out. More significantly, they inhibit the roll out of IPsec, which will in turn slow growth of applications that require a secure infrastructure. As such, NATs represent the single greatest threat to a secure Internet. 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. The lifetime of existing IPv4 systems will likely be measured in decades. At best, NAT's are a diversion from forward motion, but they do enable wider participation at the present state. At their worst, they break an association that arguably should never have been made to begin with. 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 presented as complete and finished 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. References [RFC 1631], Egevang, K., Francis, P., "The IP Network Address Translator", RFC 1631, May 1994 [RFC 2101], Carpenter et. al., "IPv4 Address Behavior Today", RFC 2101, February 1997 [RFC-2119], Bradner, S, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997 Hain Expires October 1998 5 Internet Draft Architectural Implications of NAT March 1998 Acknowledgments The IAB contributed to this draft. Author's Addresses Tony Hain Microsoft One Microsoft Way Phone: 1-425-703-6619 Redmond, Wa. USA Email: tonyhain@microsoft.com Hain Expires October 1998 6
Datatracker
draft-iab-nat-implications-00
Internet-Draft
