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

Anthony Bryan <anthonybryan@gmail.com> Tue, 05 February 2013 14:30 UTC

Return-Path: <anthonybryan@gmail.com>
X-Original-To: ftpext@ietfa.amsl.com
Delivered-To: ftpext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB3C21F88FB for <ftpext@ietfa.amsl.com>; Tue, 5 Feb 2013 06:30:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.285
X-Spam-Level:
X-Spam-Status: No, score=-3.285 tagged_above=-999 required=5 tests=[AWL=0.684, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1, SARE_PROLOSTOCK_SYM3=1.63]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ThRIkzXbYop0 for <ftpext@ietfa.amsl.com>; Tue, 5 Feb 2013 06:30:57 -0800 (PST)
Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8BE21F88E1 for <ftpext@ietf.org>; Tue, 5 Feb 2013 06:30:57 -0800 (PST)
Received: by mail-qa0-f44.google.com with SMTP id bv4so1805931qab.17 for <ftpext@ietf.org>; Tue, 05 Feb 2013 06:30:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ySqcDojibQTDfT3dY3AAIodyTTsRjrcHypLvjPdCxSs=; b=09HBR/zjcxWEd0gm9jBeZvhwvhN7MBIs6mlA4lVombGLw+8W2IGFQCJ4ExnNySqX21 CFTD4SZPfaqhQyo91IrAhDe/1PjYl3hnyNrpvSyToTkQkR9ynM17cOTWiO7fRqtE767a KRfwUy743tlkKKTHtjKa8E7M6MhAU214SxWFf2uZBoYtqTRfAA+QR8eZV86+oy++b4cv EHtdVUmxeLMg8ezUv76G8Z7mSCwhDxue/b/suY1UWQgA07I81l1rK5V+yd0PltTy2xk+ 7c7Z5gA7YQf7S1TMfQWk8Asc3aZCYB3QTKVCcC7wxZUOlyGsctw/0xTRHrTPkXz3dj9S Zu7Q==
MIME-Version: 1.0
X-Received: by 10.229.198.132 with SMTP id eo4mr507624qcb.86.1360074657040; Tue, 05 Feb 2013 06:30:57 -0800 (PST)
Received: by 10.49.12.36 with HTTP; Tue, 5 Feb 2013 06:30:56 -0800 (PST)
In-Reply-To: <510ED0FF.5070100@filezilla-project.org>
References: <CANqTPegPaMBF9i1gi+M3m5FXzuxRzUU_QULxB_sdJTVd7NGppQ@mail.gmail.com> <510ED0FF.5070100@filezilla-project.org>
Date: Tue, 5 Feb 2013 09:30:56 -0500
Message-ID: <CANqTPejwwkEGycpUjcLRku3n8vFwpf1pbzn=rJX1wZ_EMdaJ3g@mail.gmail.com>
From: Anthony Bryan <anthonybryan@gmail.com>
To: Tim Kosse <tim.kosse@filezilla-project.org>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "ftpext@ietf.org" <ftpext@ietf.org>
Subject: Re: [ftpext] New Version of FTP HASH, RANG, LOCK, and HOST
X-BeenThere: ftpext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <ftpext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ftpext>, <mailto:ftpext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ftpext>
List-Post: <mailto:ftpext@ietf.org>
List-Help: <mailto:ftpext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ftpext>, <mailto:ftpext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Feb 2013 14:30:59 -0000

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
<tim.kosse@filezilla-project.org>; 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