rfc3027.txt

RFC3027:Protocol Complications with the IP Network Address Translator

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]