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