doc: Add RFC documents

1 files changed, 1123 insertions, 0 deletions

diff --git a/doc/rfc/rfc3027.txt b/doc/rfc/rfc3027.txt
new file mode 100644
index 0000000..e0f5772
--- /dev/null
+++ b/doc/rfc/rfc3027.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+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
+
+
+
+Holdrege & Srisuresh         Informational                      [Page 5]
+
+RFC 3027            Protocol Complications with NAT         January 2001
+
+
+   not to let NAT drop the address binding.  Alternately, an ALG will
+   need to be deployed to ensure that NAT would not change address
+   bindings during the lifetime of a ticket and between the time a
+   ticket is issued to private host and the time the ticket is used by
+   private host.
+
+   But, the ticket will be valid from any host within the private realm
+   of NAPT.  Without NAPT, an attacker needs to be able to spoof the
+   source IP addresses of a connection that is being made in order to
+   use a stolen ticket on a different host.  With NAPT, all the attacker
+   needs to do from the private realm of NAPT is to simply gain
+   possession of a ticket.  Of course, this assumes, NAPT private domain
+   is not a trusted network - not surprisingly, since many attacks occur
+   from inside the organization.
+
+3.3 Kerberos 5
+
+   Just as with Kerberos 4, Kerberos 5 tickets are encrypted.
+   Therefore, an ALG cannot be written.
+
+   In Kerberos 5, the client specifies a list of IP addresses which the
+   ticket should be valid for, or it can ask for a ticket valid for all
+   IP addresses.  By asking for an all-IP-addresses ticket or a ticket
+   containing the NAPT device address, you can get krb5 to work with an
+   NAPT device, although it isn't very transparent (it requires the
+   clients to behave differently than they otherwise would).  The MIT
+   krb5 1.0 implementation didn't have any configurability for what IP
+   addresses the client asked for (it always asked for the set of its
+   interface addresses) and did not interact well with NAT.  The MIT
+   krb5 1.1 implementation allows you to put "noaddresses" somewhere in
+   krb5.conf to request all-IP-addresses-valid tickets.
+
+   The K5 ticket (response) contains IP addresses, as requested by the
+   client node, from which the ticket is to be considered valid.  If the
+   services being accessed with Kerberos authentication are on the
+   public side of the NAT, then the Kerberos authentication will fail
+   because the IP address used by the NAT (basic NAT or NAPT) is not in
+   the list of acceptable addresses.
+
+   There are two workarounds in Kerberos 5 both of which reduce the
+   security of the tickets.  The first is to have the clients in NAPT
+   private realm specify the public IP address of the NAPT in the
+   ticket's IP list.  But this leads to the same security problem
+   detailed for K4.  Plus, it is not obvious for the client in the
+   private domain to find out the public IP Address of the NAPT.  That
+   would be a change of application behavior on end-host.
+
+
+
+
+
+Holdrege & Srisuresh         Informational                      [Page 6]
+
+RFC 3027            Protocol Complications with NAT         January 2001
+
+
+   The second method is to remove all IP addresses from the K5 tickets
+   but this now makes theft of the ticket even worse since the tickets
+   can be used from anywhere.  Not just from within the private network.
+
+3.4 The X Windowing System and X-term/Telnet
+
+   The X Windowing system is TCP based.  However, the client-server
+   relationship with these applications is reverse compared to most
+   other applications.  The X server or Open-windows server is the
+   display/mouse/keyboard unit (i.e., the one that controls the actual
+   Windows interface).  The clients are the application programs driving
+   the Windows interface.
+
+   Some machines run multiple X Windows servers on the same machine.
+   The first X Windows server is at TCP port 6000.  The first Open
+   Windows server can be at port 6000 or port 2000 (more flexible).  We
+   will mainly refer X windowing system for illustration purposes here.
+
+   X-term Transmits IP addresses from the client to the server for the
+   purpose of setting the DISPLAY variable.  When set the DISPLAY
+   variable is used for subsequent connections from X clients on the
+   host to an X server on the workstation.  The DISPLAY variable is sent
+   inline during the TELNET negotiations as
+
+     DISPLAY=<local-ip-addr>:<server>.<display>
+
+   where the <local-ip-addr> is retrieved by looking at the local ip
+   address associated with the socket used to connect to <server>.  The
+   <server> determines which port (6000 + <server>) should be used to
+   make the connection.  <display> is used to indicate which monitor
+   attached to the X server should be used but is not important to this
+   discussion.
+
+   The <local-ip-addr> used is not a DNS name because:
+
+    . The is no ability for the local machine to know its DNS name
+      without performing a reverse DNS lookup on the local-ip-addr
+
+    . There is no guarantee that the name returned by a reverse
+      DNS lookup actually maps back to the local IP address.
+
+    . Lastly, without DNSSEC, it may not be safe to use DNS addresses
+      because they can easily be spoofed.  NAT and DNS-ALG cannot work
+      unless DNSSEC is disabled.
+
+   A common use of this application is people dialing in to corporate
+   offices from their X terminals at home.  Say, the X client is running
+   on a host on the public side of the NAT and X server is running on a
+
+
+
+Holdrege & Srisuresh         Informational                      [Page 7]
+
+RFC 3027            Protocol Complications with NAT         January 2001
+
+
+   host on the private side of the NAT.  The DISPLAY variable is
+   transmitted inline to the host the X client is running in some way.
+   The process transmitting the contents of the DISPLAY variable does
+   not know the address of the NAT.
+
+   If the channel transmitting the DISPLAY variable is not encrypted,
+   NAT device might solicit the help of an ALG to replace the IP address
+   and configure a port in the valid display range (ports 6000 and
+   higher) to act as a gateway.  Alternately, NAT may be configured to
+   listen for incoming connections to provide access to the X Server(s),
+   without requiring an ALG.  But, this approach increases the security
+   risk by providing access to the X server that would not otherwise be
+   available.  As the ALG tampers with the IP addresses it will also not
+   be possible for X Authorization methods other than MIT-MAGIC-COOKIE-1
+   to be used.  MIT-MAGIC-COOKIE-1 is the least secure of all the
+   documented X Authorization methods.
+
+   When START_TLS is used there may be client certificate verification
+   problems caused by the NAT depending on the information provided in
+   the certificate.
+
+3.5 RSH/RLOGIN
+
+   RSH uses multiple sessions to support separate streams for stdout and
+   stderr.  A random port number is transmitted inline from the client
+   to the server for use as stderr port.  The stderr socket is a
+   connection back from the server to the client.  And unlike FTP, there
+   is no equivalent to PASV mode.  For traditional NAT, this is a
+   problem as traditional NAT would not permit incoming sessions.
+
+   RLOGIN does not use multiple sessions.  But the Kerberos protected
+   versions of RSH and RLOGIN will not work in a NAT environment due to
+   the ticket problems and the use of multiple sessions.
+
+4.0 Protocols that can work with the aid of an ALG
+
+   This document predominantly addresses problems associated with
+   Traditional NAT, especially NAPT.
+
+4.1 FTP
+
+   FTP is a TCP based application, used to reliably transfer files
+   between two hosts.  FTP uses bundled session approach to accomplish
+   this.
+
+   FTP is initiated by a client accessing a well-known port number 21 on
+   the FTP server.  This is called the FTP control session.  Often, an
+   additional data session accompanies the control session.  By default,
+
+
+
+Holdrege & Srisuresh         Informational                      [Page 8]
+
+RFC 3027            Protocol Complications with NAT         January 2001
+
+
+   the data session would be from TCP port 20 on server to the TCP port
+   client used to initiate control session.  However, the data session
+   ports may be altered within the FTP control sessions using ASCII
+   encoded PORT and PASV commands and responses.
+
+   Say, an FTP client is in a NAT supported private network.  An FTP ALG
+   will be required to monitor the FTP control session (for both PORT
+   and PASV modes) to identify the FTP data session port numbers and
+   modify the private address and port number with the externally valid
+   address and port number.  In addition, the sequence and
+   acknowledgement numbers, TCP checksum, IP packet length and checksum
+   have to be updated.  Consequently the sequence numbers in all
+   subsequent packets for that stream must be adjusted as well as TCP
+   ACK fields and checksums.
+
+   In rare cases, increasing the size of the packet could cause it to
+   exceed the MTU of a given transport link.  The packet would then have
+   to be fragmented which could affect performance.  Or, if the packet
+   has the DF bit set, it would be ICMP rejected and the originating
+   host would then have to perform Path MTU Discovery.  This could have
+   an adverse effect on performance.
+
+   Note however, if the control command channel is secured, it will be
+   impossible for an ALG to update the IP addresses in the command
+   exchange.
+
+   When AUTH is used with Kerberos 4, Kerberos 5, and TLS, the same
+   problems that occur with X-Term/Telnet occur with FTP.
+
+   Lastly, it is of interest to note section 4 of RFC 2428 (FTP
+   extensions for IPv6 and NATs) which describes how a new FTP port
+   command (EPSV ALL) can be used to allow NAT devices to fast-track the
+   FTP protocol, eliminating further processing through ALG, if the
+   remote server accepts "EPSV ALL".
+
+4.2 RSVP
+
+   RSVP is positioned in the protocol stack at the transport layer,
+   operating on top of IP (either IPv4 or IPv6).  However, unlike other
+   transport protocols, RSVP does not transport application data but
+   instead acts like other Internet control protocols (for example,
+   ICMP, IGMP, routing protocols).  RSVP messages are sent hop-by-hop
+   between RSVP-capable routers as raw IP datagrams using protocol
+   number 46.  It is intended that raw IP datagrams should be used
+   between the end systems and the first (or last) hop router.  However,
+   this may not always be possible as not all systems can do raw network
+   I/O.  Because of this, it is possible to encapsulate RSVP messages
+   within UDP datagrams for end-system communication.  UDP-encapsulated
+
+
+
+Holdrege & Srisuresh         Informational                      [Page 9]
+
+RFC 3027            Protocol Complications with NAT         January 2001
+
+
+   RSVP messages are sent to either port 1698 (if sent by an end system)
+   or port 1699 (if sent by an RSVP-enabled router).  For more
+   information concerning UDP encapsulation of RSVP messages; consult
+   Appendix C of RFC 2205.
+
+   An RSVP session, a data flow with a particular destination and
+   transport-layer protocol, is defined by:
+
+   Destination Address - the destination IP address for the data
+   packets.  This may be either a unicast or a multicast address.
+
+   Protocol ID - the IP protocol ID (for example, UDP or TCP).
+
+   Destination Port - a generalized destination port that is used for
+   demultiplexing at a layer above the IP layer.
+
+   NAT devices are presented with unique problems when it comes to
+   supporting RSVP.  Two issues are:
+
+   1. RSVP message objects may contain IP addresses.  The result is that
+   an RSVP-ALG must be able to replace the IP addresses based upon the
+   direction and type of the message.  For example, if an external
+   sender were to send an RSVP Path message to an internal receiver, the
+   RSVP session will specify the IP address that the external sender
+   believes is the IP address of the internal receiver.  However, when
+   the RSVP Path message reaches the NAT device, the RSVP session must
+   be changed to reflect the IP address that is used internally for the
+   receiver.  Similar actions must be taken for all message objects that
+   contain IP addresses.
+
+   2. RSVP provides a means, the RSVP Integrity object, to guarantee the
+   integrity of RSVP messages.  The problem is that because of the first
+   point, a NAT device must be able to change IP addresses within the
+   RSVP messages.  However, when this is done, the RSVP Integrity object
+   is no longer valid as the RSVP message has been changed.  Therefore
+   an RSVP-ALG will not work when RSVP Integrity Object is used.
+
+4.3 DNS
+
+   DNS is a TCP/UDP based protocol.  Domain Names are an issue for hosts
+   which use local DNS servers in NAT private realm.  DNS name to
+   address mapping for hosts in private domain should be configured on
+   an authoritative name server within private domain.  This server
+   would be accessed by external and internal hosts alike for name
+   resolutions.  A DNS-ALG would be required to perform address to name
+   conversions on DNS queries and responses.  [DNS-ALG] describes DNS-
+   ALG
+
+
+
+
+Holdrege & Srisuresh         Informational                     [Page 10]
+
+RFC 3027            Protocol Complications with NAT         January 2001
+
+
+   in detail.  If DNS packets are encrypted/authenticated per DNSSEC,
+   then DNS_ALG will fail because it won't be able to perform payload
+   modifications.
+
+   Applications using DNS resolver to resolve a DNS name into an IP
+   address, assume availability of address assignment for reuse by the
+   application specific session.  As a result, DNS-ALG will be required
+   to keep the address assignment (between private and external
+   addresses) valid for a pre-configured period of time, past the DNS
+   query.
+
+   Alternately, if there isn't a need for a name server within private
+   domain, private domain hosts could simply point to an external name
+   server for external name lookup.  No ALG is required when the name
+   server is located in external domain.
+
+4.4 SMTP
+
+   SMTP is a TCP based protocol ([SMTP]), used by Internet email
+   programs such as sendmail to send TCP-based email messages to well-
+   known port 25.  The mail server may be located within or outside
+   private domain.  But, the server must be assigned a global name and
+   address, accessible by external hosts.  When mail server is located
+   within private domain, inbound SMTP sessions must be redirected to
+   the private host from its externally assigned address.  No special
+   mapping is required when Mail server is located in external domain.
+
+   Generally speaking, mail systems are configured such that all users
+   specify a single centralized address (such as fooboo@company.com),
+   instead of including individual hosts (such as
+   fooboo@hostA.company.com).  The central address must have an MX
+   record specified in the DNS name server accessible by external hosts.
+
+   In the majority of cases, mail messages do not contain reference to
+   private IP addresses or links to content data via names that are not
+   visible to outside.  However, some mail messages do contain IP
+   addresses of the MTAs that relay the message in the "Received: "
+   field.  Some mail messages use IP addresses in place of FQDN for
+   debug purposes or due to lack of a DNS record, in "Mail From: "
+   field.
+
+   If one or more MTAs were to be located behind NAT in a private
+   domain, and the mail messages are not secured by signature or
+   cryptographic keys, an SMTP-ALG may be used to translate the IP
+   address information registered by the MTAs.  If the MTAs have static
+   address mapping, the translation would be valid across realms for
+   long periods of time.
+
+
+
+
+Holdrege & Srisuresh         Informational                     [Page 11]
+
+RFC 3027            Protocol Complications with NAT         January 2001
+
+
+   The ability to trace the mail route may be hampered or prevented by
+   NAT alone, without the ALG.  This can cause problems when debugging
+   mail problems or tracking down abusive users of mail.
+
+4.5 SIP
+
+   SIP (Refer [SIP]) can run on either TCP or UDP, but by default on the
+   same port 5060.
+
+   When used with UDP, a response to a SIP request does not go to the
+   source port the request came from.  Rather the SIP message contains
+   the port number the response should be sent to.  SIP makes use of
+   ICMP port unreachable errors in the response to request
+   transmissions.  Request messages are usually sent on the connected
+   socket.  If responses are sent to the source port in the request,
+   each thread handling a request would have to listen on the socket it
+   sent the request on.  However, by allowing responses to come to a
+   single port, a single thread can be used for listening instead.
+
+   A server may prefer to place the source port of each connected socket
+   in the message.  Then each thread can listen for responses
+   separately.  Since the port number for a response may not go to the
+   source port of the request, SIP will not normally traverse a NAT and
+   would require a SIP-ALG.
+
+   SIP messages carry arbitrary content, which is defined by a MIME
+   type.  For multimedia sessions, this is usually the Session
+   Description Protocol (SDP RFC 2327).  SDP may specify IP addresses or
+   ports to be used for the exchange of multimedia.  These may loose
+   significance when traversing a NAT.  Thus a SIP-ALG would need the
+   intelligence to decipher and translate realm-relevant information.
+
+   SIP carries URL's in its Contact, To and From fields that specify
+   signaling addresses.  These URL's can contain IP addresses or domain
+   names in the host port portion of the URL.  These may not be valid
+   once they traverse a NAT.
+
+   As an alternative to an SIP-ALG, SIP supports a proxy server which
+   could co-reside with NAT and function on the globally significant NAT
+   port.  Such a proxy would have a locally specific configuration.
+
+4.6 RealAudio
+
+   In default mode, RealAudio clients (say, in a private domain) access
+   TCP port 7070 to initiate conversation with a real-audio server (say,
+   located an external domain) and to exchange control messages during
+   playback (ex: pausing or stopping the audio stream).  Audio session
+   parameters are embedded in the TCP control session as byte stream.
+
+
+
+Holdrege & Srisuresh         Informational                     [Page 12]
+
+RFC 3027            Protocol Complications with NAT         January 2001
+
+
+   The actual audio traffic is carried in the opposite direction on
+   incoming UDP based packets (originated from the server) directed to
+   ports in the range of 6970-7170.
+
+   As a result, RealAudio is broken by default on a traditional NAT
+   device.  A work around for this would be for the ALG to examine the
+   TCP traffic to determine the audio session parameters and selectively
+   enable inbound UDP sessions for the ports agreed upon in the TCP
+   control session.  Alternately, the ALG could simply redirect all
+   inbound UDP sessions directed to ports 6970-7170 to the client
+   address in the private domain.
+
+   For bi-Directional NAT, you will not need an ALG.  Bi-directional NAT
+   could simply treat each of the TCP and UDP sessions as 2 unrelated
+   sessions and perform IP and TCP/UDP header level translations.
+
+   The readers may contact RealNetworks for detailed guidelines on how
+   their applications can be made to work, traversing through NAT and
+   firewall devices.
+
+4.7 H.323
+
+   H.323 is complex, uses dynamic ports, and includes multiple UDP
+   streams.  Here is a summary of the relevant issues:
+
+   An H.323 call is made up of many different simultaneous connections.
+   At least two of the connections are TCP.  For an audio-only
+   conference, there may be up to 4 different UDP 'connections' made.
+
+   All connections except one are made to ephemeral (dynamic) ports.
+
+   Calls can be initiated from the private as well as the external
+   domain.  For conferencing to be useful, external users need to be
+   able to establish calls directly with internal users' desktop
+   systems.
+
+   The addresses and port numbers are exchanged within the data stream
+   of the 'next higher' connection.  For example, the port number for
+   the H.245 connection is established within the Q.931 data stream.
+   (This makes it particularly difficult for the ALG, which will be
+   required to modify the addresses inside these data streams.)  To make
+   matters worse, it is possible in Q.931, for example, to specify that
+   the H.245 connection should be secure (encrypted).  If a session is
+   encrypted, it is impossible for the ALG to decipher the data stream,
+   unless it has access to the shared key.
+
+   Most of the control information is encoded in ASN.1 (only the User-
+   User Information within Q.931 Protocol Data Units, or PDUs, is
+
+
+
+Holdrege & Srisuresh         Informational                     [Page 13]
+
+RFC 3027            Protocol Complications with NAT         January 2001
+
+
+   ASN.1-encoded (other parts of each Q.931 PDU are not encoded).  For
+   those unfamiliar with ASN.1, suffice it to say that it is a complex
+   encoding scheme, which does not end up with fixed byte offsets for
+   address information.  In fact, the same version of the same
+   application connecting to the same destination may negotiate to
+   include different options, changing the byte offsets.
+
+   Below is the protocol exchange for a typical H.323 call between User
+   A and User B.  A's IP address is 88.88.88.88 and B's IP address is
+   99.99.99.99.  Note that the Q.931 and H.245 messages are encoded in
+   ASN.1 in the payload of an RTP packet.  So to accomplish a connection
+   through a NAT device, an H.323-ALG will be required to examine the
+   packet, decode the ASN.1, and translate the various H.323 control IP
+   addresses.
+
+   User A                                                  User B
+         A establishes connection to B on well-
+         known Q.931 port (1720)
+
+         ----------------------------------------------->
+         Q.931 Setup caller address = 88.88.88.88
+                     caller port    = 1120
+                     callee address = 99.99.99.99
+                     callee port    = 1720
+         <-----------------------------------------------
+         Q.931 Alerting
+         <-----------------------------------------------
+         Q.931 Connect H.245 address = 99.99.99.99
+                       H.245 port    = 1092
+
+         User A establishes connection to User B at
+         99.99.99.99, port 1092
+
+         <---------------------------------------------->
+         Several H.245 messages are exchanged (Terminal
+         Capability Set, Master Slave Determination and
+         their respective ACKs)
+
+         <-----------------------------------------------
+         H.245 Open Logical Channel, channel = 257
+                   RTCP address = 99.99.99.99
+                   RTCP port    = 1093
+         ----------------------------------------------->
+         H.245 Open Logical Channel Ack, channel = 257
+                   RTP address = 88.88.88.88
+                   RTP port    = 2002
+                   (This is where User A would like RTP
+                    data sent to)
+
+
+
+Holdrege & Srisuresh         Informational                     [Page 14]
+
+RFC 3027            Protocol Complications with NAT         January 2001
+
+
+                   RTCP address = 88.88.88.88
+                   RTCP port    = 2003
+         ----------------------------------------------->
+         H.245 Open Logical Channel, channel = 257
+                   RTCP address = 88.88.88.88
+                   RTCP port    = 2003
+         <-----------------------------------------------
+         H.245 Open Logical Channel Ack, channel = 257
+                   RTP address = 99.99.99.99
+                   RTP port    = 1092
+                   (This is where User B would like RTP data
+                    sent to)
+                   RTCP address = 99.99.99.99
+                   RTP port     = 1093
+
+   Also note that if an H.323 Gateway resided inside a NAT boundary, the
+   ALG would have to be cognizant of the various gateway discovery
+   schemes and adapt to those schemes as well.  Or if just the H.323
+   host/terminal was inside the NAT boundary and tried to register with
+   a Gatekeeper, the IP information in the registration messages would
+   have to be translated by NAT.
+
+4.8 SNMP
+
+   SNMP is a network management protocol based on UDP.  SNMP payload may
+   contain IP addresses or may refer IP addresses through an index into
+   a table.  As a result, when devices within a private network are
+   managed by an external node, SNMP packets transiting a NAT device may
+   contain information that is not relevant in external domain.  In some
+   cases, as described in [SNMP-ALG], an SNMP ALG may be used to
+   transparently convert realm-specific addresses into globally unique
+   addresses.  Such an ALG assumes static address mapping and bi-
+   directional NAT.  It can only work for the set of data types (textual
+   conventions) understood by the SNMP-ALG implementation and for a
+   given set of MIB modules.  Furthermore, replacing IP addresses in the
+   SNMP payload may lead to communication failures due to changes in
+   message size or changes in the lexicographic ordering.
+
+   Making SNMP ALGs completely transparent to all management
+   applications is not an achievable task.  The ALGs will run into
+   problems with SNMPv3 security features, when authentication (and
+   optionally privacy) is enabled, unless the ALG has access to security
+   keys.  [NAT-ARCH] also hints at potential issues with SNMP management
+   via NAT.
+
+   Alternately,  SNMP proxies, as defined in [SNMP-APPL], may be used in
+   conjunction with NAT to forward SNMP messages to external SNMP
+   engines (and vice versa).  SNMP proxies are tailored to the private
+
+
+
+Holdrege & Srisuresh         Informational                     [Page 15]
+
+RFC 3027            Protocol Complications with NAT         January 2001
+
+
+   domain context and can hence operate independent of the specific
+   managed object types being accessed.  The proxy solution will require
+   the external management application to be aware of the proxy
+   forwarder and the individual nodes being managed will need to be
+   configured to direct their SNMP traffic (notifications and requests)
+   to the proxy forwarder.
+
+5.0 Protocols designed explicitly to work with NAT enroute
+
+5.1 Activision Games
+
+   Activision Games were designed to be NAT-friendly so as not to
+   require an ALG for the games to work transparently through
+   traditional NAT devices.  Game players within a private domain can
+   play with other players in the same domain or external domain.
+   Activision gaming protocol is proprietary and is based on UDP.  The
+   address server uses UDP port number 21157 and is expected to be
+   located in the global address realm.
+
+   Game players connect to the address server first, and send their
+   private IP address information (such as private IP address and UDP
+   port number) in the initial connect message.  The server notes
+   private address information from the connect message and external
+   address information from the IP and UDP headers.  The server then
+   sends both the private and external address information of the game
+   player to all the other peer players.  At this point, each game
+   player knows the private and public address information of every
+   other peer.  Subsequent to this, each client opens up symmetrical
+   direct connection to each other and uses whichever address (private
+   or external) works first.
+
+   Now, the clients can have a session directly with other clients (or)
+   they can have session with other clients via the gaming server.  The
+   key is to allow reuse of the same (global address, assigned UDP port)
+   tuple used for initial connection to the game server for all
+   subsequent connections to the client.  A game player is recognized by
+   one of (private address, UDP port) or (global address, assigned UDP
+   port) by all other peer players.  So, the binding between tuples
+   should remain unchanged on NAT, so long as the gaming player is in
+   session with one or multiple other players.
+
+   Opening a connection to a game server in external realm from a
+   private host is no problem.  All NAT would have to do is provide
+   routing transparency and retain the same private-to-external address
+   binding so long as there is a minimum of one gaming session with an
+   external node.  But, an NAPT configuration must allow multiple
+   simultaneous UDP connections on the same assigned global
+   address/port.
+
+
+
+Holdrege & Srisuresh         Informational                     [Page 16]
+
+RFC 3027            Protocol Complications with NAT         January 2001
+
+
+   The above approach has some problems.  For example, a client could
+   try contacting a private address, but that private address could be
+   in use locally, when the private address at some other realm is
+   meant. If the node that was contacted wrongfully has some other
+   service or no service registered for the UDP port, the Activision
+   connect messages are expected to be simply dropped.  In the unlikely
+   event, a registered application chooses to interpret the message, the
+   results can be unpredictable.
+
+   The readers may refer to Activision for the proprietary, detailed
+   information on the function and design of this protocol.
+
+6.0 Acknowledgements
+
+   The authors would like to express sincere thanks to Bernard Aboba,
+   Bill Sommerfield, Dave Cridland, Greg Hudson, Henning Schulzrine,
+   Jeffrey Altman, Keith Moore, Thomas Narten, Vernon Shryver and others
+   that had provided valuable input in preparing this document.  Special
+   thanks to Dan Kegel for sharing the Activision games design
+   methodology.
+
+7.0 Security Considerations
+
+   The security considerations outlined in [NAT-TERM] are relevant to
+   all NAT devices.  This document does not warrant additional security
+   considerations.
+
+8.0 References
+
+   [NAT-TERM]   Srisuresh, P. and M. Holdrege, "IP Network Address
+                Translator (NAT) Terminology and Considerations", RFC
+                2663, August 1999.
+
+   [NAT-TRAD]   Srisuresh, P. and K. Egevang, "Traditional IP Network
+                Address Translator (Traditional NAT)", RFC 3022, January
+                2001.
+
+   [H.323]      ITU-T SG16 H.323, Intel white paper, "H.323 and
+                Firewalls", Dave Chouinard, John Richardson, Milind
+                Khare (with further assistance from Jamie Jason).
+
+   [SNMP-ALG]   Raz, D., Schoenwaelder, J. and B. Sugla, "An SNMP
+                Application Level Gateway for Payload Address
+                Translation", RFC 2962, October 2000.
+
+   [SNMP-APPL]  Levi, D., Meyer, P. and B. Stewart, "SNMP Applications",
+                RFC 2573, April 1999.
+
+
+
+
+Holdrege & Srisuresh         Informational                     [Page 17]
+
+RFC 3027            Protocol Complications with NAT         January 2001
+
+
+   [NAT-ARCH]   Hain, T. "Architectural Implications of NAT", RFC 2993,
+                November 2000.
+
+   [SMTP]       Postel, J., "Simple Mail Transfer Protocol", STDl 10,
+                RFC 821, August 1982.
+
+   [FTP]        Postel, J. and J. Reynolds, "File Transfer Protocol
+                (FTP)", STD 9, RFC 959, October 1985.
+
+   [SIP]        Handley, M., Schulzrinne, H., Schooler, E. and J.
+                Rosenberg, "SIP: Session Initiation Protocol", RFC 2543,
+                March 1999.
+
+   [X Windows]  Scheifler, B., "FYI on the X Window System", FYI 6, RFC
+                1198, January 1991.
+
+   [RSVP]       Braden, R., Zhang. L., Berson. S., Herzog, S. and S.
+                Jamin, "Resource ReSerVation Protocol (RSVP) -- Version
+                1 Functional Specification", RFC 2205, September 1997.
+
+   [DNS-TERMS]  Mockapetris, P., "Domain Names - Concepts and
+                Facilities", STD 13, RFC 1034, November 1987.
+
+   [DNS-IMPL]   Mockapetris, P., "Domain Names - Implementation and
+                Specification", STD 13, RFC 1035, November 1987.
+
+   [DNS-ALG]    Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A.
+                Heffernan, "DNS extensions to Network Address
+                Translators (DNS_ALG)", RFC 2694, September 1999.
+
+   [IPsec]      Kent, S. and R. Atkinson, "Security Architecture for the
+                Internet Protocol", RFC 2401, November 1998.
+
+   [IPsec-ESP]  Kent, S. and R. Atkinson, "IP Encapsulating Security
+                Payload (ESP)", RFC 2406, November 1998.
+
+   [IPsec-AH]   Kent, S. and R. Atkinson, "IP Authentication Header",
+                RFC 2402, November 1998.
+
+   [IPsec-DOCS] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security
+                Document Roadmap", RFC 2411, November 1998.
+
+   [NAT-SEC]    Srisuresh, P., "Security Model with Tunnel-mode IPsec
+                for NAT Domains", RFC 2709, October 1999.
+
+   [PRIV-ADDR]  Rekhter, Y., Moskowitz, B., Karrenberg, D., G. de Groot,
+                and E. Lear, "Address Allocation for Private Internets",
+                BCP 5, RFC 1918, February 1996.
+
+
+
+Holdrege & Srisuresh         Informational                     [Page 18]
+
+RFC 3027            Protocol Complications with NAT         January 2001
+
+
+   [ADDR-BEHA]  Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4
+                Address Behaviour Today", RFC 2101, February 1997.
+
+Authors' Addresses
+
+   Matt Holdrege
+   ipVerse
+   223 Ximeno Ave.
+   Long Beach, CA 90803
+
+   EMail: matt@ipverse.com
+
+
+   Pyda Srisuresh
+   Jasmine Networks, Inc.
+   3061 Zanker Road, Suite B
+   San Jose, CA 95134
+   U.S.A.
+
+   Phone: (408) 895-5032
+   EMail: srisuresh@yahoo.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Holdrege & Srisuresh         Informational                     [Page 19]
+
+RFC 3027            Protocol Complications with NAT         January 2001
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  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 RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Holdrege & Srisuresh         Informational                     [Page 20]
+