idnits 2.17.1 draft-rosenau-ftp-single-port-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 354. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 365. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 372. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 378. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 170: '... The identifier MUST NOT contain pare...' RFC 2119 keyword, line 173: '...formational text MUST NOT contain pare...' RFC 2119 keyword, line 206: '... The server SHOULD be prepared to...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 18, 2008) is 5699 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 1545 (ref. '2') (Obsoleted by RFC 1639) Summary: 7 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT M. Rosenau 2 Expires: March 18, 2009 September 18, 2008 3 Category: Experimental 5 FTP EXTENSION ALLOWING IP FORWARDING (NATs) 6 8 Status of this Memo 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on March 18, 2009. 33 Copyright Notice 35 Copyright (C) The IETF Trust (2008). 37 Abstract 39 The FTP protocol [1] needs two connections. A control and a data 40 connection. Using networks with "port forwarding" (eg. SSH, DSL 41 routers, VPN etc.) there is often only the possibility for the 42 server to listen on only one TCP port. In such networks the 43 traditional FTP protocol cannot be used. 45 This memo describes an extension to the FTP protocol that allows the 46 use of FTP using only one TCP port number for both control 47 connections and passive-mode data connections. 49 The extension can also be used to use the FTP protocol over network 50 protocols that do not have a "port" concept (such as the NetBIOS 51 protocol). 53 Changes in version "-01" 55 - The SPDT command was no longer proposed. Instead a method using 56 a special user name and password is proposed. 58 - The data returned by SPSV is only valid for one connection. This 59 is necessary for better resource management within the FTP server. 60 version-00 did not clarify this. 62 - Spelling or grammar mistakes were corrected and unclear statements 63 were replaced. 65 Change in version "-02" 67 - Added chapter 6 about implementation issues. 69 Change in version "-03" 71 - Fixed a mistake in chapter 6 73 Changes in version "-04" 75 The changes in version "-04" are done because of comments of a 76 third party: 78 - Changed back to the SPDT variant no longer proposing the method 79 using a special user name and password. 81 - Added chapter 7 about security issues. 83 Changes in this version 85 - Changed "user name and password" to "identifier" in chapter 86 3 because the "SPDT" variant is used instead of a "USER" 87 based variant. 89 - Changed many language, grammar, terms, ... due to a third 90 party review 92 1. INTRODUCTION 94 To transfer data via FTP [1] you need two connections: A control 95 connection and a data connection. 97 In traditional FTP there are two methods to establish the data 98 connection: 100 1) The active method: The server establishes the data connection; 101 the client must send its address to the server and listen on a 102 TCP port. 104 2) The passive method: The server sends its address (including 105 the TCP port number) to the client, which establishes the 106 connection. 108 The active method requires that the client can listen for incoming 109 connections and that the server can establish a connection to the 110 client. The client must know its own address as it is seen by the 111 server. This is not the case when the client is behind a 112 firewall [3]. 114 The passive method requires the server to be able to listen for 115 incoming TCP connections on a second port and to know its own IP 116 address. If the server is behind a NAT firewall with TCP port 117 forwarding this is often not the case. 119 Both variants do originally only work with IPv4; FTP using other 120 network protocols requires special extensions such as the "EPRT" [4] 121 or the "LPRT" [2] command. Both extensions do not work with 122 protocols that do not have a "port" concept (such as NetBIOS). 124 This draft describes an extension to the FTP protocol that allows 125 using FTP with TCP port forwarding ("IP forwarding") or network 126 protocols that do not have a "port" concept. 128 2. OVERVIEW 130 The reason for the problems described above is the fact that either 131 the server or the client must know its own transport address 132 (IP address AND port number) and tell it to the other side. 133 The server needs a second transport address (port) if using passive 134 mode. This can be a problem when using TCP port forwarding. (Note 135 that in this case neither of the two computers knows its own 136 address and port number.) 138 The extension proposed here allows the server to use the same 139 transport address (port) for passive mode data connections as it 140 is used for the control connection. 142 To establish a data connection, the client establishes a second 143 connection to the same port that is used for the control connection 144 and tells the server that it desires to establish a data connection. 146 Because the client already knows the transport address of the 147 control connection (it would not have been able to connect 148 otherwise) neither the server nor the client need to know their own 149 transport addresses. 151 3. EXTENSION COMMANDS ADDED 153 3.1. USE SINGLE PORT PASSIVE MODE ("SPSV" proposed) 155 Command syntax: 157 "SPSV" CRLF 159 This command is sent by the client to indicate that it wants 160 to use the method described in this document to establish a 161 data connection. The command has no parameter. 163 If the command succeeds the server will reply 165 "227" SP any informational text "(" identifier ")" CRLF 167 The identifier in parentheses is used to establish a data 168 connection using the "SPDT" command described later. 170 The identifier MUST NOT contain parentheses, colons or 171 characters above 126 or below 33. The identifier must not be 172 longer than 32 characters. The identifier is case-sensitive. 173 The informational text MUST NOT contain parentheses. 175 Unlike the "PASV" command the data replied to "SPSV" is only 176 valid for one data connection. After establishing a data 177 connection "SPSV" must be sent again to get a new identifier 178 before establishing a new data connection. This is necessary 179 to allow the server to implement the "Service not ready" 180 behaviour as it is described below. 182 3.2. ESTABLISHING A DATA CONNECTION ("SPDT" proposed) 184 Command syntax: 186 "SPDT" SP identifier CRLF 188 This command is the only command sent over the connection 189 dedicated to become the data connection. It is sent instead 190 of a "USER" command. 192 The argument is the identifier received in the answer to the 193 "use singe port passive mode" command. 195 If the server accepted the command it returns EXACTLY the 196 following sequence: 198 "200" SP "DATA" CR LF 200 After transmitting this sequence the former control connection 201 becomes the new data connection. 203 If the identifier was not correct the server returns a reply 204 with the code 504 and drops the TCP connection. 206 The server SHOULD be prepared to accept the command instead of 207 the "PASS" command or directly after the "PASS" command because 208 some FTP proxy servers require sending an USER/PASS combination 209 before establishing a connection. 211 4. EXAMPLE TRANSMISSION SCENARIO 213 (Each line in the following scenario ends with a CRLF sequence that 214 is not written because of better readability.) 216 - The control connection ("--1-->") is established. 217 S--1-->C 220 FTP server ready 218 C--1-->S USER u001 219 S--1-->C 331 Enter password 220 C--1-->S PASS xyz 221 S--1-->C 230 You are logged in 222 C--1-->S SPSV 223 S--1-->C 227 Entering single-port mode (xYab1234) 224 - The data connection ("---2->") is established 225 S---2->C 220 FTP server ready 226 C---2->S SPDT xYab1234 227 S---2->C 200 DATA 228 C--1-->S RETR example.file 229 S--1-->C 150 Transmitting data 230 S---2->C (Contents of example.file (not followed by CRLF)) 231 - The server closes the data connection ("---2->") 232 S--1-->C 226 Data transferred 233 ... 235 5. THE "SERVICE NOT READY" MESSAGE 237 If there are too many control connections open many FTP servers deny 238 new users to connect to the server. The server sends the following 239 message: 240 "120 Too many users connected. Try later." CRLF 241 and drops the connection. 243 If a client sent an "SPSV" command but did not establish a data 244 connection, yet, this is not possible. In this case the following 245 behaviour is proposed (CRLF not shown here): 246 <--- 220 Too many users; only SPSV connections allowed 247 ---> SPDT xYz1234 248 <--- 200 DATA 249 or with a real user name: 250 <--- 220 Too many users; only SPSV connections allowed 251 ---> USER u001 252 <--- 421 Too many users connected. Try later. 254 6. POSSIBLE IMPLEMENTATION 256 In many implementations a new process is started everytime a 257 connection to the FTP service port is opened. The "inetd" service 258 on UNIX operating systems is an example for this behavior. 260 Adding the "SPSV" option to existing FTP server programs may be 261 done by implementing two extensions: 263 Extension behavior on SPSV: 264 The "SPSV" command behaves like the "PASV" command with the 265 exception that the format of the response is different. Example: 266 --> SPSV 267 (Server is actually doing "PASV"; TCP port is 12345 in this 268 example; the response differs from "PASV":) 269 <-- 227 Entering single-port mode (12345) 271 Extension behaviour on SPDT: 272 The SPDT command is used to create a tunneling connection to a 273 port number given in the argument. Example: 274 <-- 220 FTP server ready 275 --> SPDT 80 276 (Server tries to establish a connection to localhost:80 277 which is actually the HTTP server) 278 <-- 200 DATA 279 (Server is simply "tunneling" the data between the two 280 TCP connections) 281 --> GET /index.html HTTP/1.0 282 --> 283 <-- HTTP/1.0 200 OK 284 <-- Content-type: text/html 285 <-- 286 <-- 287 <-- Hello world! 288 <-- 290 This simple way of implementing the extensions would make it easy to 291 bypass server security systems such as firewalls. To avoid this such 292 an implementation should first check if the port number given by the 293 "SPDT" argument really is used by the FTP service. 295 7. SECURITY ISSUES 297 This extension can be combined with any other FTP extension. 298 Therefore all security extensions of FTP can be combined with this 299 extension. 301 Extensions that normally would transfer data over the data 302 connection after it has been established will transfer their data 303 after receiving the "200 DATA" CRLF characters. 305 When using an implementation that is based on tunneling (as 306 described in chapter 6) the process receiving a "SPDT" command 307 should not allow a tunneling connection to a non-FTP process. 308 Using non-TCP/IP connections (e.g. AF_UNIX) for tunneling could make 309 this easier. 311 The "identifier" should contain information that is really needed 312 for establishing the connection (such as the port number in the 313 example in chapter 6) as well as a random number cookie that is used 314 to verify if the identifier is really valid. The SPDT command will 315 check if the random number part in the identifier matches the one 316 generated by the SPSV command. 318 The port number should also not be included directly in the 319 identifier but it should only be transferred encrypted or indirectly 320 (e.g. file name of a temporary file containing the port number). 321 The "file name" variant would also ensure that SPDT can only tunnel 322 FTP connections (and not HTTP connections as shown in chapter 6.) 324 REFERENCES 326 [1] FILE TRANSFER PROTOCOL (FTP), RFC 959 327 [2] FTP Operation Over Big Address Records, RFC 1545 328 [3] Firewall-Friendly FTP, RFC 1579 329 [4] FTP Extensions for IPv6 and NATs, RFC 2428 331 Author's Address 333 Martin Rosenau 334 Johannes Schuster Weg 14 335 76185 Karlsruhe 336 Germany 338 Email: martin@rosenau-ka.de 340 Full Copyright Statement 342 Copyright (C) The IETF Trust (2008). 344 This document is subject to the rights, licenses and restrictions 345 contained in BCP 78, and except as set forth therein, the authors 346 retain all their rights. 348 This document and the information contained herein are provided on an 349 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 350 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 351 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 352 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 353 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 354 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 356 Intellectual Property 358 The IETF takes no position regarding the validity or scope of any 359 Intellectual Property Rights or other rights that might be claimed to 360 pertain to the implementation or use of the technology described in 361 this document or the extent to which any license under such rights 362 might or might not be available; nor does it represent that it has 363 made any independent effort to identify any such rights. Information 364 on the procedures with respect to rights in RFC documents can be 365 found in BCP 78 and BCP 79. 367 Copies of IPR disclosures made to the IETF Secretariat and any 368 assurances of licenses to be made available, or the result of an 369 attempt made to obtain a general license or permission for the use of 370 such proprietary rights by implementers or users of this 371 specification can be obtained from the IETF on-line IPR repository at 372 http://www.ietf.org/ipr. 374 The IETF invites any interested party to bring to its attention any 375 copyrights, patents or patent applications, or other proprietary 376 rights that may cover technology that may be required to implement 377 this standard. Please address the information to the IETF at 378 ietf-ipr@ietf.org.