Internet Engineering Task Force Mark Allman
INTERNET DRAFT NASA Lewis/Sterling Software
File: draft-allman-ftp-variable-05.txt Shawn Ostermann
Ohio University
August 18, 1997
Expires: February 18, 1998
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/IPv4 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.
Expires: February 18, 1998 [Page 1]
draft-allman-ftp-variable-05.txt August 1997
This document provides a specification which makes no assumptions
regarding the underlying network and transport protocols. 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<space><d><net-prt><d><trans-prt><d><net-addr><d><trans-addr><d>
The EPRT command keyword must be followed by a single space.
Following the space, a delimiter character (<d>) must be specified.
The delimiter character MUST be one of the ASCII characters in range
33-126 inclusive, the character "|" (ASCII 124) is recommended
unless it coincides with a character needed to encode the network or
transport address.
The <net-prt> and <trans-prt> 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 <net-addr> and <trans-addr> 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]
Expires: February 18, 1998 [Page 2]
draft-allman-ftp-variable-05.txt August 1997
Keyword Address Format Example
------- -------------- -------
TCP string 6446
representation
of decimal port
number
RDP string 3684
representation
of decimal port
number
The <net-prt>, <trans-prt> and <net-addr> fields are optional. If
left blank, their default values are as follows:
Field Default Value If Omitted
----- ------------------------
<net-prt> Network protocol of the control connection
<trans-prt> Transport protocol of the control connection
<net-addr> 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:
<text stating that the network protocol is unsupported> \
(prot1,prot2,...,protn)
Expires: February 18, 1998 [Page 3]
draft-allman-ftp-variable-05.txt August 1997
In this document, any text enclosed within "<>" is informational
text that 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:
Supported network protocols (IP6)
Supported network protocols (IP4,IP6)
Similarly, if the transport protocol is not supported, the format of
the response string MUST be:
<text stating that the transport protocol is unsupported> \
(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:
<text indicating server is entering extended passive mode> \
(<d><net-prt><d><trans-prt><d><net-addr><d><trans-addr><d>)
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:
Entering Extended Passive Mode (|IP4|TCP|132.235.1.2|6446|)
The standard negative error codes 500 and 501 are sufficient to
handle all errors involving the EPSV command (e.g., syntax errors).
4. IPv6 Transition Issues
To aid in transition from IPv4 to IPv6 it is RECOMMENDED that the
network address be omitted from the EPRT command and the EPSV
Expires: February 18, 1998 [Page 4]
draft-allman-ftp-variable-05.txt August 1997
response whenever possible. This will allow the end hosts to
utilize standard IPv6 mechanisms to communicate, rather than forcing
FTP to negotiate the network protocol.
5. 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.
6. Conclusions
The extensions specified in this paper will enable FTP to operate
over a variety of network and transport protocols.
References
[AO97] Mark Allman and Shawn Ostermann. FTP Security
Considerations, August 1997. I-D
draft-allman-ftp-sec-consider-02.txt (work in progress).
[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.
Expires: February 18, 1998 [Page 5]
draft-allman-ftp-variable-05.txt August 1997
Author's Addresses:
Mark Allman
NASA Lewis Research Center/Sterling Software
21000 Brookpark Rd. MS 54-2
Cleveland, OH 44135
mallman@lerc.nasa.gov
Shawn Ostermann
School of Electrical Engineering and Computer Science
Ohio University
416 Morton Hall
Athens, OH 45701
ostermann@cs.ohiou.edu
Expires: February 18, 1998 [Page 6]