Behavior Engineering for Hindrance I. van Beijnum Avoidance IMDEA Networks Internet-Draft April 27, 2009 Expires: October 29, 2009 An FTP Application Layer Gateway for IPv6-to-IPv4 translation draft-van-beijnum-behave-ftp64-01 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 October 29, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract The only FTP mode that works without changes through an IPv6-to-IPv4 translator is extended passive, introduced in 1998. However, many existing FTP servers don't support this mode, making it impossible to van Beijnum Expires October 29, 2009 [Page 1] Internet-Draft An FTP64 ALG April 2009 support the File Transfer Protocol through an IPv6-to-IPv4 translator without an Application Layer Gateway. This document describes the behavior of such an ALG. 1. Introduction [RFC0959] specifies two modes of operation for FTP: active mode, in which the server connects back to the client on port 20 or a client- provided port number, and passive mode, where the server opens a port for the client to connect to. Without additional action, active mode doesn't work through NATs or firewalls. And in both cases, an IPv4 address is specified, making both modes incompatible with IPv6. These issues were solved in [RFC2428], which specifies the EPSV (extended passive) mode that only specifies a port number and the EPRT (extended port) command which allows the client to supply an IPv6 address to the server. A survey done by the author in April of 2009 of 25 randomly picked and/or well-known FTP sites reachable over IPv4 showed that only 12 of them supported EPSV over IPv4. Additionally, only 2 of those 12 indicated that they supported EPSV in response to the FEAT command ([RFC2389]), while one supported EPSV but not FEAT. In 5 cases, issuing the EPSV command to the server led to a significant delay, in 3 cases followed by a control channel reset. It appears that in these cases, the server did support EPSV but a middlebox didn't. All 25 servers were able to successfully complete a transfer in PASV mode as required by [RFC1123]. Based on the survey, an FTP ALG should be considered a necessary part of any [I-D.bagnulo-behave-nat64] deployment. Since all servers in the survey supported PASV passive mode, implementers of IPv6-to-IPv4 translators SHOULD implement EPSV to PASV translation, and SHOULD perform this translation for all EPSV commands issued by a client. Implementers of IPv6-to-IPv4 translators that maintain state MAY also implement EPRT to PORT translation. However, as many hosts reside behind firewalls, often unbeknownst to the FTP clients running on those hosts, active FTP is relatively likely to fail with or without translation. The EPRT translation specified in this document applies to stateful IPv6-to-IPv4 translators such as [I-D.bagnulo-behave-nat64]. However, EPSV translation may apply to all forms of IPv6-to-IPv4 translation, including [RFC2765] van Beijnum Expires October 29, 2009 [Page 2] Internet-Draft An FTP64 ALG April 2009 2. Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Control channel translation The IPv6-to-IPv4 FTP ALG intercepts all TCP sessions towards IPv4 port 21 destinations. The FTP ALG implements the Telnet protocol ([RFC0854]) used for control channel interactions to the degree necessary to interpret commands and responses and re-issue those commands and responses, modifying them as outlined below. Option negotiation attempts by either the client or the server, except for those allowed by [RFC1123], SHOULD be rejected by the FTP ALG without relaying those attempts. This avoids the situation where the client and the server negotiate options unknown to the FTP ALG. If the client issues the AUTH command and the server responds with code 234 or 334, the client and server are negotiating [RFC2228] security mechanisms which are likely to be incompatible with the FTP ALG function. In this situation, the FTP ALG MUST switch to transparently fowarding all data on the control channel in both directions until the end of the control channel session. 4. EPSV to PASV translation Although many IPv4 FTP servers support the EPSV command, some servers react adversely to this command, and there is no reliable way to detect in advance that this will happen. As such, an FTP ALG SHOULD translate all occurrences of the EPSV command issued by the the client to the PASV command, and reformat a 227 response as a corresponding 229 response. For instance, if the client issues EPSV, this is translated to the PASV command. If the server with address 192.0.2.31 then reponds with: 227 Entering Passive Mode (192,0,2,31,237,19) The FTP ALG reformats this as: 229 Entering Extended Passive Mode (|||60691|) If the server's 227 response contains an IPv4 address that doesn't match the destination of the control channel, the FTP ALG SHOULD send van Beijnum Expires October 29, 2009 [Page 3] Internet-Draft An FTP64 ALG April 2009 the following response to the client: 425 Can't open data connection. It is important that the response is in the 4xx range to indicate a temporary condition. 5. EPRT to PORT translation Should the IPv6 client issue an EPRT command, the FTP ALG MAY translate this EPRT command to a PORT command. In that case, there are three possibilities: 1. The address specified in the EPRT command is the client's IPv6 address 2. The address specified in the EPRT command is an IPv6 address that isn't the client's address 3. The address specified in the EPRT command is an IPv4 address In the first case, and in the second case if the address in the EPRT command is an IPv6 address within the range that the translator is prepared to serve, the stateful translator selects an unused port number in combination with the IPv4 address used for the control channel towards the FTP server, and sets up a mapping from that transport address to the one specified by the client in the EPRT command. The PORT command is only issued towards the server once the mapping is created. Initially, the mapping is such that either any transport address or the FTP server's IPv4 address with any port number is accepted as a source, but once the three-way handshake is complete, the mapping is narrowed to only match the negotiated TCP session. In the second case, if the address in the EPRT command is an IPv6 address that the translator is not prepared to translate for, the EPRT command is passed along to the server unmodified. In the third case, where the address in the EPRT command is an IPv4 address, the FTP ALG reformats the EPRT command to the equivalent PORT command without changing the transport address. In these cases, the translator doesn't create a mapping. This behavior retains compatibility with the server-to-server transfer option in FTP. Note that there is the corner case where the client doesn't specify either EPSV or EPRT because it wants to use active FTP on the default port. This case isn't handled and will result in failure. van Beijnum Expires October 29, 2009 [Page 4] Internet-Draft An FTP64 ALG April 2009 6. Timeouts Wherever possible, control channels SHOULD NOT time out while there is an active data channel. A timeout of at least 30 seconds is recommended for mappings created by the FTP ALG that are waiting for initial packets. 7. IANA considerations None. 8. Security considerations In the majority of cases, FTP is used without further security mechanisms. This allows a passive attacker to obtain the login credentials, and an attacker that can modify packets to change the data transferred. However, FTP can be used with TLS in order to solve these issues. IPv6-to-IPv4 translation and the FTP ALG don't impact the security issues in the former case nor the use of TLS in the latter case. However, if FTP is used with TLS or another authentication mechanism, the ALG function is not performed so only passive transfers from a server that implements EPSV will succeed. 9. References 9.1. Normative References [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983. [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985. [RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2389] Hethmon, P. and R. Elz, "Feature negotiation mechanism for the File Transfer Protocol", RFC 2389, August 1998. [RFC2228] Horowitz, M., "FTP Security Extensions", RFC 2228, October 1997. van Beijnum Expires October 29, 2009 [Page 5] Internet-Draft An FTP64 ALG April 2009 [RFC2428] Allman, M., Ostermann, S., and C. Metz, "FTP Extensions for IPv6 and NATs", RFC 2428, September 1998. 9.2. Informative References [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000. [I-D.bagnulo-behave-nat64] Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", draft-bagnulo-behave-nat64-03 (work in progress), March 2009. Appendix A. Document and discussion information The latest version of this document will always be available at http://www.muada.com/drafts/. Please direct questions and comments to the BEHAVE mailinglists or directly to the author. Appendix B. Acknowledgement Iljitsch van Beijnum is partly funded by Trilogy, a research project supported by the European Commission under its Seventh Framework Program. Author's Address Iljitsch van Beijnum IMDEA Networks Avda. del Mar Mediterraneo, 22 Leganes, Madrid 28918 Spain Email: iljitsch@muada.com van Beijnum Expires October 29, 2009 [Page 6]