Hello,
I've reviewed this document as part of the transport area directorate's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the
document's authors for their information and to allow them to address
any issues raised. The authors should consider this review together with
any other last-call comments they receive. Please always CC
tsv-dir@xxxxxxxx if you reply to or forward this review.
SUMMARY
-------
This draft is on the right track but has open issues, described in the
review.
TECHNICAL
---------
* Section 1, page 3:
In 5 cases, issuing the EPSV
command to the server led to a significant delay, in 3 cases followed
by a control channel reset.
Could you please clarify what was the cause of the delay? And, btw, have
you guys put the details of your results publicly available somewhere?
* Section 1, page 3-4:
Clients that want to engage in more complex behavior, such as server-
to-server transfers, may make an FTP application layer gateway (ALG)
go into transparent mode by issuing AUTH or ALGS commands as
explained in Section 5.
I thought server-to-server transfer had been banned for many years now
(it was exploited for address scan purposes). Am I missing something?
* Section 5:
In the second case, an implementation MUST have the ability to track
and update TCP sequence numbers when translating packets as well as
the ability to break up packets into smaller packets after
[....]
What about the TCP URG flag and the Urgent Pointer? FTP is one of the
few legacy applications that make use of TCP's urgent mode. And while
use in new applications is deprecated, and TCP urgent mode itself is
unreliable (see RFC 6093), you should make an explicit decision about
what to do with TCP urgent mode when used for the FTP control channel.
When packets are translated individually, the ALG should update the
Urgent Pointer if/where necessary. If the ALG terminates the IPv6 TCP
session, there's the question of whether urgent mode should be "copied"
from the IPv6 session to the IPv4 session.
* Section 5.1, page 7:
For the time being, ALG implementations may employ
one of the following strategies regarding LANG negotiation
Should you s/may/MAY/?
* Section 5.1, page 8:
3. Block LANG negotiation by translating the LANG command to a NOOP
command, and translating the resulting 200 response into a
response appropriate for unsupported commands, such as 500. Text
is sent in the default language.
I think you should mandate which exact code the 200 should be translated
to, rather than just provide an example.
EDITORIAL
---------
* Abstract, page 1
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.
Remove the comma between "today" and "others"
* Abstract, page 1
translators
are used to bridge that gap, FTP is made to work through these
translators as best it can.
s/as best as it can/to the best possible extent/?
* Section 5.1 (page 7) and elsewhere:
So the situation where the client and server try to
negotiate a language that the ALG doesn't support can't be avoided.
Expand doesn't to "does not", "can't" to "cannot", etc.
* Section 5.1, page 8:
Note that [RFC2640] section 3.1 specifies new handling for spaces and
the CR character in path names.
Rephrase to "Note that Section 3.1 of [RFC2640]..."
* Section 11, page 12:
ALGs MUST support the new ALGS (ALG status) command that allows
command MUST be passed on to the server without modification, and the
clients to query and set the ALG's status.
I had trouble parsing this sentence.
* Section 11, page 12:
A client can use the ALGS command to request the ALG's status and to
enable and disable EPSV to PASV and, if implemented, EPRT to PORT
translation.
Please rephrase to "...disable EPSV to PASV translation and, if
implemented, EPRT to PORT translation".
Thanks!
Best regards,
--
Fernando Gont
e-mail: fernando@xxxxxxxxxxx || fgont@xxxxxxx
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf