NAT Working Group D. Senie
INTERNET-DRAFT Amaranth Networks Inc.
Category: Unknown November 1998
Expires in six months
NAT Friendly Application Design Guidelines
<draft-ietf-nat-app-guide-00.txt>
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
"`id-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).
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
Preface:
While many common Internet applications will operate cleanly in the
presence of Network Address Translators, others suffer from a variety
of problems when crossing these devices. This document discusses
those things which application designers might wish to consider when
designing new protocols. Guidelines are presented herein to help
ensure new protocols and applications will, to the extent possible,
be compatible with NAT.
1. Introduction
Other documents which describe Network Address Translation (NAT)
discuss the Terminology and Considerations [Srisuresh1] and Protocol
Issues [Holdrege] or discuss the preceived implications of NAT [Hain]
[Rekhter]. All of those relate to various issues with the NAT
mechanism and its effects on protocols which already exist. It is the
focus of this document to instruct authors of new protocols what to
think about when designing new protocols such that special handling
Senie [Page 1]
Internet-Draft NAT Friendly Application Design October 1998
is not required at NAT gateway points.
When a protocol is unable to pass cleanly through a NAT, the use of
an Application Level Gateway (ALG) can still permit operation of the
protocol. Depending on the encoding used in a protocol, the ALG may
be difficult or easy to construct. While adjunct to NAT, the
formulation of protocols which cannot directly operate through NAT
should be considered such that the ALG design may be simple and
automated. ALGs typically operate inside small routers along with the
NAT component. Ideally, the ALG should be simple and not require
excessive computation or state storage.
The same issues in application design which create issues for NAT
(and thus can require ALG support) are also issues for firewalls. An
application designer would do well to keep this in mind, as any
protocol which does require special handling by NAT or firewall
products will be more difficult to deploy than those which require no
special handling.
2. Discussion
Network Address Translation presents a challenge to some existing
applications. It should be possible for developers of new
applications to avoid problems if they understand the issues
involved. This document aims to provide the application designer with
information on what to do, and what to avoid, when building
applications.
The proliferation of NAT, especially in homes and small offices
cannot be dismissed. The emerging technologies for providing high
bandwidth to these types of locations often allow only a single IP
address per location. As such NAT is a clear choice for connecting
more than a single system per location.
Clearly the most common problem associated with NAT implementations
is the passing of addressing data between stations. Where possible,
applications should find alternatives to such schemes. Studying a few
existing protocols will serve to highlight the different approaches
possible.
Two common forms of NAT exist. With Basic NAT, only the IP addresses
of packets are altered by the NAT implementation. Many applications
will operate correctly with Basic NAT. The other common form is
Network Address Port Translation. With NAPT, both the IP addresses
and the source and destination ports (for TCP and UDP) are
potentially altered by the gateway. As such, applications which pass
only port number information will work with Basic NAT, but not with
NAPT.
Senie [Page 2]
Internet-Draft NAT Friendly Application Design October 1998
Application designers should ensure compatability with NAPT, as this
form of NAT is the most widely deployed. This is also the form of NAT
which will likely see the greatest penetration in homes and small
offices.
3. Recommendations and Examples
When possible, applications designers should strive to avoid the
necessity of ALG functions in NAT implementations. Since the same
issues apply to firewalls, application designers have added incentive
to consider these recommendations.
Applications which work in such fashion as to not need ALG support
will be much easier to deploy, and have the greatest chance of
operation on a broad spectrum of NAT implementations.
Each of the areas called out below are examples of issues to consider
when building an application. This list is likely not comprehensive,
but does cover a number of important issues and considerations.
3.1 Avoid Session Bundles
Independent sessions, such as used by HTTP, are preferred to
protocols which attept to manage a bundle of related sessions,
such as FTP.
In the FTP protocol, port information is passed over one TCP
connection and is used to construct a second TCP connection for
passing the actual data. While using a separate connection to pass
the files being transferred makes determination of the end of data
quite simple, other schemes could be envisioned.
The HTTP protocol, for example, uses a header and content length
approach to passing data. In this model, all data is transferred
over the single TCP connection, with the header portion indicating
the length of the data to follow. HTTP has evolved to allow
multiple objects to be passed on a single connection (thereby
cutting the connection establishment overhead). Clearly a new file
transfer function could be built that would perform most of the
functions of FTP without the need for additional TCP connections.
It is clear that the lesson here is to keep to single connections
where possible. This keeps us from needing to pass addressing
information of any sort across the network. Since addressing
issues are limited to the establishment of the TCP session,
standard NAT functionality is sufficient.
Senie [Page 3]
Internet-Draft NAT Friendly Application Design October 1998
3.2. Session Bundles Originate From Same End
Origination of connections is an important consideration. Where
possible, the client should originate all connections. The FTP
protocol is the most obvious example, where by default the server
opens the data connection to a port on the client (the client
having specified the port number via a PORT command over the
control TCP session).
As pointed out in [Bellovin], the use of the passive open option
in FTP (PASV) remedies this situation as the client is responsible
for opening the connection in this case. With client-opened
connections, the standard functions of NAPT will process the
request as it would any other simple TCP connection, and so an ALG
is not required.
In cases where session bundles are unavoidable, each session in
the bundle should originate from the same end station.
3.3. Use DNS Names, Not IP Addresses In Payload
Applications should take care to use fully-qualified domain names,
rather than IP addresses when referring to IP endpoints. When
endpoints are across a NAT gateway, private addresses must not be
allowed to leak to the other endpoint. An example of where this
can happen today is with the HTTP and HTML protocols. It is
possible for web pages to be specified with numeric IP addresses,
rather than with names, for example http://192.168.1.10/index.html
could be used as a URL, but would likely create a problem if this
address is on a server located behind a NAT gateway. Users outside
the gateway would not be able to reach the address 192.168.1.10,
and so would not see the page.
3.4. Use IP and TCP/UDP Headers Alone
Applications which use only the information in the IP and TCP or
UDP headers for communication (in other words, do not pass any
additional addressing information in the payload of the packets),
are clearly easier to support in a NAT environment. Where
possible, applications designers should try to limit themselves in
this area.
The X windowing system, for example, uses fixed port numbers to
address X servers. With X, the server (display) is addressed via
ports 6000 through 6000 + n. These map to hostname:0 through
hostname:n server displays. Since only the address and port are
used, the NAT administrator could map these ports to one or more
private addresses, yielding a functioning solution.
Senie [Page 4]
Internet-Draft NAT Friendly Application Design October 1998
The X example requires configuration of the NAT implementation,
and so is at least somewhat problematic for the small office or
home NAT implementation, but it can be made to operate.
3.5. TCP preferred over UDP
NAT implementations must track which sessions are alive, and flush
old sessions. TCP has clear advantages in this area, since there
are specific beginning and end of session indicators in the
packets (SYN and FIN packets). While UDP works for some types of
applications with NAT, there can be issues when that data is
infrequent. Since there is no clean way to know when an end
station has finished using a UDP session, NAT implementations use
timeouts to guess when a UDP session completes. If an application
doesn't send data for a long period of time, the NAT translation
may time out.
3.6. Single Sessions Preferred Over Multiple Sessions
Resource utilization on the NAT gateway should be considered. An
application which opens and closes many TCP connections, for
example, will use up more resources on the NAT router than a
similar application which performs all transfers over a single TCP
connection. HTTP 1.0 opened a connection for each object on a web
page, whereas HTTP 1.1 permits the TCP session to be held open for
additional objects which may need to be transferred. Clearly the
latter imposes a lower overhead on the NAT gateway, as it is only
maintaining state on a single connection instead of multiple
connections.
The quanity of computing resources required to handle new session
establishment is much higher than the ongoing cost of performing
the translations. Indeed, once the associations are set up for a
given session, the actual translation component could be
implemented in a hardware forwarding engine.
3.7. Applications Requiring End-to-End IPSec Will Fail
Use of IPSec for end to end security will not function in the
presence of a NAT implementation. Application designers may want
to explore the use of TLS as a mechanism which will traverse NAT
cleanly. See [Srisuresh2] for additional discussion of the
interaction of NAT with security mechanisms.
3.8. Multicast Or Broadcast Service Location Problematic
The use of multicast or broadcast packets for service location
will cause some difficulty in conjunction with NAT. Some issues
Senie [Page 5]
Internet-Draft NAT Friendly Application Design October 1998
exist when such services are used with routers without NAT as
well. In some cases helper functions in routers perform a relay of
these broadcasts. In effect, these are a type of ALG function.
While NAT attached networks can appear like a single end station
(PAT case), devices behind a NAT system are in essence behind a
router.
3.9. Address Bindings Not Guaranteed
Applications should not assume bindings will be maintained from
one session to another. An example of this is RSVP, which forms
one connection to reserve the resources, then the actual session
for which resources were reserved is started. The sessions do not
necessarily overlap. There is no guarantee that the NAT
implementation will keep the binding association. As such,
applications which rely on subsequent sessions being mapped to the
same destination system may not function without an ALG.
4. Security Considerations
NAT has implications for IPSec, which are covered in other documents.
When application developers are considering whether their
applications function with NAT implementations, care should be given
to selection of security methodology. Transport Layer Security (TLS)
[TLS REFERENCE HERE] operates across translation boundaries. IPSec
will prove problematic in many cases. As such, where possible TLS
should be the preferred security scheme.
5. References
[Srisuresh1] P. Srisuresh, M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations," <draft-ietf-nat-
terminology-00.txt> - Work In Progress.
[Holdrege] M. Holdrege, P. Srisuresh, "IP Network Address Translator
(NAT) Protocol Issues," <draft-ietf-nat-protocol-issues-00.txt> -
Work In Progress.
[Hain] T. Hain, "Architectural Implications of NAT," <draft-iab-nat-
implications-01.txt> - Work In Progress.
[Rekhter] Y. Rekhter, "Implications of NATs on the TCP/IP
architecture," <draft-ietf-nat-arch-implications-00.txt> - Work In
Progress.
[Bellovin] S. Bellovin, "Firewall Friendly FTP," RFC 1579, February
Senie [Page 6]
Internet-Draft NAT Friendly Application Design October 1998
1994.
[Srisuresh2] P. Srisuresh, "Security for IP Network Address
Translator (NAT) Domains," <draft-ietf-nat-security-00.txt> - Work In
Progress.
6. Acknowledgements
I'd like to thank Pyda Srisuresh of Lucent Technologies for his
invaluable feedback on early versions of this draft.
7. Author's Address
Daniel Senie
Amaranth Networks Inc.
324 Still River Road
Bolton, MA 01740
Phone: (978) 779-6813
EMail: dts@senie.com
Senie [Page 7]
