Subject: [BEHAVE] Last Call: <draft-ietf-behave-ftp64-10.txt> (An FTP ALG for IPv6-to-IPv4 translation) to Proposed Standard

From: The IESG <[email-masked]>
Date: Fri, 20 May 2011 15:48:13 -0700

The IESG has received a request from the Behavior Engineering for
Hindrance Avoidance WG (behave) to consider the following document:
- 'An FTP ALG for IPv6-to-IPv4 translation'
  <draft-ietf-behave-ftp64-10.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2011-06-03. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   The File Transfer Protocol (FTP) has a very long history, and despite
   the fact that today, other options exist to perform file transfers,
   FTP is still in common use.  As such, it is important that in the
   situation where some client computers only have IPv6 connectivity
   while many servers are still IPv4-only and IPv6-to-IPv4 translators
   are used to bridge that gap, FTP is made to work through these
   translators as best it can.

   FTP has an active and a passive mode, both as original commands that
   are IPv4-specific, and as extended, IP version agnostic commands.
   The only FTP mode that works without changes through an IPv6-to-IPv4
   translator is extended passive.  However, many existing FTP servers
   do not support this mode, and some clients do not ask for it.  This
   document specifies a middlebox that may solve this mismatch.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-behave-ftp64/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-behave-ftp64/

The following IPR Declarations may be related to this I-D:

   http://datatracker.ietf.org/ipr/1322/

IPR has been disclosed and announced to the mailing list,
https://datatracker.ietf.org/ipr/search/?option=document_search&document_sea
rch=draft-ietf-behave-ftp64
and there has been no subsequent WG discussion about this IPR disclosure.

---

From: Pekka Savola <[email-masked]>
Date: Mon, 30 May 2011 12:10:23 +0300 (EEST)

>  <draft-ietf-behave-ftp64-10.txt> as a Proposed Standard

This is an ops-dir review of draft-ietf-behave-ftp64-10.

I do not find major issues in the document.  This is a somewhat complex
document and I would have hoped that the spec could have been more
straightforward and the result is some 50 MUSTs, SHOULDs and MAYs.
But I suppose FTP legacy cases and implementations etc. make it a
difficult protocol to support in the real life.

substantial comments
--------------------

The document does not mention or discuss LPRT and LPSV. Is that intentional?
The IANA registry says these are now obsolete, but RFC1639 is still
experimental and no document has (formally) obsoleted these.

S 5:

    Telnet option negotiation attempts by either the client or the
    server, except for those allowed by [RFC1123], MUST be rejected by
    the FTP ALG without relaying those attempts.  This avoids the
    situation where the client and the server negotiate Telnet options
    that are unimplemented by the FTP ALG.

... what does "rejected" mean exactly?  Does the ALG send back to
the negotiation attempter some error code?  Does it abort the connection?
ignore these options?  strip them out when connecting to the other end?

8. Default port 20 translation

    If the client does not issue an EPSV/PASV or EPRT/PORT command prior
    to initiating a file transfer, it is invoking the default active FTP
    behavior where the server sets up a TCP session towards the client.
    In this situation, the source port number is the default FTP data
    port (port 20) and the destination port is the port the client uses
    as the source port for the control channel session.

.. is it?  I thought the source port used by the server is orthogonal to
whether pasv/port is issued.  AFAIK, multiple FTP server implementations
never use port 20.  But I have not recently tested this myself.

    The ALG MUST enable or disable EPSV to PASV translation as requested.
    If EPRT to PORT translation is supported, ALGS ENABLE64 SHOULD enable
    it and ALGS DISABLE64 SHOULD disable it along with enabling or
    disabling EPSV to PASV translation, respectively.  If EPRT to PORT
    translation is not supported, ALGS ENABLE64 only enables EPSV to PASV
    translation.

.. what does this SHOULD..along with.. mean?  I read it so that it's OK
that for "ALGS DISABLE64" EPSV->PASV is disabled but EPRT->PORT is not
disabled?  A different way to read it would be that both EPSV->PASV and
EPRT->PORT are SHOULDs.

editorial:
----------

    A survey done 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.

.. fwiw, Dan Wing redid this test on 18 May 2011, reporting on behave list.
the results didn't differ much (I didn't look at the numbers), but if you
want to update this, now would be the chance.

  If
    such a multi-purpose ALG forbids the use of the AUTH command for
    policy reasons, the side effect of making the ALG stop performing the
    translations described here, as well as other possible interventions
    related to IPv6-to-IPv4 translation, MUST be retained even if the ALG
    responds to the AUTH command with an error and does not propagate the
    command to the server.

.. I had a hard time following what this one sentence includign a MUST
actually requires.  Maybe break down to more easily digestible sentences?

    [Bernstein]
               Bernstein, D., "PASV security and PORT security", 2000,
               <http://cr.yp.to/ftp/security.html>.

.. this reference is not cited in the doc, add or remove?