Re: [ftpext] New Version of FTP HASH, RANG, LOCK, and HOST

[Tim Kosse <[e-mail]>]

Hi,

here's my review of the LOCK draft:

1. From the draft: "As mentioned, the use of two ports with FTP became
problematic with the advent of firewalls and NATs. By using a single
port, like many other protocols, these problems are eliminated."

For plain FTP, transmitting arbitrary data over the control connection
will cause massive problems. There are plenty of firewalls and NAT
devices that close the FTP connection if there's strange data on the
control connection.

Worse, many NAT devices act as transparent FTP proxy. They have the
nasty habit of not filtering out FEAT responses they do not know about,
so once a client uses an advertised feature the proxy doesn't support,
the connection will fail.

In other words, the additional problems with firewalls and NAT devices
caused by LOCK completely defeat its intended purpose.

There is a good solution for this problem though, namely FTP over TLS.
Following the AUTH TLS command, most firewalls and NAT routers stop
interfering with the control connection. Perhaps mandate FTP over TLS
for LOCK?


2. What about Telnet signals (e.g. IP and Synch) on the NVT during a
transfer?

Suggestion: Not allowed during a running transfer.


3. How is the STAT command to be handled?

From RFC959: The command may be sent during a file transfer (along with
the Telnet IP and Synch signals--see the Section on FTP Commands) in
which case the server will respond with the status of the operation in
progress

There's no way to send the STAT reply during an ongoing download (e.g.
RETR) if LOCK is being used.

During an ongoing upload (e.g. STOR), how should STAT be handled?

Suggestion: No STAT during a running transfer allowed.


4. SIZE command

From RFC3659: The FTP command, SIZE OF FILE (SIZE), is used to obtain
the transfer size of a file from the server-FTP process.  This is the
exact number of octets (8 bit bytes) that would be transmitted over the
data connection should that file be transmitted.

I suggest that if LOCK is being used, it refers to the amount of octets
that would be enclosed in the boundary start end end, excluding the
boundary markers.


5. From the draft: "To turn off LOCK and return to the previous
behavior, a client can
   issue a PORT, PASV, or similar command."

Not precise enough. What is similar? PASS is similar to PASV, only one
different letter. I suggest explicitly naming all commands.


6. REST command. Same problem as with SIZE. I propose the restart offset
refers to the actual data payload excluding the boundary.


7. Transfer modes other than MODE S aren't mentioned. Explicitly state
that LOCK with other transfer modes is undefined.


Regards,
Tim Kosse