One document matched: draft-ietf-nat-app-guide-02.txt

Differences from draft-ietf-nat-app-guide-01.txt

NAT Working Group                                               D. Senie
INTERNET-DRAFT                                    Amaranth Networks Inc.
Category: Informational                                   September 1999
Expires in six months

               NAT Friendly Application Design Guidelines
                    
                     draft-ietf-nat-app-guide-02.txt



Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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.

Copyright Notice

   Copyright (C) The Internet Society (1999). 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]. 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 is not
   required at NAT gateway points.

Senie                                                           [Page 1]

Internet-Draft       NAT Friendly Application Design      September 1999

   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 Traditional 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.

   Application designers should ensure compatability with NAPT, as this

Senie                                                           [Page 2]

Internet-Draft       NAT Friendly Application Design      September 1999

   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 Recommendations for NAPT

      As many of the issues specifically address NAPT issues, this
      section will group these issues. NAPT is the most common form of
      NAT in actual deployment in routers and host software, especially
      in smaller offices and home offices.

    3.1.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.

Senie                                                           [Page 3]

Internet-Draft       NAT Friendly Application Design      September 1999

      The goal is to keep to single connections where possible. This
      keeps us from needing to pass addressing information of any sort
      across the network.

    3.1.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.1.3. TCP preferred over UDP

      NAPT gateways 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.

      Protocols other than TCP and UDP are workable with simple NAT in
      many cases, provided they are not carrying addressing information.
      For NAPT implementations Use of any protocols other than TCP and
      UDP should be discouraged.

    3.1.4. 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

Senie                                                           [Page 4]

Internet-Draft       NAT Friendly Application Design      September 1999

      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.

    3.2 Issues and recommendations for NAT

      If only Basic NAT implementations are involved, not NAPT, then
      many of the issues above do not apply. This form of NAT is not a
      panacea. In this case many of the issues still remain, and many
      protocols will not function correctly without assistance.

    3.2.1. 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.

      The X example, in the case of NAPT, requires configuration of the
      NAT implementation. This results in the ability for no more than
      one station inside the NAT gateway to use such a protocol. This
      approach to the problem is thus OK for NAT but not recommended for
      NAPT environments.

    3.3 Issues and Recommendations affecting both NAT and NAPT

    3.3.1. 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.

      Future work is under consideration which could offer compatability
      between NAT and IPSec, but is outside the scope of this document.

    3.3.2. Use DNS Names, Not IP Addresses In Payload

Senie                                                           [Page 5]

Internet-Draft       NAT Friendly Application Design      September 1999

      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.

      Further exacerbating the problem is the possibility of duplicate
      addresses between realms. If a server offers a link with a private
      address space IP address embedded within it, such as 192.168.1.10,
      the page referenced may resolve to a system on the local network
      the browser is on, but would be a completely different server. The
      resulting confusion to end users would be significant. Sessions
      involving multiple NAT implementations would be exceptionally
      vulnerable to address reuse issues of this sort.

    3.3.3. 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
      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.

      In the NAPT case, attached networks can appear like a single end
      stations.  Devices behind a NAPT system are in essence behind a
      router, though the rules of forwarding are not the same as a
      router.

    3.4 Performance Implications of NAT and NAPT Implementations

      In general, single sessions are preferred Over multiple sessions.
      In NAPT implementations, 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.

Senie                                                           [Page 6]

Internet-Draft       NAT Friendly Application Design      September 1999

      New session establishment will typically remain a software
      function even in implementations where the packet-by-packet
      translation work is handled by hardware forwarding engines. While
      high-performance NAT boxes may be built, protocols which open many
      sessions instead of multiplexing will be slower than those which
      do not.

      Applications with different types of data, such as interactive
      conferencing, require separate streams for the different types of
      data.  In such cases the protocol needs of each stream must be
      optimized. While the goal of multiplexing over a single session is
      preferred, clearly there are cases where this is impractical.

      Basic NAT implementations have fairly low overhead in the gateway.
      The latency of this overhead is implementation dependent. With
      Basic NAT, only the source and destination IP addresses are
      replaced, and the checksum recalculated.

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)
   [Dierks] operates across translation boundaries. IPSec will prove
   problematic in many cases. As such, where possible TLS should be the
   preferred security scheme.

5. References

   [Bellovin] S. Bellovin, "Firewall Friendly FTP," RFC 1579, February
   1994.

   [Dierks] T. Dierks, C. Allen, "The TLS Protocol Version 1.0," RFC
   2246, January 1999.

   [Hain] T. Hain, "Architectural Implications of NAT," <draft-iab-nat-
   implications-04.txt> - Work In Progress.

   [Holdrege] M. Holdrege, P. Srisuresh, "Protocol Complications with
   the IP Network Address Translator (NAT)," <draft-ietf-nat-protocol-
   complications-01.txt> - Work In Progress.

   [Srisuresh1] P. Srisuresh, M. Holdrege, "IP Network Address
   Translator (NAT) Terminology and Considerations," RFC 2663, August
   1999.

Senie                                                           [Page 7]

Internet-Draft       NAT Friendly Application Design      September 1999

   [Srisuresh2] P. Srisuresh, "Security Model with Tunnel-mode IPset for
   NAT Domains," <draft-ietf-nat-security-02.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 8]