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

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

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

               NAT Friendly Application Design Guidelines
                      draft-ietf-nat-app-guide-04.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."

   To view the list Internet-Draft Shadow Directories, see
   http://www.ietf.org/shadow.html.

Copyright Notice

   Copyright (C) The Internet Society (1999-2001). 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 [RFC2663] and Protocol
   Issues [RFC3027] or discuss the preceived implications of NAT
   [RFC2993]. 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       February 2001


   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       February 2001


   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, especially in smaller offices
      and home offices.

    3.1.1 Realm Specific IP Addresses

      Avoid the use of IP address and port number information within the
      payload of packets. While in some cases ALGs will permit such
      protocols to function, this presupposes every NAT device can be
      updated in a timely fashion to support a new protocol. Since this
      is unlikely application writers are urged to avoid addressing
      information in payloads all together.

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




Senie                                                           [Page 3]





Internet-Draft       NAT Friendly Application Design       February 2001


      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.

      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.3. 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 [RFC1579], 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.4. 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



Senie                                                           [Page 4]





Internet-Draft       NAT Friendly Application Design       February 2001


      UDP should be discouraged.

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

    3.1.6. IP Fragmentation

      Applications should attempt to avoid fragmentation when packets
      pass over NAPT devices. While not always practical or possible,
      there are failures which can occur with NAPT. Specifically, if two
      stations in the private realm pick matching fragmentation
      identifiers, and talk to the same remote host, it will be
      impossible to determine which fragments belong to which session.

      Ideally, applications should limit packet size, use Path MTU
      Discovery or both.

    3.2 Issues and recommendations for Basic 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.




Senie                                                           [Page 5]





Internet-Draft       NAT Friendly Application Design       February 2001


      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.2.2. Avoid Addressing In Payload

      As with NAPT, transporting IP address and/or port number
      information in the payload is likely to cause trouble. The IP
      address and/or port information valid in the realm on one side of
      a NAT may well be invalid or even refer to different resources on
      the other side of a NAT gateway.

    3.3 Bidirectional NAT

      Bidirectional NAT makes use of DNS mapping of names to point
      sessions originating outside the private realm to servers in the
      private realm.  Through use of a DNS-ALG, lookups are performed to
      find the proper host and packets are sent to that host.

      Requirements for applications are the same as for Basic NAT.
      Addresses are mapped one-to-one to servers.

    3.4 Twice NAT

      Twice NAT is address translation where both source and destination
      IP addresses are modified due to addressing conflicts between two
      private realms. Two bidirectional NAT boxes connected together
      would essentially perform the same task, though a common address
      space which is not otherwise used by either private realm would be
      required.

      Requirements for applications to work in the Twice NAT environment
      are the same as for Basic NAT. Addresses are mapped one to one.

    3.5 Multihomed NAT

      Multihomed NAT is the use of multiple NAT implementations to
      provide redundancy. The multiple implementations share
      configuration information so that sessions might continue in the
      event of a failover. Unless the multiple implementations share the
      same external addresses, sessions will have to restart regardless.

      Requirements for multihomed NAT are the same as for Basic NAT or
      NAPT, depending on how the multihomed NAT is implemented and
      configured.




Senie                                                           [Page 6]





Internet-Draft       NAT Friendly Application Design       February 2001


    3.6 Realm Specific IP (RSIP)

      Realm Specific IP is described in [RFC2663] and defined in [RSIP]
      and related documents.  Clients within a private realm using RSIP
      are aware of the delineation between private and public, and
      access a server to allocate address (and optionally port)
      information for use in conversing with hosts in the public realm.
      By doing this, clients create packets which need not be altered by
      the RSIP server on their way to the remote host. This technique
      can permit IPSec to function, and potentially makes any
      application function as if there were no special processing
      involved at all.

    3.7 Issues and Recommendations affecting all types of Network
      Address Translators

    3.7.1. Peer to Peer Applications Unworkable

      Peer to peer applications are problematic in a NAT world. Client-
      server applications are more generally workable. Peer-to-peer
      applications rely on each peer being reachable as a server for the
      other to connect to. With NAPT, there are likely many machines
      behind one address. With other types of NAT such as one-to-one
      mappings, there is a greater chance of making such applications
      work.


    3.7.2. 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 [RFC2709] 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.

      Vendors of IPSec technologies are implementing and deploying
      solutions which encapsulate the IPSec packets in UDP or TCP
      packets, thereby providing a packet format which can traverse a
      Network Address Translation, and which can pass muster with IPSec
      validity checks.

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



Senie                                                           [Page 7]





Internet-Draft       NAT Friendly Application Design       February 2001


      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.7.4. 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.7.5. Retention Of Address Mapping

      Applications which expect addresses of end stations to remain
      invariate tend to get into trouble. With various types of NAT
      there is a real chance connections from the same workstation will
      egress a private realm on separate IP addresses. Devices exist in
      the market which use this as a way to load-balance NAT across
      multiple connections to the Internet, for example.

    3.8 Performance Implications of Address Translation 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



Senie                                                           [Page 8]





Internet-Draft       NAT Friendly Application Design       February 2001


      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.

      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. This function can be
      implemented efficiently in hardware or software.

4. Security Considerations


   Network Address Translators have implications for IPSec, as noted
   above.  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)
   [RFC2246] operates across translation boundaries. IPSec will prove
   problematic in many cases.

   IPSec packets can be encapsulated in other packet types to allow
   operation over address translation topologies. The use of TLS should
   also be considered where it is appropriate and sufficient for an
   application.

5. References

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

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



Senie                                                           [Page 9]





Internet-Draft       NAT Friendly Application Design       February 2001


   [RFC2993] T. Hain, "Architectural Implications of NAT," RFC 2993,
   November 2000.

   [RFC3027] M. Holdrege, P. Srisuresh, "Protocol Complications with the
   IP Network Address Translator (NAT)," RFC 3027, January 2001.

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

   [RFC2709] P. Srisuresh, "Security Model with Tunnel-mode IPsec for
   NAT Domains," RFC 2709, October 1999.

   [RSIP] M. Borella, et. al., "Realm Specific IP: Framework," <draft-
   ietf-nat-rsip-framework-05.txt> - Work In Progress.

6. Acknowledgements

   I'd like to thank Pyda Srisuresh for his invaluable feedback.

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 10]