RFC 1579

Firewall-Friendly FTP 🎀

okay bestie, so this is RFC 1579 💖 It's called Firewall-Friendly FTP and it came out in February 1994 from S. Bellovin (full name Steven M. Bellovin!) at AT&T Bell Laboratories 🦋 It's filed as Category: Informational, which means it's giving "here's some info," not "this is a standard" 🧚 It's also part of the Network Working Group 🌸 The document doesn't list anything it obsoletes or updates, so there's no extra title-block drama there ✨

Status of this Memo 📜

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

Abstract 🫶

This memo suggests a change to how FTP client programs behave. No protocol modifications are required, though it does outline some that might be useful 🌈

Overview and Rational ✨

The FTP protocol [1] uses a secondary TCP connection to actually send files 📁 By default, that connection is set up by an active open from the FTP server to the FTP client. But this setup doesn't work well with packet filter-based firewalls, which generally can't let incoming calls through to random port numbers 😭

If clients use the PASV command instead, the data channel becomes an outgoing call through the firewall. Those calls are way easier to handle and cause fewer problems 🎀

The Gory Details 🔥

The FTP spec says that by default, all data transfers should be over a single connection. The server does an active open from its port 20 to the same port on the client machine that the control connection used. The client does a passive open 🧚

Honestly though, most current FTP clients don't do it that way 💀 They use a new connection for each transfer. To avoid running afoul of TCP's TIMEWAIT state, the client picks a new port number every time and sends a PORT command to tell the server about it 🙈

Neither scenario is firewall-friendly, bestie 😩 If a packet filter is in use (like the ones most modern routers come with), those data channel requests look like incoming calls to unknown ports. Most firewalls only let incoming calls reach certain believed-to-be-safe ports, like SMTP. The usual workaround is to block only the "server" area, meaning port numbers below 1024. But that's risky, because dangerous services such as X Windows live at higher-numbered ports 🥺

Outgoing calls are a whole different vibe 🦋 They cause fewer problems for both the firewall admin and the packet filter. Any TCP packet with the ACK bit set can't be the packet that starts a TCP connection, so filters can be set up to pass those packets only in the outbound direction. So we want FTP to change so the data channel is a call from the client to the server 👑

Good news: the mechanisms we need already exist in the protocol ✨ If the client sends a PASV command, the server does a passive TCP open on some random port and tells the client which port number it picked. Then the client can do an active open to set up the connection 💜

There are a few FTP servers out there that don't honor the PASV command. That's unfortunate (and it violates STD 3, RFC 1123 [2]), but it's not a dealbreaker 🙃 Non-conforming implementations will reply with 500 Command not understood, and it's a simple matter to fall back to the current behavior. Sure, you might not be able to talk to those sites through a firewall, but that would've been true anyway if PASV had never 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's no reason not to use it even for non-firewall transfers, and making it standard behavior will make the client way more useful in a firewall environment 👑

STD 3, RFC 1123 points out that the format of the response to a PASV command isn't well-defined. So we recommend that FTP clients and servers follow that RFC's recommendations for solving this problem 🫶

Discussion 💬

With most current FTP clients, using PASV doesn't cause any extra messages to be sent. Every transfer already starts with an extra exchange between the client and the server, and it doesn't matter whether that exchange involves a PORT command or a PASV command 🧚

Gopher-style clients have a bit of extra overhead. They transfer exactly one file per control channel connection, so they don't need PORT commands at all. If that's a serious concern, the Gopher proxy should sit on the outside of the firewall so the packet filter's restrictions don't get in its way 🎀

If we accept that clients should always do active opens, it might be worth enhancing FTP to get rid of the extra exchange entirely 🌈 At startup, the client could send a new command, APSV ("all passive"). A server that implements this would always do a passive open. A new reply code 151 would be sent in response to all file transfer requests not preceded by a PORT or PASV command, and that message would contain the port number to use for the 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, which allows third-party transfers 🦋

Implementation Status 🛠️

At least two independent implementations of the modified clients exist. Source code for one of them is freely available. As far as the authors know, APSV hasn't been implemented 🥺

Security Considerations 🔐

Some people think packet filters are dangerous, since they're super hard to configure properly. We agree 💀 But they're also very popular, so here we are 😤 Another common complaint is that allowing arbitrary outgoing calls is dangerous, because it lets sensitive data be exported freely through a firewall. Some firewalls impose artificial bandwidth limits to discourage this. Whether that approach is a good idea is beyond the scope of this memo, but we note that the kind of application-level gateway needed to build a bandwidth limiter could be built just as easily using PASV as with PORT 🧐

Using PASV does enhance the security of gateway machines 🛡️ They no longer need to create ports that an outsider might connect to before the real FTP client does. Even better, the protocol between the client host and the firewall can be simplified, since there's no need to specify a "create" operation 🔥

Concerns have been raised that this use of PASV just trades one problem for another 😱 With it, the FTP server has to accept calls to random ports, which could pose an equal problem for its firewall.

We don't think this is a serious issue, and there are several reasons why 🫶

First, there are far fewer FTP servers than there are clients. It's possible to secure a small number of special-purpose machines, like gateways and organizational FTP servers. The firewall's filters can be configured to allow access to just those machines. Further precautions can be taken by modifying the FTP server so it only uses very high-numbered ports for the data channel. It's comparatively easy to make sure no dangerous services live in a given port range, and again, this is feasible only because there are so few servers 🌸

References 📚

[1] Postel, J., and J. Reynolds, "File Transfer Protocol", STD 1, RFC 959, USC/Information Sciences Institute, October 1985.

[2] Braden, R., Editor, "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, USC/Information Sciences Institute, October 1989.

[3] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey, D., and B. Alberti, "The Internet Gopher Protocol (a distributed document search and retrieval protocol)", RFC 1436, University of Minnesota, March 1993.

Author's Address 💌

Steven M. Bellovin
AT&T Bell Laboratories
600 Mountain Avenue
Murray Hill, NJ  07974

Phone: (908) 582-5886
EMail: smb@research.att.com