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

Anthony Bryan <anthonybryan@gmail.com> Sun, 10 March 2013 00:19 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 B1ED721F8493 for <ftpext@ietfa.amsl.com>; Sat, 9 Mar 2013 16:19:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AyRMblmXNTV1 for <ftpext@ietfa.amsl.com>; Sat, 9 Mar 2013 16:19:25 -0800 (PST)
Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id C10C221F8480 for <ftpext@ietf.org>; Sat, 9 Mar 2013 16:19:24 -0800 (PST)
Received: by mail-qc0-f170.google.com with SMTP id d42so1051994qca.15 for <ftpext@ietf.org>; Sat, 09 Mar 2013 16:19:24 -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=zDhNxgwl2A09fYQEzQGHp3sEo7dNd3Bvye+LZtw1nn4=; b=K8cUzAYX2lDPbIkTygRG9oLPdiNL2Lh+j/iFQsIXx5rjkvTdGN75U9P572DcMHaQsC O76uD1UUT6e4CiY25uhDQ5+vhlVhjY6KxEZxB9TQJseFifSz0SOGpPZAxRX93Aio/sBH Qh1ZpIHfXjXWDZ0mBq1xOJjr9CSfc/Na5G/y7jv1j1A1b8sUwLLaFU5x3w+1S2EVkbtt Hj+qXevLR+2pwmZM/FoEgZSwbpIY05YE8vR6ZX0nJAkvnK3bWV3R3FvUfI3sh+lDX35J RjhlzOmFCW02BhnN6r0mf05TsEnCir9XzGeiQmbpJ2E84nKUjZqTAzmrTldFcCwsEb0n hsuA==
MIME-Version: 1.0
X-Received: by 10.224.216.8 with SMTP id hg8mr10854262qab.74.1362874763939; Sat, 09 Mar 2013 16:19:23 -0800 (PST)
Received: by 10.49.71.140 with HTTP; Sat, 9 Mar 2013 16:19:23 -0800 (PST)
In-Reply-To: <041801cdfce8$98df0fa0$ca9d2ee0$@texis.com>
References: <CANqTPegPaMBF9i1gi+M3m5FXzuxRzUU_QULxB_sdJTVd7NGppQ@mail.gmail.com> <041801cdfce8$98df0fa0$ca9d2ee0$@texis.com>
Date: Sat, 9 Mar 2013 19:19:23 -0500
Message-ID: <CANqTPehveZGYBDVhQ3-hNhxX3KdmbUd4vSi6qmgbbt-JfHsxtg@mail.gmail.com>
From: Anthony Bryan <anthonybryan@gmail.com>
To: Alun Jones <alun@texis.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "ftpext@ietf.org" <ftpext@ietf.org>, Daniel Stenberg <daniel.haxx@gmail.com>
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, 10 Mar 2013 00:19:25 -0000

thanks for the comments!

see diff for changes: http://tools.ietf.org/html/draft-bryan-ftp-lock

On Sun, Jan 27, 2013 at 6:46 PM, Alun Jones <alun@texis.com>; wrote:
> After reading the LOCK draft, I have a couple of comments:
>
> 0. RFC 959 already defines a mechanism - Block Mode over the default port -
> which doesn't require PORT or PASV to operate, and doesn't close connections
> between files. This means that under such a scheme, a firewall's life is
> made easier - you open 21 inbound, and allow outbound connections from port
> 20 on the server. Document this in your draft, and people may start using
> that, just because it already works on many servers.

ok, this is now appendix B. if you have any text suggestions, let us know.

> 1. You need an example showing how an upload works, just to make that clear.

added.

> "When uploading files, the client MUST use end-of-marker solution." You
> don't explain this anywhere, or use the term "end-of-marker" anywhere else
> in the draft.

thanks, fixed.

> 2. You need to answer at least the security questions of how a client is
> protected from a malicious server, and how a server is protected from a
> malicious client, as well as how the connection (client and server) is
> protected against a malicious file. Consider what happens if a file contains
> a number of predicted boundary values, and the server or client is not good
> at picking random numbers for those boundaries. Note, for instance, how SMTP
> does this in the DATA command - the DATA ends with a line containing only
> ".". Any line beginning with a "." in the data has to be prefixed by another
> ".". The receiver then simply strips out the first dot on each line. Don't
> give in to the idea that "random numbers can't be guessed", or that
> accidental occurrences or malicious action won't ever successfully reproduce
> the boundary condition. Make it IMPOSSIBLE.

it's not a secret "random" number that would be "guessed". it's
explicitly given by the sender.

> 3. At least three commands are documented to work while a transfer is in
> progress. STAT, which reports the status of the transfer, NOOP, which does
> nothing (but many clients use to keep the control connection open when a
> firewall might close it over a long data transfer), and ABOR, which stops an
> existing transfer. My suggestion would be that STAT will return a response
> after the data transfer has finished (after the response from the transfer
> completion); NOOP the same; ABOR will interrupt the transfer, the transfer's
> end response will be signaled as interrupted, and the ABOR command will send
> a 426 and 226.

Tim Kosse suggested:

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

any other suggestions?

> 4. Answering your question of "how to unlock" - the obvious way is to use a
> PORT or PASV (or similar) command to re-establish such behavior, or REIN if
> you want to go back to default port operation (and blow away your login,
> other settings, etc).

yes, thanks. added.

> 5. You should indicate in your examples whether the boundary and separator
> lines are sent by client or server, just to avoid confusion.

added.

> Alun.
> ~~~~
>
>> -----Original Message-----
>> From: ftpext-bounces@ietf.org [mailto:ftpext-bounces@ietf.org] On Behalf
>> Of Anthony Bryan
>> Sent: Sunday, January 20, 2013 9:01 AM
>> To: ftpext@ietf.org
>> Subject: [ftpext] New Version of FTP HASH, RANG, LOCK, and HOST
>>
>> we updated the FTP HASH, RANG, and LOCK drafts, while the authors of
>> HOST have updated their (hopefully final, get any comments or reviews in
>> ASAP) draft.
>>
>> we are mostly interested in finishing up HASH & RANG, but also feel free
> to
>> comment on LOCK. fancy diffs are available. HASH, RANG, & LOCK changes
>> are all editorial or just updating the draft.
>>
>>
>> HASH FTP command to be used by clients to request cryptographic hashes of
>> files.
>> http://tools.ietf.org/html/draft-bryan-ftpext-hash
>>
>>
>> RANG command to be used by clients to designate a start and end point to
>> permit restarts and repairs of interrupted data transfers in STREAM mode.
>> http://tools.ietf.org/html/draft-bryan-ftp-range
>>
>>
>> LOCK command to be used by clients to request the server to use the
> control
>> connection for data transfers, using a single port instead of two.
>> http://tools.ietf.org/html/draft-bryan-ftp-lock
>>
>>
>> also, HOST has been updated:
>>
>> FTP command that provides a mechanism for FTP clients and servers to
>> identify individual virtual hosts on an FTP server.
>>
>> http://datatracker.ietf.org/doc/draft-hethmon-mcmurray-ftpext-ftp-hosts/
>> http://tools.ietf.org/html/draft-hethmon-mcmurray-ftpext-ftp-hosts (diffs)



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