Firewall-Friendly FTP
RFC 1579

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions

Network Working Group                                        S. Bellovin
Request for Comments: 1579                        AT&T Bell Laboratories
Category: Informational                                    February 1994

                         Firewall-Friendly FTP

Status of this Memo

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

Abstract

   This memo describes a suggested change to the behavior of FTP client
   programs.  No protocol modifications are required, though we outline
   some that might be useful.

Overview and Rational

   The FTP protocol [1] uses a secondary TCP connection for actual
   transmission of files.  By default, this connection is set up by an
   active open from the FTP server to the FTP client.  However, this
   scheme does not work well with packet filter-based firewalls, which
   in general cannot permit incoming calls to random port numbers.

   If, on the other hand, clients use the PASV command, the data channel
   will be an outgoing call through the firewall.  Such calls are more
   easily handled, and present fewer problems.

The Gory Details

   The FTP specification says that by default, all data transfers should
   be over a single connection.  An active open is done by the server,
   from its port 20 to the same port on the client machine as was used
   for the control connection.  The client does a passive open.

   For better or worse, most current FTP clients do not behave that way.
   A new connection is used for each transfer; to avoid running afoul of
   TCP's TIMEWAIT state, the client picks a new port number each time
   and sends a PORT command announcing that to the server.

   Neither scenario is firewall-friendly.  If a packet filter is used
   (as, for example, provided by most modern routers), the data channel
   requests appear as incoming calls to unknown ports.  Most firewalls
   are constructed to allow incoming calls only to certain believed-to-
   be-safe ports, such as SMTP.  The usual compromise is to block only

Bellovin                                                        [Page 1]
RFC 1579                 Firewall-Friendly FTP             February 1994

   the "server" area, i.e., port numbers below 1024.  But that strategy
   is risky; dangerous services such as X Windows live at higher-
   numbered ports.

   Outgoing calls, on the other hand, present fewer problems, either for
   the firewall administrator or for the packet filter.  Any TCP packet
   with the ACK bit set cannot be the packet used to initiate a TCP
   connection; filters can be configured to pass such packets in the
   outbound direction only.  We thus want to change the behavior of FTP
   so that the data channel is implemented as a call from the client to
   the server.

   Fortunately, the necessary mechanisms already exist in the protocol.
   If the client sends a PASV command, the server will do a passive TCP
   open on some random port, and inform the client of the port number.
   The client can then do an active open to establish the connection.

   There are a few FTP servers in existence that do not honor the PASV
   command.  While this is unfortunate (and in violation of STD 3, RFC
   1123 [2]), it does not pose a problem.  Non-conforming
   implementations will return a "500 Command not understood" message;
   it is a simple matter to fall back to current behavior.  While it may
   not be possible to talk to such sites through a firewall, that would
   have been the case had PASV not been adopted.

Recommendation

   We recommend that vendors convert their FTP client programs
   (including FTP proxy agents such as Gopher [3] daemons) to use PASV
   instead of PORT.  There is no reason not to use it even for non-
   firewall transfers, and adopting it as standard behavior will make
   the client more useful in a firewall environment.

   STD 3, RFC 1123 notes that the format of the response to a PASV
   command is not well-defined.  We therefore recommend that FTP clients
   and servers follow the recommendations of that RFC for solving this
   problem.

Discussion

   Given the behavior of most current FTP clients, the use of PASV does
   not cause any additional messages to be sent.  In all cases, a
   transfer operation is preceded by an extra exchange between the
   client and the server; it does not matter if that exchange involves a
   PORT command or a PASV command.

   There is some extra overhead with Gopher-style clients; since they
   transfer exactly one file per control channel connection, they do not

Bellovin                                                        [Page 2]
RFC 1579                 Firewall-Friendly FTP             February 1994

   need to use PORT commands.  If this is a serious concern, the Gopher
   proxy should be located on the outside of the firewall, so that it is
   not hampered by the packet filter's restrictions.