rfc3027.txt

RFC3027:Protocol Complications with the IP Network Address Translator

Network Working Group                                        M. Holdrege
Request for Comments: 3027                                       ipVerse
Category: Informational                                     P. Srisuresh
                                                        Jasmine Networks
                                                            January 2001


     Protocol Complications with the IP Network Address Translator

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   Many internet applications can be adversely affected when end nodes
   are not in the same address realm and seek the assistance of an IP
   Network Address Translator (NAT) enroute to bridge the realms.  The
   NAT device alone cannot provide the necessary application/protocol
   transparency in all cases and seeks the assistance of Application
   Level Gateways (ALGs) where possible, to provide transparency.  The
   purpose of this document is to identify the protocols and
   applications that break with NAT enroute.  The document also attempts
   to identify any known workarounds.  It is not possible to capture all
   applications that break with NAT in a single document.  This document
   attempts to capture as much information as possible, but is by no
   means a comprehensive coverage.  We hope the coverage provides
   sufficient clues for applications not covered.

Table of Contents

   1.0 Introduction ..............................................  2
   2.0 Common Characteristics of Protocols broken by NAT .........  2
   3.0 Protocols that cannot work with NAT enroute ...............  4
   4.0 Protocols that can work with the aid of an ALG ............  8
   5.0 Protocols designed explicitly to work with NAT enroute .... 16
   6.0 Acknowledgements .......................................... 17
   7.0 Security Considerations ................................... 17
   8.0 References ................................................ 17
   9.0 Authors' Addresses ........................................ 19
   10.0 Full Copyright Statement  ................................ 20




Holdrege & Srisuresh         Informational                      [Page 1]

RFC 3027            Protocol Complications with NAT         January 2001


1.0 Introduction

   This document requires the reader to be familiar with the terminology
   and function of NAT devices as described in [NAT-TERM].  In a
   nutshell, NAT attempts to provide a transparent routing solution to
   end hosts requiring communication to disparate address realms.  NAT
   modifies end node addresses (within the IP header of a packet) en-
   route and maintains state for these updates so that datagrams
   pertaining to a session are transparently routed to the right end-
   node in either realm.  Where possible, application specific ALGs may
   be used in conjunction with NAT to provide application level
   transparency.  Unlike NAT, the function of ALG is application
   specific and would likely require examination and recomposition of IP
   payload.

   The following sections attempt to list applications that are known to
   have been impacted by NAT devices enroute.  However, this is by no
   means a comprehensive list of all known protocols and applications
   that have complications with NAT - rather just a subset of the list
   gathered by the authors.  It is also important to note that this
   document is not intended to advocate NAT, but rather to point out the
   complications with protocols and applications when NAT devices are
   enroute.

2.0 Common Characteristics of Protocols broken by NAT

   [NAT-TERM] and [NAT-TRAD] have sections listing the specific nature
   of problems and limitations to NAT devices.  Some of these
   limitations are being restated in this section to summarize
   characteristics of protocols that are broken by NAT.

2.1 Realm-specific IP address information in payload

   A wide range of applications fail with NAT enroute when IP packets
   contain realm-specific IP address or port information in payload.  An
   ALG may be able to provide work around in some cases.  But, if the
   packet payload is IPsec secured (or secure by a transport or
   application level security mechanisms), the application is bound to
   fail.

2.2 Bundled session applications

   Bundled session applications such as FTP, H.323, SIP and RTSP, which
   use a control connection to establish a data flow are also usually
   broken by NAT devices enroute.  This is because these applications
   exchange address and port parameters within control session to
   establish data sessions and session orientations.  NAT cannot know
   the inter-dependency of the bundled sessions and would treat each



Holdrege & Srisuresh         Informational                      [Page 2]

RFC 3027            Protocol Complications with NAT         January 2001


   session to be unrelated to one another.  Applications in this case
   can fail for a variety of reasons.  Two most likely reasons for
   failures are:  (a) addressing information in control payload is
   realm-specific and is not valid once packet crosses the originating
   realm, (b) control session permits data session(s) to originate in a
   direction that NAT might not permit.

   When DNS names are used in control payload, NAT device in conjunction
   with a DNS-ALG might be able to offer the necessary application level
   transparency, if NAT has no contention with data session orientation.
   However, using DNS names in place of realm-specific IP addresses may
   not be an option to many of these applications (e.g., FTP).

   When realm-specific addressing is specified in payload, and the
   payload is not encrypted, an ALG may in some cases be able to provide
   the work around necessary to make the applications run transparently
   across realms.  The complexity of ALG depends on the application
   level knowledge required to process payload and maintain state.

2.3 Peer-to-peer applications

   Peer-to-peer applications more than client-server based applications
   are likely to break with NAT enroute.  Unlike Client-server
   applications, Peer-to-peer applications can be originated by any of
   the peers.  When peers are distributed across private and public
   realms, a session originated from an external realm is just as likely
   as the session from  a host in private realm.  External peers will be
   able to locate their peers in private realm only when they know the
   externally assigned IP address or the FQDN ahead of time.  FQDN name
   to assigned address mapping can happen only so long as the enroute
   NAT device supports DNS-ALG.  Examples of Peer-to-peer applications
   include interactive games, Internet telephony and event-based
   protocols (such as Instant-Messaging).

   This is particularly a problem with traditional NAT and may be less
   of an issue with bi-directional NAT, where sessions are permitted in
   both directions.

   A possible work-around for this type of problem with traditional-NAT
   is for private hosts to maintain an outbound connection with a server
   acting as their representative to the globally routed Internet.

