away from the longer-term solution.
But at the same time NAT functionality may be a critical facilitator
in the deployment of IPv6. There are already 100 million or more
computers running IPv4 on data networks. Some of these networks are
connected to and thus part of the Internet and some are on private
isolated networks. It is inconceivable that we could have a "flag
day" and convert all of the existing IPv4 nodes to IPv6 at the same
time. There will be a very long period of coexistence while both
IPv4 and IPv6 are being used in the Internet and in private networks.
The original IPv6 transition plan relied heavily on having new IPv6
nodes also be able to run IPv4 - a "dual stack" approach. When the
dual stack node looks up another node in the DNS it will get back a
IPv4 or an IPv6 address in response. If the response is an IPv4
address then the node uses IPv4 to contact the other node. And if the
response is an IPv6 address then IPv6 can be used to make the
contact. Turning the NAT into a 6to4 [13]router enables widespread
deployment of IPv6 while providing an IPv4 path if IPv6 is
unavailable. While this maintains the current set of issues for IPv4
connections, it reestablishes the end-to-end principle for IPv6
connections.
An alternative methodology would be to translate the packets between
IPv6 and IPv4 at the boarders between IPv4 supporting networks and
IPv6 supporting networks. The need for this functionality was
recognized in [RFC1752], the document that recommended to the IETF
that IPv6 be developed and recommended that a set of working groups
be established to work on a number of specific problems. Header
translation (i.e, NAT) was one of those problems.
Of course, NATs in an IPv6 to IPv4 translation environment encounter
all of the same problems that NATs encounter in a pure IPv4 and the
environment and cautions in this document apply to both situations.
9. Security Considerations
NAT (particularly NAPT) actually has the potential to lower overall
security because it creates the illusion of a security barrier, but
does so without the managed intent of a firewall. 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 that make internal
breaches much easier.
IPsec RFC-2401 [7] defines a set of mechanisms to support packet-
level authentication and encryption for use in IP networks. While
this may be less efficient than application-level security but in the
words of RFC-1752 [14] "support for basic packet-level authentication
will provide for the adoption of a much needed, widespread, security
infrastructure throughout the Internet."
NATs break IPsec's authentication and encryption technologies because
these technologies depend on an end-to-end consistency of the IP
addresses in the IP headers, and therefore may stall further
deployment of enhanced security across the Internet. NATs raise a
number of specific issues with IPsec. 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.
- 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, but at the cost of restricting the trust model,
as discussed in section 4 above. 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 RFC-2694 [15], 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 [16], SSL [17], or SSH [18] 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 [19] discusses
the issues in more detail.
Arguments that NATs may operate in a secure mode preclude true End-
to-End security, as the NAT becomes the security endpoint.
Operationally the NAT must be managed as part of the security domain,
and in this mode the packets on the unsecured side of the NAT are
fully exposed.
10. Deployment Guidelines
Given that NAT devices are being deployed at a fairly rapid pace,
some guidelines are in order. Most of these cautionary in nature and
are designed to make sure that the reader fully understands the
implications of the use of NATs in their environment.
- 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 administrations.
- 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 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 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 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 of RSIP (end-to-end address/port pair use) is lost.
- For RSIP, determine the probability of TCP_Time_Wait collisions
when subsequent private side hosts attempt to contact a recently
disconnected public side service.
11. Summary
Over the 6-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
Eases renumbering when providers Facilitates concatenation of
change multiple name spaces
Breaks IPsec
Stateful points of failure
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 shortsighted 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. NATs are a diversion from forward motion, but they do
enable wider participation at the present state. They also break a
class of applications, which creates the need for complex work-around
scenarios.
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 L2TP 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 tunnel.
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.
12. References
1 Bradner, S., " The Internet Standards Process -- Revision 3", BCP
9, RFC2026, October 1996.
2 Egevang, K. and P. Francis, "The IP Network Address Translator",
RFC1631, May 1994.
3 Srisuresh, P. and M. Holdrege, "NAT Terminology and
Considerations", RFC2663, August 1999.
4 Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E.
Lear, "Address Allocation for Private Internets", BCP 5, RFC
1918, February 1996.
5 Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address
Behavior Today", RFC2101, February 1997.
6 M. Borella, D. Grabelsky, J., K. Tuniguchi, "Realm Specific IP:
Protocol Specification", Work in Progress, March 2000.
7 Kent, S. and R. Atkinson, "Security Architecture for IP", RFC
2401, November 1998.
8 Carpenter, B., "Internet Transparency", RFC2775, February 2000.
9 Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D. and J.
Postel, "Internet Registry IP Allocation Guidelines", BCP 12, RFC
2050, November 1996.
10 Postel, J., "Transmission Control Protocol", STD 7, RFC793,
September 1981.
11 Jacobson, V., Braden, R. and L. Zhang, "TCP Extension for High-
Speed Paths", RFC1185, October 1990.
12 Braden, R., "Requirements for Internet Hosts", STD 3, RFC1123,
October 1989.
13 Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4
Clouds without Explicit Tunnels", Work in Progress.
14 Bradner, S. and A. Mankin, "Recommendation for IPng", RFC1752,
January 1995.
15 Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A. Heffernan, "DNS
extensions to NAT", RFC2694, September 1999.
16 Dierks, T. and C. Allen, "The TLS Protocol", RFC2246, January
1999.
17 http://home.netscape.com/eng/ssl3/ssl-toc.html, March 1996.
18 T. Ylonen, et al., "SSH Protocol Architecture", Work in Progress,
August 1998.
19 Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC2385, August 1998.
13. Acknowledgments
Valuable contributions to this document came from the IAB, Vern
Paxson (lbl), Scott Bradner (harvard), Keith Moore (utk), Thomas
Narten (ibm), Yakov Rekhter (cisco), Pyda Srisuresh, Matt Holdrege
(lucent), and Eliot Lear (cisco).
14. Author's Address
Tony Hain
Microsoft
One Microsoft Way
Redmond, Wa. USA
Phone: 1-425-703-6619
EMail: tonyhain@microsoft.com
Full Copyright Statement
Copyright (C) The Internet Society (2000). 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.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.