One document matched: draft-iab-nat-implications-00.txt
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 ISP’s 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 (VPN’s). Technically VPN’s treat
the IP infrastructure as a multiplexing substrate allowing the end
points to build circuits to run IP over. VPN’s redefine network
visibility and increase the likelihood of address collision when
traversing NAT’s. 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 can’t 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
NAT’s 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, NAT’s 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 NAT’s. A short sighted view would miss the point that
both have a role, because NAT’s 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
| PAFTECH AB 2003-2026 | 2026-04-22 07:04:00 |