RFC 1579 (rfc1579) - Page 3 of 4

Firewall-Friendly FTP

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.

   If we accept that clients should always perform active opens, it
   might be worthwhile enhancing the FTP protocol to eliminate the extra
   exchange entirely.  At startup time, the client could send a new
   command APSV ("all passive"); a server that implements this option
   would always do a passive open.  A new reply code 151 would be issued
   in response to all file transfer requests not preceded by a PORT or
   PASV command; this message would contain the port number to use for
   that transfer.  A PORT command could still be sent to a server that
   had previously received APSV; that would override the default
   behavior for the next transfer operation, thus permitting third-party
   transfers.

Implementation Status

   At least two independent implementations of the modified clients
   exist.  Source code to one is freely available.  To our knowledge,
   APSV has not been implemented.

Security Considerations

   Some people feel that packet filters are dangerous, since they are
   very hard to configure properly.  We agree.  But they are quite
   popular.  Another common complaint is that permitting arbitrary
   outgoing calls is dangerous, since it allows free export of sensitive
   data through a firewall.  Some firewalls impose artificial bandwidth
   limits to discourage this.  While a discussion of the merits of this
   approach is beyond the scope of this memo, we note that the sort of
   application-level gateway necessary to implement a bandwidth limiter
   could be implemented just as easily using PASV as with PORT.

   Using PASV does enhances the security of gateway machines, since they
   no longer need to create ports that an outsider might connect to
   before the real FTP client.  More importantly, the protocol between
   the client host and the firewall can be simplified, if there is no
   need to specify a "create" operation.

   Concerns have been expressed that this use of PASV just trades one
   problem for another.  With it, the FTP server must accept calls to
   random ports, which could pose an equal problem for its firewall.  We
   believe that this is not a serious issue, for several reasons.

   First, there are many fewer FTP servers than there are clients.  It
   is possible to secure a small number of special-purpose machines,
   such as gateways and organizational FTP servers.  The firewall's



Bellovin