INTERNET-DRAFT M. Rosenau Expires: August 19, 2008 February 19, 2008 Category: Experimental FTP EXTENSION ALLOWING IP FORWARDING (NATs) Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 19, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Rosenau FTP extension for IP forwarding [Page 1] Abstract The FTP protocol [1] needs two connections. A control and a data connection. Using networks with "port forwarding" (eg. SSH, DSL routers, VPN etc.) there is often only the possibility for the server to listen on only one TCP port. In such networks the traditional FTP protocol cannot be used. This memo describes an extension to the FTP protocol that allows the use of FTP using only one TCP port number for both control connections and passive-mode data connections. The extension can also be used to use the FTP protocol over network protocols that do not have a "port" concept (such as the NetBIOS protocol). Changes to version "-00" - The SPDT command is no longer proposed. Instead the method using a special user name and password is proposed. - The data returned by SPSV is only valid for one connection. This is necessary for better resource management within the FTP server. version-00 did not clarify this. - Spelling or grammar mistakes were corrected and unclear statements were replaced. Change to version "-01" - Added chapter 6 Rosenau FTP extension for IP forwarding [Page 2] 1. INTRODUCTION To transfer data via FTP [1] you need two connections: A control connection and a data connection. In traditional FTP there are two methods to establish the data connection: 1) The active method: The server establishes the data connection; the client must send its address to the server and listen on a TCP port. 2) The passive method: The server sends its address (including the TCP port number) to the client, which establishes the connection. The active method requires that the client can listen for incoming connections and that the server can establish a connection to the client. The client must know its own address as it is seen by the server. This is not the case when the client is behind a firewall [3]. The passive method requires the server to be able to listen for incoming TCP connections on a second port and to know its own IP address. If the server is behind a NAT firewall with TCP port forwarding this is often not the case. Both variants do originally only work with IPv4; FTP using other network protocols requires special extensions such as the "EPRT" [4] or the "LPRT" [2] command. Both extensions do not work with protocols that do not have a "port" concept (such as NetBIOS). This draft describes an extension to the FTP protocol that allows using FTP with TCP port forwarding ("IP forwarding") or network protocols that do not have a "port" concept. Rosenau FTP extension for IP forwarding [Page 3] 2. OVERVIEW The reason for the problems described above is the fact that either the server or the client must know its own network address (this includes the port number when using TCP) and tell it to the other side. The server needs a second address (in the case of TCP a second port) if using passive mode. This can be a problem when using TCP port forwarding. (Note that in this case neither of the two computers knows its own port number.) The extension proposed here allows the server to use the same address (and port number) for a passive mode data connection as it is used for a control connection. To establish the data connection the client establishes a second connection to the same port that is used for the control connection and tells the server that it desires to establish a data connection. Because the client already knows the address and port number of the control connection (it would not have been able to connect otherwise) neither the server nor the client need to know its own address nor its port number. Rosenau FTP extension for IP forwarding [Page 4] 3. EXTENSION COMMAND ADDED USE SINGLE PORT PASSIVE MODE ("SPSV" proposed) This command is sent by the client to indicate that it wants to use the method described in this document to establish a data connection. The command has no parameter. If the command succeeds the server will reply 227 Any informational text (UserName:Password) The user name and the password in brackets are used to establish a data connection. An implementation may use a common user name for all data connections and the password as a connection identifier that will identify this control connection. Unlike the "PASV" command the data replied by "SPSV" is only valid for one data connection. After establishing a data connection "SPSV" must be sent again to get a new identifier before establishing a new data connection. This is necessary to allow the server to implement the "Service not ready" behaviour as it is described below. The user name SHOULD only include letters (A-Z) and digits (0-9). It MUST NOT contain brackets, colons or characters above 126 or below 33. The user name must not be longer than 32 characters. The same is true for the password. The user name SHOULD be considered as case-insensitive by the server and as case-sensitive by the client. The password is case-sensitive. Rosenau FTP extension for IP forwarding [Page 5] ESTABLISHING A DATA CONNECTION When a client wants to establish a data connection it establishes a second control connection and uses the user name and password returned by "SPSV". The "PASS" command does NOT return the return code 230 on success but it returns EXACTLY the following sequence: 200DATA After transmitting this sequence the control connection becomes the new data connection. If there was an error the server behaves just like in the case of a failed login. This means it will reply 504 and drop the TCP connection. 4. EXAMPLE TRANSMISSION SCENARIO - The control connection ("--1-->") is established. S--1-->C 220 FTP server ready C--1-->S USER u001 S--1-->C 331 Enter password C--1-->S PASS xyz S--1-->C 230 You are logged in C--1-->S SPSV S--1-->C 227 Entering single-port mode (DATACONN:007aB) - The data connection ("---2->") is established S---2->C 220 FTP server ready C---2->S USER DATACONN S---2->C 331 Preparing for a data connection C---2->S PASS 007aB S---2->C 200 DATA C--1-->S RETR contents.txt S--1-->C 150 Transmitting data S---2->C (Contents of contents.txt) - The server closes the data connection S--1-->C 226 Data transferred ... Rosenau FTP extension for IP forwarding [Page 6] 5. THE "SERVICE NOT READY" MESSAGE If there are too many control connections open many FTP servers deny new users to connect to the server. The server sends the following message: 120 Too many users connected. Try later. and drops the connection. If a client sent an "SPSV" command but did not establish a data connection, yet, this is not possible. In this case the following behaviour is proposed: <--- 220 Too many users; only SPSV connections allowed ---> USER DATACONN <--- 331 Preparing for a data connection or with a real user name: <--- 220 Too many users; only SPSV connections allowed ---> USER u001 <--- 421 Too many users connected. Try later. 6. POSSIBLE IMPLEMENTATION In many implementations a new process is started everytime a connection to the FTP service port is opened. The "inetd" service on UNIX operating systems is an example for this behavior. Adding the "SPSV" option to existing FTP server programs may be done by implementing two extensions: Extension 1) The "SPSV" command behaves like the "PASV" command with the exception that the format of the response is different. Example: --> SPSV (Server is actually doing "PASV"; TCP port is 12345 in this example; the response differs from "PASV":) <-- 227 Entering single-port mode (DATACONN:12345) Rosenau FTP extension for IP forwarding [Page 7] Extension 2) The "DATACONN" user (may be any other user name) is used to create a tunneling connection to a port number given in the password. Example: <-- 220 FTP server ready --> USER DATACONN <-- 331 Preparing for a data connection --> PASS 80 (Server tries to establish a connection to localhost:80 which is the HTTP server) <-- 200 DATA (Server is simply "tunneling" the data between the two TCP connections) --> GET /index.html <-- HTTP/1.0 200 OK <-- Content-type: text/html <-- <-- <> <-- Hello world! <-- <> This simple way of implementing the extensions would make it easy to bypass server security systems such as firewalls. To avoid this the implementation should first check if the port number given by the "PASS" argument really is used by the FTP service. This may be done using a file or multiple files containing a list of all FTP ports currently waiting for a passive mode connection. The use of name- based network protocols (such as AF_UNIX or AF_NETBIOS) instead of TCP for "SPSV" could also be a possibility. "PASS 80" would name the network address AF_UNIX,"/tmp/ftp/80", not AF_INET,"localhost:80" or it names the file "/tmp/ftp/80" that contains the actual TCP port number (which is different from 80). REFERENCES [1] FILE TRANSFER PROTOCOL (FTP), RFC 959 [2] FTP Operation Over Big Address Records, RFC 1545 [3] Firewall-Friendly FTP, RFC 1579 [4] FTP Extensions for IPv6 and NATs, RFC 2428 AUTHOR'S ADDRESS Martin Rosenau Johannes Schuster Weg 14 76185 Karlsruhe Germany Email: martin@rosenau-ka.de Rosenau FTP extension for IP forwarding [Page 8] Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Rosenau FTP extension for IP forwarding [Page 9]