Network Working Group Craig Metz Internet Draft The Inner Net draft-metz-sport-00.txt 5 September 1997 Short Port Commands for FTP Status of this Memo This document is an Internet Draft. Internet Drafts are working documents. Internet Drafts are draft documents valid for a maximum of 6 months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as "work in progress". A future version of this draft will be submitted to the RFC Editor for publication as an Informational document. Abstract RFC 1639[Pis94] documents experimental long port (LPRT) and long passive (LPSV) commands that many IP Version 6 implementations are using as the replacement for the PORT and PASV commands in FTP [PR85]. The author believes that this is the incorrect direction to be heading and that the replacement for PORT and PASV should carry less information instead of more. The short port command (SPORT) and short passive command (SPASV) are replacements for the PORT and PASV commands, respectively. The short commands only carry port numbers and do not carry addresses. This makes them usable with IPv4 and IPv6. A benefit of not carrying addresses is that pure network address translators (NAT) do not have to do a search-and-replace on the TCP stream, which is an expensive operation. This also precludes three-way FTP, which is a rarely used mode of operation that leaves most existing FTP servers wide open to the FTP Bounce Attack [Hob95]. The short port and passive commands are implemented in the NRL IPv6+IPsec software distribution and the descendant inet6-apps Metz Expires in 6 months [Page 1] Internet Draft Short Port Commands for FTP 5 September 1997 distribution. 1. Introduction The FTP protocol defines two commands that are used to control the addresses and ports used for data connections. The first is the PORT command, with syntax of: PORT a1,a2,a3,a4,p1,p2 And a success response of 200. The second is the PASV command, with a syntax of: PASV And a success response of: 227 Entering Passive Mode. a1,a2,a3,a4,p1,p2 These commands carry four bytes of address information to make a 32 bit IPv4 address. To carry IPv6 addresses, these commands must be changed. The FOOBAR approach is to use a long port command, with a syntax of: LPRT af,hal,h1,h2,h3,h4...,pal,p1,p2... And a success response of 200. FOOBAR also defines a long passive command, with a syntax of: LPSV And a success response of: 228 Entering Long Passive Mode (af, hal, h1, h2, h3,..., pal, p1, p2...) The long port and long passive commands are a more flexible version of the original PORT and PASV commands that can handle longer addresses and port numbers. It has the same advantages and disadvantages as the original design. The author's opinion is that the replacements for PORT and PASV should modify this design to reflect current experiences and requirements. The File Transfer Protocol was designed to support a "three-way" mode of operation in which a server can be directed to send a file to a system other than the client. This feature is easily abused to Metz Expires in 6 months [Page 2] Internet Draft Short Port Commands for FTP 5 September 1997 create the FTP Bounce Attack. In his paper on this attack, [Hob95] rather bluntly characterizes the attack: "The mechanism used is probably well-known, but to date interest in detailing or fixing it seems low to nonexistent. ... It is chosen in an effort to make the reader sit up and notice that there are some really ill-conceived aspects of the standard FTP protocol." The fix for this attack is for servers to verify that the address sent in the PORT command matches the far address on the TCP control connection. Because the server's TCP stack must maintain the control connection address anyway and must check that the PORT argument matches, the address argument to the PORT command is redundant and only serves to create extra processing. The address argument to the PORT command creates headaches for implementors of Network Address Translators (NATs) because that address information must be translated along with the addresses on packets. However, unlike other addresses on packets, the PORT command arguments are at the application layer, above the telnet protocol, which is in turn above TCP. NATs have to re-assemble the TCP stream and then decode the telnet protocol looking for the PORT command's arguments. Once found, these boxen have to synthesize a new stream. Changing the TCP stream, and possibly the length of the string, in transit is a very expensive operation. Two alternatives to doing this are: 1. To implement the search-and-replace in a faster but less correct manner making certain assumptions (the path many existing NAT implementors chose to take, and a dangerous one), which means that some commands can be missed. 2. To not put the address information in the PORT commands. The short port commands make life much easier for those implementing NATs because there is no address to be translated in those commands. Note that a form of NAT being considered for use in the transition to IPv6, the IPv6<->IPv4 translator, also benefits from the short port commands. Finally, by removing the address information from the PORT commands, IPv4 and IPv6 addresses are naturally supported. 2. Short Port Commands The short port command's syntax is: SPORT p1,p2 Where p1 and p2 are the same as in the standard PORT command. The success response to this command is 200. Metz Expires in 6 months [Page 3] Internet Draft Short Port Commands for FTP 5 September 1997 The short passive command's syntax is: SPASV The success response to this command is: 229 Entering Passive Mode. p1,p2 Where p1 and p2 are the same as in the standard PASV command. 3. Security Considerations This document describes a set of protocol extensions that, among other things, closes a security hole in the current FTP protocol known as the FTP Bounce Attack. These extensions are believed by the author to otherwise have the same security properties as the protocol commands they replace. Acknowledgments This work was done at the Center for High Assurance Computer Systems at the U.S. Naval Research Laboratory. This work was sponsored by the Information Security Program Office (PMW-161), U.S. Space and Naval Warfare Systems Command (SPAWAR) and the Computing Systems Technology Office, Defense Advanced Research Projects Agency (DARPA/CSTO). The author and his co-workers really appreciates their sponsorship of NRL's network security efforts and their continued support of IPsec development. Without that support, this document, among many others, would not exist. References [Hob95] "*Hobbit*", "The FTP Bounce Attack", July 1995. (ftp.avian.org:/random/ftp-attack) [Pis94] D. Piscitello, "FTP Operation Over Big Address Records (FOOBAR)", RFC 1639, June 1994. [PR85] J. Postel and J. Reynolds, "File Transfer Protocol (FTP)", RFC 959, October 1985. Disclaimer The views and specification here are those of the author and are not necessarily those of his employer. His employer has not passed judgment on the merits, if any, of this work. The author and his employer specifically disclaim responsibility for any problems arising from correct or incorrect implementation or use of this Metz Expires in 6 months [Page 4] Internet Draft Short Port Commands for FTP 5 September 1997 specification. Author's Address Craig Metz The Inner Net Box 10314-1933 Blacksburg, VA 24062-0314 Phone: (DSN) 354-8590 E-mail: cmetz@inner.net Metz Expires in 6 months [Page 5]