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

[Anthony Bryan <[e-mail]>]

Tim, thanks so much for the review!

here's the text I've used to address your comments.

let me know what you think, if we can refine it more.

On Sun, Feb 3, 2013 at 4:05 PM, Tim Kosse
<[e-mail]> wrote:
> 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?

   FTP secured with TLS [RFC4217] is RECOMMENDED when LOCK is in use as
   most firewalls and NATs will stop interfering with the control
   connection following the AUTH TLS command.

> 2. What about Telnet signals (e.g. IP and Synch) on the NVT during a
> transfer?
>
> Suggestion: Not allowed during a running transfer.

   The STAT command and Telnet IP and Synch signals are 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.

   The STAT command and Telnet IP and Synch signals are not allowed
   during a running transfer.

> 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.

   When LOCK is in use, the response to a SIZE command refers to the
   amount of octets that would be enclosed in the boundary start and
   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.

   To turn off LOCK and return to the previous behavior, a client can
   issue a EPRT, EPSV, PASV, or PORT command.

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

   When LOCK is in use, the restart offset of the REST command 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.

   LOCK is undefined with other transfer modes, besides STREAM.


--
(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
  )) Easier, More Reliable, Self Healing Downloads