home *** CD-ROM | disk | FTP | other *** search
/ A Beginner's Guide to the Internet / INTERNET.ISO / text / rfc / rfc1579.txt < prev    next >
Encoding:
Text File  |  1996-03-03  |  8.8 KB  |  228 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                        S. Bellovin
  8. Request for Comments: 1579                        AT&T Bell Laboratories
  9. Category: Informational                                    February 1994
  10.  
  11.  
  12.                          Firewall-Friendly FTP
  13.  
  14. Status of this Memo
  15.  
  16.    This document provides information for the Internet community.  This
  17.    document does not specify an Internet standard of any kind.
  18.    Distribution of this document is unlimited.
  19.  
  20. Abstract
  21.  
  22.    This memo describes a suggested change to the behavior of FTP client
  23.    programs.  No protocol modifications are required, though we outline
  24.    some that might be useful.
  25.  
  26. Overview and Rational
  27.  
  28.    The FTP protocol [1] uses a secondary TCP connection for actual
  29.    transmission of files.  By default, this connection is set up by an
  30.    active open from the FTP server to the FTP client.  However, this
  31.    scheme does not work well with packet filter-based firewalls, which
  32.    in general cannot permit incoming calls to random port numbers.
  33.  
  34.    If, on the other hand, clients use the PASV command, the data channel
  35.    will be an outgoing call through the firewall.  Such calls are more
  36.    easily handled, and present fewer problems.
  37.  
  38. The Gory Details
  39.  
  40.    The FTP specification says that by default, all data transfers should
  41.    be over a single connection.  An active open is done by the server,
  42.    from its port 20 to the same port on the client machine as was used
  43.    for the control connection.  The client does a passive open.
  44.  
  45.    For better or worse, most current FTP clients do not behave that way.
  46.    A new connection is used for each transfer; to avoid running afoul of
  47.    TCP's TIMEWAIT state, the client picks a new port number each time
  48.    and sends a PORT command announcing that to the server.
  49.  
  50.    Neither scenario is firewall-friendly.  If a packet filter is used
  51.    (as, for example, provided by most modern routers), the data channel
  52.    requests appear as incoming calls to unknown ports.  Most firewalls
  53.    are constructed to allow incoming calls only to certain believed-to-
  54.    be-safe ports, such as SMTP.  The usual compromise is to block only
  55.  
  56.  
  57.  
  58. Bellovin                                                        [Page 1]
  59.  
  60. RFC 1579                 Firewall-Friendly FTP             February 1994
  61.  
  62.  
  63.    the "server" area, i.e., port numbers below 1024.  But that strategy
  64.    is risky; dangerous services such as X Windows live at higher-
  65.    numbered ports.
  66.  
  67.    Outgoing calls, on the other hand, present fewer problems, either for
  68.    the firewall administrator or for the packet filter.  Any TCP packet
  69.    with the ACK bit set cannot be the packet used to initiate a TCP
  70.    connection; filters can be configured to pass such packets in the
  71.    outbound direction only.  We thus want to change the behavior of FTP
  72.    so that the data channel is implemented as a call from the client to
  73.    the server.
  74.  
  75.    Fortunately, the necessary mechanisms already exist in the protocol.
  76.    If the client sends a PASV command, the server will do a passive TCP
  77.    open on some random port, and inform the client of the port number.
  78.    The client can then do an active open to establish the connection.
  79.  
  80.    There are a few FTP servers in existence that do not honor the PASV
  81.    command.  While this is unfortunate (and in violation of STD 3, RFC
  82.    1123 [2]), it does not pose a problem.  Non-conforming
  83.    implementations will return a "500 Command not understood" message;
  84.    it is a simple matter to fall back to current behavior.  While it may
  85.    not be possible to talk to such sites through a firewall, that would
  86.    have been the case had PASV not been adopted.
  87.  
  88. Recommendation
  89.  
  90.    We recommend that vendors convert their FTP client programs
  91.    (including FTP proxy agents such as Gopher [3] daemons) to use PASV
  92.    instead of PORT.  There is no reason not to use it even for non-
  93.    firewall transfers, and adopting it as standard behavior will make
  94.    the client more useful in a firewall environment.
  95.  
  96.    STD 3, RFC 1123 notes that the format of the response to a PASV
  97.    command is not well-defined.  We therefore recommend that FTP clients
  98.    and servers follow the recommendations of that RFC for solving this
  99.    problem.
  100.  
  101. Discussion
  102.  
  103.    Given the behavior of most current FTP clients, the use of PASV does
  104.    not cause any additional messages to be sent.  In all cases, a
  105.    transfer operation is preceded by an extra exchange between the
  106.    client and the server; it does not matter if that exchange involves a
  107.    PORT command or a PASV command.
  108.  
  109.    There is some extra overhead with Gopher-style clients; since they
  110.    transfer exactly one file per control channel connection, they do not
  111.  
  112.  
  113.  
  114. Bellovin                                                        [Page 2]
  115.  
  116. RFC 1579                 Firewall-Friendly FTP             February 1994
  117.  
  118.  
  119.    need to use PORT commands.  If this is a serious concern, the Gopher
  120.    proxy should be located on the outside of the firewall, so that it is
  121.    not hampered by the packet filter's restrictions.
  122.  
  123.    If we accept that clients should always perform active opens, it
  124.    might be worthwhile enhancing the FTP protocol to eliminate the extra
  125.    exchange entirely.  At startup time, the client could send a new
  126.    command APSV ("all passive"); a server that implements this option
  127.    would always do a passive open.  A new reply code 151 would be issued
  128.    in response to all file transfer requests not preceded by a PORT or
  129.    PASV command; this message would contain the port number to use for
  130.    that transfer.  A PORT command could still be sent to a server that
  131.    had previously received APSV; that would override the default
  132.    behavior for the next transfer operation, thus permitting third-party
  133.    transfers.
  134.  
  135. Implementation Status
  136.  
  137.    At least two independent implementations of the modified clients
  138.    exist.  Source code to one is freely available.  To our knowledge,
  139.    APSV has not been implemented.
  140.  
  141. Security Considerations
  142.  
  143.    Some people feel that packet filters are dangerous, since they are
  144.    very hard to configure properly.  We agree.  But they are quite
  145.    popular.  Another common complaint is that permitting arbitrary
  146.    outgoing calls is dangerous, since it allows free export of sensitive
  147.    data through a firewall.  Some firewalls impose artificial bandwidth
  148.    limits to discourage this.  While a discussion of the merits of this
  149.    approach is beyond the scope of this memo, we note that the sort of
  150.    application-level gateway necessary to implement a bandwidth limiter
  151.    could be implemented just as easily using PASV as with PORT.
  152.  
  153.    Using PASV does enhances the security of gateway machines, since they
  154.    no longer need to create ports that an outsider might connect to
  155.    before the real FTP client.  More importantly, the protocol between
  156.    the client host and the firewall can be simplified, if there is no
  157.    need to specify a "create" operation.
  158.  
  159.    Concerns have been expressed that this use of PASV just trades one
  160.    problem for another.  With it, the FTP server must accept calls to
  161.    random ports, which could pose an equal problem for its firewall.  We
  162.    believe that this is not a serious issue, for several reasons.
  163.  
  164.    First, there are many fewer FTP servers than there are clients.  It
  165.    is possible to secure a small number of special-purpose machines,
  166.    such as gateways and organizational FTP servers.  The firewall's
  167.  
  168.  
  169.  
  170. Bellovin                                                        [Page 3]
  171.  
  172. RFC 1579                 Firewall-Friendly FTP             February 1994
  173.  
  174.  
  175.    filters can be configured to allow access to just these machines.
  176.    Further precautions can be taken by modifying the FTP server so that
  177.    it only uses very high-numbered ports for the data channel.  It is
  178.    comparatively easy to ensure that no dangerous services live in a
  179.    given port range.  Again, this is feasible because of the small
  180.    number of servers.
  181.  
  182. References
  183.  
  184.    [1] Postel, J., and J. Reynolds, "File Transfer Protocol", STD 1, RFC
  185.        959, USC/Information Sciences Institute, October 1985.
  186.  
  187.    [2] Braden, R., Editor, "Requirements for Internet Hosts -
  188.        Application and Support", STD 3, RFC 1123, USC/Information
  189.        Sciences Institute, October 1989.
  190.  
  191.    [3] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey,
  192.        D., and B. Alberti, "The Internet Gopher Protocol (a distributed
  193.        document search and retrieval protocol)", RFC 1436, University of
  194.        Minnesota, March 1993.
  195.  
  196. Author's Address
  197.  
  198.        Steven M. Bellovin
  199.        AT&T Bell Laboratories
  200.        600 Mountain Avenue
  201.        Murray Hill, NJ  07974
  202.  
  203.        Phone: (908) 582-5886
  204.        EMail: smb@research.att.com
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Bellovin                                                        [Page 4]
  227.  
  228.