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

Hi,

Can you address these issues?
Do you have any other comments you know of that need to be included in
a new rev?

As soon as you get a revised ID, and the shepherd gives me a go-ahead
that we've caught all comments, I'll schedule the doc for an IESG
telechat.

David Harrington
Director, IETF Transport Area
ietfdbh@comcast.net (preferred for ietf)
dbharrington@huaweisymantec.com
+1 603 828 1401 (cell)

-----Original Message-----
From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On
Behalf Of Pekka Savola
Sent: Monday, May 30, 2011 5:10 AM
To: ietf@ietf.org
Cc: draft-ietf-behave-ftp64.all@tools.ietf.org; behave@ietf.org
Subject: Re: [BEHAVE] Last Call: <draft-ietf-behave-ftp64-10.txt> (An
FTP ALG for IPv6-to-IPv4 translation) to Proposed Standard

On Fri, 20 May 2011, The IESG wrote:
> 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

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?
_______________________________________________
Behave mailing list
Behave@ietf.org
https://www.ietf.org/mailman/listinfo/behave