Re: SSH File Transfer Protocol - draft-moonesamy-secsh-filexfer-00

Joseph Galbriath <galb-list@vandyke.com> Mon, 22 July 2013 17:06 UTC

Return-Path: <bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org>
X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com
Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 212A711E81AD for <ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com>; Mon, 22 Jul 2013 10:06:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1
X-Spam-Level:
X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[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 KgfXWLDILFw5 for <ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com>; Mon, 22 Jul 2013 10:06:10 -0700 (PDT)
Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id C212711E811E for <secsh-tyoxbijeg7-archive@lists.ietf.org>; Mon, 22 Jul 2013 09:51:52 -0700 (PDT)
Received: by mail.netbsd.org (Postfix, from userid 605) id 839BE14A144; Mon, 22 Jul 2013 16:43:35 +0000 (UTC)
Delivered-To: ietf-ssh@netbsd.org
Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 9189E14A114 for <ietf-ssh@netbsd.org>; Mon, 22 Jul 2013 16:43:33 +0000 (UTC)
X-Virus-Scanned: amavisd-new at NetBSD.org
Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 6UfJD6gcSzay for <ietf-ssh@netbsd.org>; Mon, 22 Jul 2013 16:43:33 +0000 (UTC)
Received: from vandyke.com (mail.vandyke.com [216.184.10.33]) by mail.netbsd.org (Postfix) with ESMTP id D8D4414A0A9 for <ietf-ssh@netbsd.org>; Mon, 22 Jul 2013 16:43:32 +0000 (UTC)
Received: from [192.168.1.62] (HELO cw01.nm.cotsware.com) by vandyke.com (CommuniGate Pro SMTP 5.4.4) with ESMTP id 13143431; Mon, 22 Jul 2013 10:01:58 -0600
Message-ID: <51ED57CF.8090009@vandyke.com>
Date: Mon, 22 Jul 2013 10:03:27 -0600
From: Joseph Galbriath <galb-list@vandyke.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Mouse <mouse@Rodents-Montreal.ORG>
CC: ietf-ssh@NetBSD.org
Subject: Re: SSH File Transfer Protocol - draft-moonesamy-secsh-filexfer-00
References: <6.2.5.6.2.20130712030130.0beda980@elandnews.com> <201307131256.IAA29783@Chip.Rodents-Montreal.ORG>
In-Reply-To: <201307131256.IAA29783@Chip.Rodents-Montreal.ORG>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Sender: ietf-ssh-owner@NetBSD.org
List-Id: ietf-ssh.NetBSD.org
Precedence: list

On 2013/07/13 6:56, Mouse wrote:
>> The SSH File Transfer Protocol provides secure file transfer
>> functionality over any reliable data stream.
>
> Well...it, combined with the rest of ssh, does; sftp itself doesn't
> provide any significant level of security, depending on lower layers
> for that.
>
> But, really, it provides a lot more than file transfer; it's really a
> remote filesystem access protocol, misnamed as a file transfer
> protocol.  If you really want a file transfer protocol, I'd suggest
> using a slight mutation of FTP (using ssh channels rather than TCP
> connections).  But, apparently, people prefer a remote filesystem
> access protocol, even a misnamed one.

Funny we should arrive here.  That was one of the things VanDyke was
considering in the time frame between SFTP advent as a product and
the publishing of the initial draft.  We may have even brought it up
in an ietf meeting.

 From a technical view point, this is still somewhat interesting to me;
one of the difficulties with SFTP (as speced from draft 0 onwards) is
the request/response nature of moving data. A protocol (like FTP) that
just said "send me the whole file as fast as you can" would probably
be a lot harder to mess up performance wise than SFTP, where it is
necessary to issue multiple overlapping read requests with carefully
tuned max-packet, read size, and channel window in order to get
reasonably good performance.

Thanks,

Joseph