HTTP/1.1 200 OK Date: Mon, 08 Apr 2002 22:28:36 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Thu, 27 Mar 1997 18:59:00 GMT ETag: "2e7cc8-29b4-333ac374" Accept-Ranges: bytes Content-Length: 10676 Connection: close Content-Type: text/plain Internet Engineering Task Force Mark Allman INTERNET DRAFT Shawn Ostermann File: draft-allman-ftp-variable-04.txt Ohio University March 26, 1997 Expires: September 26, 1997 FTP Extensions for Variable Protocol Specification Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract The specification for the File Transfer Protocol assumes that the underlying network protocols use a 32-bit network address and a 16-bit transport address (specifically IP version 4 and TCP). With the deployment of version 6 of the Internet Protocol, network addresses will no longer be 32-bits. This paper specifies extensions to FTP that will allow the protocol to work over a variety of network and transport protocols. 1. Introduction The File Transfer Protocol [PR85] only provides the ability to open data connections on networks using the TCP/IP protocol suite [Com95]. FTP assumes network addresses will be 32 bits in length and the transport address (TCP port number) will be 16 bits long. Changes to FTP to support different network and transport protocols will be needed as new protocols are deployed (most notably, IPv6 [DH96]). RFC 1639 [Pis94] specifies extensions to FTP to enable its use over various network protocols. While RFC 1639 allows for variable length transport addresses, it provides no mechanism to choose which transport protocol will be used. The transport protocol is assumed to be based on the network protocol chosen. This document provides a specification which makes no assumptions Expires: September 26, 1997 [Page 1] draft-allman-ftp-variable-04.txt March 26, 1997 regarding the underlying network and transport protocols. In addition, protocol specification and encoding have been changed to a more human-readable format. In this specification, the FTP commands PORT and PASV are replaced with EPRT and EPSV, respectively. 2. The EPRT Command The EPRT command allows for the specification of an extended address for the data connection. The extended address consists of the network and transport protocols as well as the network and transport addresses. The format of EPRT is: EPRT ||| The and arguments MUST be upper-case strings indicating the protocol to be used (and, implicitly, the address length). This specification defines keywords for the following protocols: Network Protocols: Keyword Protocol ------- -------- IP4 Internet Protocol, Version 4 [Pos81a] IP6 Internet Protocol, Version 6 [DH96] Transport Protocols: Keyword Protocol ------- -------- TCP Transmission Control Protocol [Pos81b] RDP Reliable Data Protocol [PH90] Keywords for other protocols will be specified as needed. The and are protocol specific string representations of the respective addresses. For each of the following keywords, addresses MUST be in the following format: Keyword Address Format Example ------- -------------- ------- IP4 dotted decimal 132.235.1.2 IP6 IPv6 string 1080::8:800:200C:417A representations defined in [HD96] TCP string 6446 representation of decimal port number RDP string 3684 representation of decimal port number Expires: September 26, 1997 [Page 2] draft-allman-ftp-variable-04.txt March 26, 1997 The , and fields are optional. If left blank, their default values are as follows: Field Default Value If Omitted ----- ------------------------ Network protocol of the control connection Transport protocol of the control connection Network address of the control connection The following are sample EPRT commands: EPRT IP4|TCP|132.235.1.2|6275 EPRT |RDP||5282 The first command specifies that the server should use IPv4/TCP to open a data connection to the host "132.235.1.2" on port 6275. The second command specifies that the server should use the network protocol and network address used by the control connection to open an RDP data connection on port 5282. Upon receipt of a valid EPRT command, the server MUST return a code of 200 (Command OK). The standard negative error codes 500 and 501 [PR85] are sufficient to handle most errors (e.g., syntax errors) involving the EPRT command. However, two additional error codes are needed. The response code 522 indicates that the server does not support the requested network protocol. Likewise, the response code 523 indicates that the server does not support the requested transport protocol. The interpretation of these error codes is: 5yz Negative Completion x2z Connections xy2 Extended Port Failure - unknown network protocol xy3 Extended Port Failure - unknown transport protocol The text portion of the response MUST indicate which protocol(s) the server does support. If the network protocol is unsupported, the format of the response string MUST be: (prot1,prot2,...,protn) \ In this document, any text enclosed within "<>" is informational text which can be written in any language. In the above case, the text SHOULD indicate that the network protocol in the EPRT command is not supported by the server. Two example response strings follow: (IP6) Supported network protocols (IP4,IP6) Supported network protocols Similarly, if the transport protocol is not supported, the format of Expires: September 26, 1997 [Page 3] draft-allman-ftp-variable-04.txt March 26, 1997 the response string MUST be: (prot1,prot2,...,protn) \ where the protocols are identified by the keywords listed above for the EPRT command. In the case when both the network and transport protocols specified in the EPRT command are unsupported, the error reported MUST be 522 (unsupported network protocol). 3. The EPSV Command The EPSV command requests that a server listen on a data port and wait for a connection. The response to this command includes all information needed to setup a connection using the EPRT command. The response code for entering passive mode using an extended address MUST be 229. The interpretation of this code, according to [PR85] is: 2yz Positive Completion x2z Connections xy9 Extended Passive Mode Entered The text returned in response to the EPSV command MUST be: (|||) \ The portion of the string enclosed in parentheses MUST be the exact string needed by the EPRT command to open the data connection, as specified above. An example response string follows: (IP4|TCP|132.235.1.2|6446) Entering Extended Passive Mode The standard negative error codes 500 and 501 are sufficient to handle all errors involving the EPSV command (e.g., syntax errors). 4. Security Issues These FTP extensions increase the scope of the FTP "bounce attack" by making it possible for connections to be made using a transport protocol other than TCP. A companion Internet Draft [AO96] is a more general discussion of FTP security issues and techniques to reduce these security problems. 5. Conclusions The extensions specified in this paper will enable FTP to operate over a variety of network and transport protocols. Expires: September 26, 1997 [Page 4] draft-allman-ftp-variable-04.txt March 26, 1997 References [AO96] Mark Allman and Shawn Ostermann. Security Issues of Interest to FTP Server Implementers (Internet Draft, in preparation). [Com95] Douglas E. Comer. Internetworking with TCP/IP, Volume 1, Principles, Protocols, and Architecture. Prentice Hall, 3rd edition, 1995. [DH96] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) Specification, January 1996. RFC 1883. [HD96] R. Hinden and S. Deering. IP Version 6 Addressing Architecture, January 1996. RFC 1884. [Pis94] D. Piscitello. FTP Operation Over Big Address Records (FOOBAR), June 1994. RFC 1639. [PH90] C. Partridge and R. Hinden. Version 2 of the Reliable Data Protocol (RDP), April 1990. RFC 1151. [Pos81a] J. Postel. Internet Protocol, September 1981. RFC 791. [Pos81b] J. Postel. Transmission Control Protocol, September 1981. RFC 793. [PR85] J. Postel and J. Reynolds. File Transfer Protocol (FTP), October 1985. RFC 959. Author's Addresses: Mark Allman and Shawn Ostermann School of Electrical Engineering and Computer Science Ohio University 416 Morton Hall Athens, OH 45701 mallman@cs.ohiou.edu ostermann@cs.ohiou.edu Expires: September 26, 1997 [Page 5]