Summary

  • FTP separated commands from file data. The client opened the control connection, but in the normal active pattern the server opened a second connection back to a client-selected data port.
  • Packet-filter firewalls made that callback look like an unsolicited inbound call. RFC 1579 recommended PASV: the server listened, reported a port, and the client originated the data connection through the boundary.
  • RFC 2428’s EPSV returned only a port and reused the control peer’s address, reducing what NAT had to rewrite. Direction still was not identity: bounce attacks and passive-port theft required endpoints to constrain targets and bind the data peer to the control session.

One file transfer, two conversations

The architecture in RFC 959 is easy to misremember because a user sees one FTP session. The protocol sees two connections. A control connection carries commands and replies. A data connection carries a directory listing, part of a file, a whole file or a series of files. The data path can disappear while the control conversation remains alive.

The split was useful. Commands were small and long-lived; data could be large and temporary. Representation, transfer mode and file-system operations could be negotiated on the control path while a distinct full-duplex path did the carrying. Yet the split also meant that logging in did not finish the network work. Every transfer still needed an answer to a second question: which process would listen, and which one would call?

The original answer was asymmetric. The user protocol interpreter initiated the control connection. For data, the user side normally listened and the server’s data-transfer process initiated the connection. PORT let the client name a different host and port, which also supported a remarkable three-party arrangement: a user could control two servers and ask one to send directly to the other.

This was not a defect hidden in the specification. It was an explicit allocation of roles. The client described an endpoint; the server acted on that description. In a network where hosts could accept connections, the callback was ordinary machinery.

A filter saw a stranger at the door

By February 1994, Steven Bellovin’s RFC 1579 described a different operational world. Clients commonly selected a fresh data port for every transfer and sent it in PORT. A packet-filter firewall protecting the client then saw the FTP server begin a new inbound TCP connection to an unpredictable high-numbered port.

The filter had little context. It could allow known public services, or perhaps infer that a packet with an acknowledgement belonged to an established flow. It could not safely leave every transient client port open merely because an authenticated control connection existed somewhere else. The second connection was meaningful to FTP but looked unsolicited to a device applying transport rules.

The mismatch was not that the firewall had failed to understand the Internet. The two systems had divided authority differently. FTP allowed the client to nominate an inbound endpoint; the firewall’s policy assumed that protected clients should originate new conversations. Each rule was locally coherent. Their composition failed.

PASV moved the active open

The protocol already contained the escape. PASV asks the server data-transfer process to listen on a non-default port and wait rather than initiate a connection after the transfer command. The server returns the address and port on which it is listening. The client then performs the active open.

That reversal changed what crossed the boundary. Both the long-lived control connection and the temporary data connection now began on the client side. RFC 1579 therefore recommended that vendors make clients use PASV instead of PORT, even outside firewall environments.

The economy of the change matters. FTP did not have to merge its two planes. The firewall did not have to become the universal interpreter of application dialogue. A passive transfer did not necessarily add a round trip, because clients were already sending PORT before a transfer. A small choice about who dialled made the existing architecture compatible with a common local policy.

Nor did publication turn the recommendation into reality. Some servers did not understand PASV; clients could receive an error and fall back to active mode. That preserved old interoperability where the network allowed it, but the fallback still could not pass a firewall that rejected the callback. Adoption lived in server support, client defaults and deployed rules.

RFC 1579 even discussed an APSV command that might have made all transfers passive without a separate request. It reported no known implementation. The unimplemented idea is useful evidence: a document can name a future, but only running participants can make it an operating convention.

EPSV stopped advertising the address

Classic PORT and PASV encoded an IPv4 address and TCP port. That became a liability when IPv6 arrived and when NAT changed addresses between the two ends. A translator might have to inspect the FTP control payload, recognise the command, and rewrite a network address embedded inside application data.

RFC 2428 supplied the extended pair. EPRT can carry an address-family number, network address and port, preserving the active arrangement for IPv4, IPv6 and later families. EPSV takes the passive idea further: its reply contains only the listening TCP port. The data connection uses the same network protocol and peer address as the control connection.

Removing the address was more than syntax. The control connection had already established which server the client reached. For an ordinary two-machine transfer, repeating a network address created another claim that a NAT might have to repair and a client might have to interpret. EPSV narrowed the message to the new fact the client actually needed: the temporary port.

EPSV ALL made the session boundary explicit. Once the server accepts it, it must reject EPRT, PORT, PASV and other data-setup alternatives for that control session. A client that later discovers it needs a three-way transfer must open a new FTP session. The choice is strong but local and reversible at a clear boundary; it does not rewrite every other session on the network.

A coordinate was never a credential

Changing direction solved a reachability problem. It did not answer who was entitled to occupy either endpoint.

RFC 2577 documents the active side’s most striking abuse. Because PORT could name a third party, a client could ask an FTP server to connect to a different machine and service and send attacker-chosen bytes. This “bounce” obscured the initiator and could evade address-based restrictions. Suggested defences included refusing active data targets below TCP port 1024, disabling PORT where server-to-server transfer was unnecessary, and checking both control and data addresses when access policy relied on location.

Passive mode moved rather than abolished the exposed listener. The server now opened a transient port. If an attacker could predict the next port and connect first, the attacker might deny the legitimate transfer, receive a file intended for somebody else or inject a forged file into a stream expected from an authenticated client. RFC 2577 recommended random local data ports. More fundamentally, endpoints had to decide whether the data peer belonged to the control session.

That distinction keeps the historical claim honest. PASV made the connection direction friendlier to a client firewall. EPSV made the coordinates friendlier to IPv6 and NAT. Neither command made FTP confidential, authenticated the file stream or proved that the first process to reach a listening port was the logged-in party.

A small extension redistributed work

The story is often reduced to “passive FTP works through firewalls.” What endured was the allocation underneath it.

The shared protocol defined only enough for one side to announce a listener and the other to open the path. The client chose whether to request passive operation. The server chose a port and decided which setup commands and destinations it would permit. The firewall kept its local rule about new inbound flows. Implementations retained the duty to associate two transport connections with one security context.

This is a precise example of minimum common machinery producing local future choice. An old active implementation could continue where both ends and the network accepted it. A client and server could adopt passive mode without a central cutover. EPSV could become the cleaner two-party profile while EPRT retained the exceptional three-party capability. Incompatibility appeared as a failed command or connection, not as an institution declaring one participant invalid.

The limits were equally local. A server could disable PORT; a client could insist on EPSV; a NAT could avoid payload rewriting; a security policy could reject a data peer that did not match the control peer. Each decision changed that participant’s compatibility surface. None of them needed to turn a port number into universal authority.

Sources and limits

The two-connection model, normal server-initiated data connection, PORT and PASV come from RFC 959. The firewall analysis and recommendation to make client-side passive operation the default come from RFC 1579. EPRT, EPSV, address-family support, address omission and EPSV ALL are specified in RFC 2428. Bounce attacks, address checks and passive-port theft are described in RFC 2577.

These documents do not measure current FTP deployment or prove that every firewall, NAT, proxy, client or server behaves as recommended. They do not make passive FTP a secure transport. They support a narrower history: when a server callback collided with a new boundary, FTP survived by letting the client initiate the second connection and by keeping the remaining trust decisions in running systems.