Browse Prior Art Database

Firewall-Friendly FTP (RFC1579)

IP.com Disclosure Number: IPCOM000002413D
Original Publication Date: 1994-Feb-01
Included in the Prior Art Database: 2000-Sep-12
Document File: 4 page(s) / 8K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

S. Bellovin: AUTHOR

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.

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 33% of the total text.

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

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 fr...