2.4 IP fragmentation with NAPT enroute

   IP fragmentation with NAPT enroute is not an issue with any single
   application, but pervades across all TCP/UDP applications.  The
   problem is described in detail in [NAT-TRAD].  Briefly, the problem
   goes as follows.  Say, two private hosts originated fragmented



Holdrege & Srisuresh         Informational                      [Page 3]

RFC 3027            Protocol Complications with NAT         January 2001


   TCP/UDP packets to the same destination host.  And, they happened to
   use the same fragmentation identifier.  When the target host receives
   the two unrelated datagrams, carrying same fragmentation id, and from
   the same assigned host address, the target host is unable to
   determine which of the two sessions the datagrams belong to.
   Consequently, both sessions will be corrupted.

2.5 Applications requiring retention of address mapping

   NAT will most likely break applications that require address mapping
   to be retained across contiguous sessions.  These applications
   require the private-to-external address mapping to be retained
   between sessions so the same external address may be reused for
   subsequent session interactions.  NAT cannot know this requirement
   and may reassign external address to different hosts between
   sessions.

   Trying to keep NAT from discarding an address mapping would require a
   NAT extension protocol to the application that would allow the
   application to inform the NAT device to retain the mappings.
   Alternately, an ALG may be required to interact with NAT to keep the
   address mapping from being discarded by NAT.

2.6 Applications requiring more public addresses than available

   This is a problem when the number of private hosts is larger than the
   external addresses available to map the private addresses into.  Take
   for example the rlogin service initiated from a host in private realm
   supported by NAPT.  Rlogin service clients use well-known rlogin port
   512 as their TCP port ID.  No more than one host in private realm can
   initiate the service.  This is a case of trying to use a service that
   fundamentally requires more public addresses than are available.  NAT
   devices can conserve addresses, but they cannot create more
   addresses.

3.0 Protocols that cannot work with NAT enroute

3.1 IPsec and IKE

   NAT fundamentally operates by modifying end node addresses (within
   the IP header) en-route.  The IPsec AH standard [IPsec-AH] on the
   other hand is explicitly designed to detect alterations to IP packet
   header.  So when NAT alters the address information enroute in IP
   header, the destination host receiving the altered packet will
   invalidate the packet since the contents of the headers have been
   altered.  The IPsec AH secure packet traversing NAT will simply not
   reach the target application, as a result.




Holdrege & Srisuresh         Informational                      [Page 4]

RFC 3027            Protocol Complications with NAT         January 2001


   IPsec ESP ([IPsec-ESP]) encrypted packets may be altered by NAT
   device enroute only in a limited number of cases.  In the case of
   TCP/UDP packets, NAT would need to update the checksum in TCP/UDP
   headers, when an address in IP header is changed.  However, as the
   TCP/UDP header is encrypted by the ESP, NAT would not be able to make
   this checksum update.  As a result, TCP/UDP packets encrypted in
   transport mode ESP, traversing a NAT device will fail the TCP/UDP
   checksum validation on the receiving end and will simply not reach
   the target application.

   Internet Key Exchange Protocol IKE can potentially pass IP addresses
   as node identifiers during Main, Aggressive and Quick Modes.  In
   order for an IKE negotiation to correctly pass through a NAT, these
   payloads would need to be modified.  However, these payloads are
   often protected by hash or obscured by encryption.  Even in the case
   where IP addresses are not used in IKE payloads and an IKE
   negotiation could occur uninterrupted, there is difficulty with
   retaining the private-to-external address mapping on NAT from the
   time IKE completed negotiation to the time IPsec uses the key on an
   application.  In the end, the use of end-to-end IPsec is severely
   hampered anyway, as described earlier.

   For all practical purposes, end-to-end IPsec is impossible to
   accomplish with NAT enroute.

3.2 Kerberos 4

   Kerberos 4 tickets are encrypted.  Therefore, an ALG cannot be
   written.  When the KDC receives a ticket request, it includes the
   source IP address in the returned ticket.  Not all Kerberos 4
   services actually check source IP addresses.  AFS is a good example
   of a Kerberos 4 service which does not.  Services which don't check
   are not picky about NAT devices enroute.  Kerberos tickets are tied
   to the IP address that requested the ticket and the service with
   which to use the ticket.

   The K4 ticket (response) contains a single IP address describing the
   interface used by the  client to retrieve the ticket from the TGT
   from the perspective of KDC.  This works fine if the KDC is across a
   NAT gateway and as long as all of the Kerberos services are also
   across a NAT gateway.  The end user on private network will not
   notice any problems.

   There is also the caveat that NAT uses the same address mapping for
   the private host for the connection between the client and the KDC as
   for the connection between the client and the application server.  A
   work around this problem would be to keep an arbitrary connection
   open to remote server during throughout the ticket lifetime, so as