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-02
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.
EPSV translation can be applied to all forms of IPv6-to-IPv4
translation, including stateless translation such as [RFC2765] and
statefull translation such as [I-D.bagnulo-behave-nat64]. For EPRT
translation and operation using the default port there are some
differences between stateless and stateful translation.
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 (or EPSV 2 to indicate IPv6
as the network protocol), 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.
If the client issues an EPSV command with a numeric argument other
than 2, the ALG MUST NOT pass the command on to the server, but
rather respond with a 522 error.
If the client issues EPSV ALL, the FTP ALG MUST NOT pass this command
to the server, but respond with:
202 Command not implemented.
This avoids the situation where an FTP server may react adversely to
receiving a PASV command after the client indicated that it will only
use EPSV during this session.
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. The translation is
different depending on whether the translator is a stateless one-to-
one translator or a stateful one-to-many translator.
5.1. Stateless EPRT translation
If the address specified in the EPRT command is the client's IPv6
address, then the FTP ALG reformats the EPRT command into a PORT
command with the IPv4 address that maps to the client's IPv6 address.
The port number MUST be preserved.
If the address specified in the EPRT command is an IPv6 address also
served by a translator, for which the FTP ALG knows the corresponding
IPv4 address, the FTP ALG reformats the EPRT command into a PORT
command with that IPv4 address. The port number MUST be preserved.
If the address specified in the EPRT command is an IPv6 address for
which the FTP ALG doesn't know a corresponding IPv4 address, the EPSV
command is relayed to the server unchanged. The port number MUST be
preserved.
If the address specified in the EPRT command is an IPv4 address, the
FTP ALG reformats the EPRT command into a PORT command using the
supplied IPv6 address and port number.
van Beijnum Expires October 29, 2009 [Page 4]
Internet-Draft An FTP64 ALG April 2009
5.2. Stateful EPRT translation
If the address in the EPRT command is an IPv6 address within the
range that the translator is prepared to serve, which includes the
case where the IPv6 address is the control channel client's address,
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 with
the IPv4 address and port used on the IPv4 side of the mapping 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.
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.
If 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.
6. Default port 20 translation
If the client doesn't issue an EPSV or EPRT command, it is invoking
the default active FTP behavior where the server sets up a TCP
session towards the default FTP data port (port 20). In the case of
a stateless translator, this doesn't pose any problems.
In the case of a stateless translator, it would be impossible to map
incoming sessions from the IPv4 FTP server to the correct IPv6 host
if multiple IPv6 hosts have sessions with the same FTP server at the
same time. This is solved by issuing a PORT command from the FTP ALG
to the client whenever the client initiates a transfer without first
issuing an EPSV or PASV command.
In order to detect the case where the client depends on the default
port 20 behavior, the FTP ALG tracks whether the client has issued
either an EPSV (not including ESPV ALL) or EPRT command since the
start of the control channel session. If so, it is assumed that all
transfers will be accompanied by either of these commands and no
further action is taken. However, if no EPSV or EPRT command has
been issued since the start of the control channel session, and the
van Beijnum Expires October 29, 2009 [Page 5]
Internet-Draft An FTP64 ALG April 2009
client issues one of the following commands:
RETR, STOR, STOU, APPE, LIST, NLST
The FTP ALG doesn't immediately pass the command on to the server.
Instead, the translator reserves a transport address and sets up a
mapping from this transport address to port 20 on the IPv6 address
used by the client in the control channel session. Once the mapping
is created, the FTP ALG issues a PORT command to the FTP server with
the reserved transport address as the argument. The response to the
PORT command is not propagated to the client. After this, the
command originally issued by the client is propagated to the server.
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. After the session
has been completed or times out, the mapping is removed.
Note that the default port 20 is less robust than the EPSV or EPRT
cases, as some errors aren't communicated back to the client.
However, the situation where an FTP client doesn't issue the EPSV or
EPRT commands must be considered a corner case and is likely to
trigger FTP server bugs, incomplete FTP tracking implementations in
firewalls and firewalling in general, and can't be expected to work
reliably in today's environment.
7. 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.
Whenever a command from the client isn't propagated to the server,
the FTP ALG instead issues a NOOP command in order to keep the
keepalive state between the client and the server synchronized. The
response to the NOOP command is not sent back to the client.
8. IANA considerations
None.
van Beijnum Expires October 29, 2009 [Page 6]
Internet-Draft An FTP64 ALG April 2009
9. 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.
10. References
10.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.
[RFC2428] Allman, M., Ostermann, S., and C. Metz, "FTP Extensions
for IPv6 and NATs", RFC 2428, September 1998.
10.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.
van Beijnum Expires October 29, 2009 [Page 7]
Internet-Draft An FTP64 ALG April 2009
Appendix A. Acknowledgement
Kentaro Ebisawa and Remi Denis-Courmont provided useful comments.
Iljitsch van Beijnum is partly funded by Trilogy, a research project
supported by the European Commission under its Seventh Framework
Program.
Appendix B. 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 mailinglist or directly to the author.
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 8]