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

Tim Kosse <tim.kosse@filezilla-project.org> Sun, 03 February 2013 21:05 UTC

Return-Path: <tim.kosse@filezilla-project.org>
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 02B7721F8868 for <ftpext@ietfa.amsl.com>; Sun, 3 Feb 2013 13:05:12 -0800 (PST)
X-Quarantine-ID: <kgvkpKl94TdC>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): X-Spam-Report: ... [score: 0.0000]\n \n autolearn: ha[...]
X-Spam-Flag: NO
X-Spam-Score: -4.599
X-Spam-Level:
X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2]
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 kgvkpKl94TdC for <ftpext@ietfa.amsl.com>; Sun, 3 Feb 2013 13:05:11 -0800 (PST)
Received: from filezilla-project.org (filezilla-project.org [IPv6:2a01:4f8:160:7342::2]) by ietfa.amsl.com (Postfix) with ESMTP id 58A0F21F8867 for <ftpext@ietf.org>; Sun, 3 Feb 2013 13:05:11 -0800 (PST)
Received: from p4fc1d5f3.dip.t-dialin.net ([79.193.213.243] helo=[10.0.0.59]) by filezilla-project.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <tim.kosse@filezilla-project.org>) id 1U26kP-0005dl-CF; Sun, 03 Feb 2013 22:05:10 +0100
Message-ID: <510ED0FF.5070100@filezilla-project.org>
Date: Sun, 03 Feb 2013 22:05:03 +0100
From: Tim Kosse <tim.kosse@filezilla-project.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: "ftpext@ietf.org" <ftpext@ietf.org>
References: <CANqTPegPaMBF9i1gi+M3m5FXzuxRzUU_QULxB_sdJTVd7NGppQ@mail.gmail.com>
In-Reply-To: <CANqTPegPaMBF9i1gi+M3m5FXzuxRzUU_QULxB_sdJTVd7NGppQ@mail.gmail.com>
X-Enigmail-Version: 1.5
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2AASQWRFAEIJUAAHKAWOO"
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: Sun, 03 Feb 2013 21:05:12 -0000

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