From anthonybryan@gmail.com Sat Mar 9 16:19:25 2013 Return-Path: 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 ; 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 ; 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 ; Sat, 9 Mar 2013 16:19:24 -0800 (PST) Received: by mail-qc0-f170.google.com with SMTP id d42so1051994qca.15 for ; 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: <041801cdfce8$98df0fa0$ca9d2ee0$@texis.com> Date: Sat, 9 Mar 2013 19:19:23 -0500 Message-ID: From: Anthony Bryan To: Alun Jones Content-Type: text/plain; charset=ISO-8859-1 Cc: "ftpext@ietf.org" , Daniel Stenberg 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 From anthonybryan@gmail.com Sat Mar 9 16:32:08 2013 Return-Path: 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 E0F1621F8734 for ; Sat, 9 Mar 2013 16:32:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 PkYjw-8ir0lV for ; Sat, 9 Mar 2013 16:32:07 -0800 (PST) Received: from mail-qe0-f52.google.com (mail-qe0-f52.google.com [209.85.128.52]) by ietfa.amsl.com (Postfix) with ESMTP id D83B721F86D6 for ; Sat, 9 Mar 2013 16:32:06 -0800 (PST) Received: by mail-qe0-f52.google.com with SMTP id s14so1720558qeb.11 for ; Sat, 09 Mar 2013 16:32:06 -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=3++quMJs4GD2hblUJz25/c30j4V8fc+F7muZcsirSbI=; b=xUdUTUV3AVXS02Co/Y2v9I4KKCEp3sNk6m3Smina2GmASrtZHYBwFYibKPZmgxnxOQ ATI18XroZ2h15jvPm53uenZpY4XECU2agndaapc6BUJyxlHQpBfNDbESzD13bR9wL0Nl sPRDTgKNWwiuKU7wyikXcvu0qxiAouBTvLZ6HgEGc21G2zXd6dQvf4wALW0HH+6FNALQ biszRaCEEVJvxclPvWOveDlFZ1SjYA36whpJ3tRNYvButTCvubX0NZFtxx2CbJ3+Qi5X UcRTVzMDs6/M1vurvAhryGYDof9muSpeDFBFC2uZim25c0LmXOel0clSNKxOj1rBxNgT fUvg== MIME-Version: 1.0 X-Received: by 10.49.74.198 with SMTP id w6mr11661876qev.57.1362875526339; Sat, 09 Mar 2013 16:32:06 -0800 (PST) Received: by 10.49.71.140 with HTTP; Sat, 9 Mar 2013 16:32:06 -0800 (PST) In-Reply-To: References: <51009243.4080809@gmail.com> <51056391.2070901@gmail.com> <03ec01cdfcbc$b247bef0$16d73cd0$@texis.com> <5105BDA8.7000006@gmail.com> Date: Sat, 9 Mar 2013 19:32:06 -0500 Message-ID: From: Anthony Bryan To: Hans Andersen Content-Type: text/plain; charset=ISO-8859-1 Cc: "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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 00:32:09 -0000 Daniel Stenberg wrote elsewhere: "I agree that sending data in a chunked-encoding style (from HTTP 1.1) is much easier for both sender and receiver instead of having to check for a boundary separator in the stream. It would be good to get an FTP server author's point of view on this." any other +1s or opinions? On Sat, Feb 2, 2013 at 12:59 AM, Hans Andersen wrote: > I just wanted to back my colleague, Bruce, on the performance issue related > to detecting boundaries. A few weeks ago I wrote code that detects MIME > boundaries in HTTP-POSTs while piping the data to a file. The best I > managed to achieve was significantly slower than simple piping. I therefore > think that optionally including the size is important for performance. > > On 2 February 2013 14:26, Anthony Bryan wrote: >> >> right, we could leave the boundary REQUIRED but have an OPTIONAL size >> that would be used (probably the majority of the time?) -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads From anthonybryan@gmail.com Sat Mar 9 16:44:23 2013 Return-Path: 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 AF7EF21F846C for ; Sat, 9 Mar 2013 16:44:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 M7ExpvJayuZU for ; Sat, 9 Mar 2013 16:44:23 -0800 (PST) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) by ietfa.amsl.com (Postfix) with ESMTP id EC35421F845D for ; Sat, 9 Mar 2013 16:44:22 -0800 (PST) Received: by mail-qa0-f45.google.com with SMTP id g10so426573qah.4 for ; Sat, 09 Mar 2013 16:44:22 -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:content-transfer-encoding; bh=eM4X1CdKtik3+jZ6HIYGEB7+W6Q1m55iLLuHIo59icM=; b=BVyS/Z8bOh9nKTwf/YxN2zVgHTT7msZrynDl9BQiPZZRbtRnx5DfE49dsCxZwJYfhT piqCjVUigRq4mAAYRZ79Atskc2YxMyHTof7PEihTuG545wb85gkwmDc5V7lglXvFyUqQ HeoInwV0muol+3Pe9OUEa1Ns71geaPYZF+O9jzRM3HmXfrOS+q8FM8O+MzH7o6ango0s GUFdX1A0RCo+N/+EWtF4i7YrJFOzODZYTDe/QzCnoixt3DnhJt2dOawyd9xcmyBmMHnk nYuHPdjKDKDIq0xzGl9Ixe1PlXlpMMmkQLLh9kxDqOUmMulMFjlMjeFPPi3G+ljVQPSo 01rg== MIME-Version: 1.0 X-Received: by 10.229.172.162 with SMTP id l34mr2487103qcz.81.1362876262417; Sat, 09 Mar 2013 16:44:22 -0800 (PST) Received: by 10.49.71.140 with HTTP; Sat, 9 Mar 2013 16:44:22 -0800 (PST) In-Reply-To: <5106E7D4.9010505@gmail.com> References: <041a01cdfcea$9fa3a060$deeae120$@texis.com> <5106E7D4.9010505@gmail.com> Date: Sat, 9 Mar 2013 19:44:22 -0500 Message-ID: From: Anthony Bryan To: =?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 00:44:23 -0000 On Mon, Jan 28, 2013 at 4:04 PM, =C1ngel Gonz=E1lez wro= te: > On 28/01/13 01:01, Alun Jones wrote: >> After reading the RANG spec, I note that there isn't anything to state w= hat >> errors are given by RETR if the range specified is incorrect, or by STOR= / >> APPE if the range specified starts more than one byte after the end of t= he >> existing file on the server (and therefore, presumably, incorrect?). current text is: The server-PI should reject the STOR if a client issues a RANG with a start-point greater than the actual file size. If the start-point is less than or equal to the file size, the file is opened for writing, continuing at start-point. http://tools.ietf.org/html/draft-bryan-ftp-range > I think it should be documented that the server must fill the gap with > nul bytes, > with a note that it may use it as a hint to do that using a sparse file. any other feelings on this? on a side note, wondering if it might be better to separate RANG and RETR/STOR/etc_with_RANG into 2 separate drafts. HASH is also a separate draft that happens to use RANG. -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads