idnits 2.17.1 draft-metz-spasv-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-16) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. ** There are 81 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** The abstract seems to contain references ([Hob95], [Pis94], [Bel94], [PR85]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 9 has weird spacing: '... This docum...' == Line 13 has weird spacing: '... Drafts may b...' == Line 14 has weird spacing: '...iate to use ...' == Line 15 has weird spacing: '... Drafts as r...' == Line 20 has weird spacing: '...T) and long...' == (76 more instances...) -- 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 (January 15, 1998) is 9588 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 1579 (ref. 'Bel94') -- Possible downref: Non-RFC (?) normative reference: ref. 'Hob95' ** Downref: Normative reference to an Experimental RFC: RFC 1639 (ref. 'Pis94') Summary: 12 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Craig Metz 2 Internet Draft The Inner Net 3 draft-metz-spasv-00.txt January 15, 1998 5 Short Passive (SPASV) Command for FTP 7 Status of this Memo 9 This document is an Internet Draft. Internet Drafts are working 10 documents. 12 Internet Drafts are draft documents valid for a maximum of 6 13 months. Internet Drafts may be updated, replaced, or obsoleted by 14 other documents at any time. It is not appropriate to use Internet 15 Drafts as reference material or to cite them other than as "work in 16 progress". 18 Abstract 20 RFC 1639[Pis94] documents experimental long port (LPRT) and long 21 passive (LPSV) commands that many IP Version 6 implementations are 22 using as the replacement for the PORT and PASV commands in FTP 23 [PR85]. The author believes that this is the incorrect direction to 24 be heading and that the replacement for PORT and PASV should carry 25 less information instead of more. 27 The passive command (SPASV) is a replacement for the PASV command. 28 It only carries port numbers and does not carry addresses. This makes 29 it usable with IPv4 and IPv6. A benefit of not carrying addresses is 30 that pure network address translators (NAT) do not have to do a 31 search-and-replace on the TCP stream, which is an expensive 32 operation. This also eliminates three-way FTP, which is a rarely 33 used mode of operation that leaves most existing FTP servers wide 34 open to the FTP Bounce Attack [Hob95]. Because the FTP PORT command 35 is unfriendly to some kinds of firewall configurations [Bel94] and 36 that unfriendliness is there to support three-way FTP, there is no 37 replacement for the PORT command -- all transfers should use passive 38 mode instead. 40 The author's inet6-apps kit (available on ftp.ipv6.inner.net and 41 ftp.inner.net) includes a client and server that supports the current 42 version of these commands. Those FTP servers implement this command. 44 1. Introduction 46 The FTP protocol defines two commands that are used to control the 47 addresses and ports used for data connections. The first is the PORT 48 command, with syntax of: 50 PORT a1,a2,a3,a4,p1,p2 52 And a success response of 200. 54 The second is the PASV command, with a syntax of: 56 PASV 58 And a success response of: 60 227 Entering Passive Mode. a1,a2,a3,a4,p1,p2 62 These commands carry four bytes of address information to make a 32 63 bit IPv4 address. To carry IPv6 addresses, these commands must be 64 changed. The FOOBAR approach is to use a long port command, with a 65 syntax of: 67 LPRT af,hal,h1,h2,h3,h4...,pal,p1,p2... 69 And a success response of 200. 71 FOOBAR also defines a long passive command, with a syntax of: 73 LPSV 75 And a success response of: 77 228 Entering Long Passive Mode 78 (af, hal, h1, h2, h3,..., pal, p1, p2...) 80 The long port and long passive commands are a more flexible version 81 of the original PORT and PASV commands that can handle longer 82 addresses and port numbers. It has the same advantages and 83 disadvantages as the original design. The author's opinion is that 84 the replacements for PORT and PASV should modify this design to 85 reflect current experiences and requirements. 87 The File Transfer Protocol was designed to support a "three-way" 88 mode of operation in which a server can be directed to send a file to 89 a system other than the client. This feature is easily abused to 90 create the FTP Bounce Attack. In his paper on this attack, [Hob95] 91 rather bluntly characterizes the attack: "The mechanism used is 92 probably well-known, but to date interest in detailing or fixing it 93 seems low to nonexistent. ... It is chosen in an effort to make the 94 reader sit up and notice that there are some really ill-conceived 95 aspects of the standard FTP protocol." The fix for this attack is for 96 servers to verify that the address sent in the PORT command matches 97 the far address on the TCP control connection. Because the server's 98 TCP stack must maintain the control connection address anyway and 99 must check that the PORT argument matches, the address argument to 100 the PORT command is redundant and only serves to create extra 101 processing. 103 The address argument to the PORT command creates headaches for 104 implementors of Network Address Translators (NATs) because that 105 address information must be translated along with the addresses on 106 packets. However, unlike other addresses on packets, the PORT command 107 arguments are at the application layer, above the telnet protocol, 108 which is in turn above TCP. NATs have to re-assemble the TCP stream 109 and then decode the telnet protocol looking for the PORT command's 110 arguments. Once found, these boxen have to synthesize a new stream. 111 Changing the TCP stream, and possibly the length of the string, in 112 transit is a very expensive operation. Two alternatives to doing this 113 are: 115 1. To implement the search-and-replace in a faster but less correct 116 manner making certain assumptions (the path many existing NAT 117 implementors chose to take, and a dangerous one), which means 118 that some commands can be missed. 119 2. To not put the address information in the PORT commands. 121 The short passive command makes life much easier for those 122 implementing NATs because there is no address to be translated in 123 those commands. Also, by removing the address information from the 124 PORT commands, IPv4 and IPv6 addresses and other stream transports 125 are naturally supported. Note that a form of NAT being considered for 126 use in the transition to IPv6, the IPv6 to IPv4 translator, also 127 benefits from the short port commands. 129 There is only a short passive command and not a short port command 130 because the short port command's operation is somewhat odd in order 131 to support three-way FTP, which is eliminated in the short commands. 132 Most Internet protocols work by having a client open one or more 133 connections to a server, which then returns data. FTP using the PORT 134 command stands out as one of the few protocols that doesn't work this 135 way; the client opens one connection to the server, and the server 136 opens one or more connections back to the client. [Bel94] says about 137 this, "this connection is set up by an active open from the FTP 138 server to the FTP client. However, this scheme does not work well 139 with packet filter-based firewalls, which in general cannot permit 140 incoming calls to random port numbers." 142 2. Syntax 144 The short passive command's syntax is: 146 SPASV 148 The success response to this command is: 150 229 Entering Passive Mode. 152 Where is a printable service name in numeric form, as 153 would be returned by the IPv6 BSD API's getnameinfo() function with 154 the NI_NUMERICSERV flag set and suitable for passing to the POSIX 155 p1003.1g getaddrinfo() function. Note that for IP versions 4 and 6, 156 this will be the string representation of a decimal number between 157 one and 65535. 159 The failure responses to this command are the same as for the PASV 160 command in FTP. 162 3. Security Considerations 164 This document describes a protocol extension that, among other 165 things, designs away a security hole in the current FTP protocol 166 known as the FTP Bounce Attack and is more friendly to some kinds of 167 firewall configurations. This extension is believed by the author to 168 otherwise have the same security properties as the protocol commands 169 (PORT and PASV) it replaces. 171 Acknowledgments 173 This work was done at the Center for High Assurance Computer 174 Systems at the U.S. Naval Research Laboratory. This work was 175 sponsored by the Information Security Program Office (PMW-161), U.S. 176 Space and Naval Warfare Systems Command (SPAWAR) and the Computing 177 Systems Technology Office, Defense Advanced Research Projects Agency 178 (DARPA/CSTO). The author and his co-workers really appreciates their 179 sponsorship of NRL's network security efforts and their continued 180 support of IPsec development. Without that support, this document, 181 among many others, would not exist. 183 Mike Allman suggested replacing the FTP-style decimal ports that 184 were used in an earlier version of this draft with a more protocol- 185 independent value. 187 D. J. Bernstein pointed out that only passive mode is needed if 188 three-way FTP is eliminated. 190 References 192 [Bel94] S. Bellovin, "Firewall-Friendly FTP", RFC 1579, February 193 1994. 195 [Hob95] "*Hobbit*", "The FTP Bounce Attack", July 1995. 196 (ftp.avian.org:/random/ftp-attack) 198 [Pis94] D. Piscitello, "FTP Operation Over Big Address Records 199 (FOOBAR)", RFC 1639, June 1994. 201 [PR85] J. Postel and J. Reynolds, "File Transfer Protocol (FTP)", 202 RFC 959, October 1985. 204 Disclaimer 206 The views and specification here are those of the author and are 207 not necessarily those of his employer. His employer has not passed 208 judgment on the merits, if any, of this work. The author and his 209 employer specifically disclaim responsibility for any problems 210 arising from correct or incorrect implementation or use of this 211 specification. 213 Author's Address 215 Craig Metz 216 The Inner Net 217 Box 10314-1933 218 Blacksburg, VA 24062-0314 219 Phone: (DSN) 354-8590 220 E-mail: cmetz@inner.net