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

From: Peter Gutmann <[email-masked]>
Date: Fri, 12 Jul 2013 11:37:12 +0000

S Moonesamy <[email-masked]> writes:

>The SSH File Transfer Protocol provides secure file transfer functionality
>over any reliable data stream.  It is the standard file transfer protocol for
>use with the SSH2 protocol. draft-moonesamy-secsh-filexfer-00 (
>http://tools.ietf.org/html/draft-moonesamy-secsh-filexfer-00 ) describes the
>file transfer protocol and its interface to the SSH2 protocol suite.
>
>I would appreciate if you read the draft and comment.

Some background information on this decision would be useful, for example why
restart work on it now, and why use version 3 of the protocol as the baseline?

Peter.

---

From: S Moonesamy <[email-masked]>
Date: Fri, 12 Jul 2013 05:18:35 -0700

Hi Peter,
>restart work on it now, and why use version 3 of the protocol as the baseline?

There was a short discussion a few months ago about Section 6.1 of an 
expired SFTP  drafts.  I used Version 3 as the baseline as that is 
the version which OpenSSH implemented.  In my opinion it would be 
easier to document Version 3 as an IETF specification instead of 
trying to pursue the previous efforts.

Regards,
S. Moonesamy

---

From: "denis bider \(Bitvise\)" <[email-masked]>
Date: Fri, 12 Jul 2013 08:42:40 -0600

A fair number of implementations, including ours, implement SFTP versions 4 
and 6, as specified in:

draft-ietf-secsh-filexfer-13.txt

as well as extensions specified in:

draft-galb-filexfer-extensions-00.txt

Just because one open source implementation chooses to be stuck in the 
past - apparently because SFTP version 3 is simplistic, and offered most of 
what is needed on their target platform - doesn't mean it should get to 
dictate the standard.

The latest SFTP version is 6. Restarting standardization at 3 doesn't mean 
implementations of 4 and 6 are going to go away. It in fact means that two 
concurrent SFTP version trees are going to exist in the future. I think this 
is a poor decision, and I do not support it.

Any standardization efforts should continue where these documents left off:

draft-ietf-secsh-filexfer-13.txt
draft-galb-filexfer-extensions-00.txt

If OpenSSH chooses to be stuck in the past and implement an older version of 
the protocol known as SFTP version 3, then the OpenSSH project can document 
the version they implement, but based on one implementation, that doesn't 
need to be an internet standard.

-----Original Message----- 
From: S Moonesamy
Sent: Friday, July 12, 2013 06:18
To: Peter Gutmann
Cc: [email-masked]
Subject: Re: SSH File Transfer Protocol - draft-moonesamy-secsh-filexfer-00

Hi Peter,

Regards,
S. Moonesamy

---

From: Mouse <[email-masked]>
Date: Sat, 13 Jul 2013 08:59:06 -0400 (EDT)

> [...], as specified in:

> draft-galb-filexfer-extensions-00.txt

Where can one find those?  ftp.ietf.org doesn't seem to have them; the
Moonesamy draft is the only one I get asking for *filexfer*.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: "Mark D. Baushke" <[email-masked]>
Date: Sat, 13 Jul 2013 08:34:12 -0700

> > draft-ietf-secsh-filexfer-13.txt

This one lives here:

  http://tools.ietf.org/id/draft-ietf-secsh-filexfer-13.txt

but a history of the changes may be found here:

  http://datatracker.ietf.org/doc/draft-ietf-secsh-filexfer/

last updated 2006-07-18.

> > draft-galb-filexfer-extensions-00.txt

This one lives here:

  http://tools.ietf.org/html/draft-galb-filexfer-extensions-00

last updated 2005-10-05.

> Moonesamy draft is the only one I get asking for *filexfer*.

fwiw: Both drafts were authored by Joseph Galbraith of VanDyke Software
and Oskari Saarenmaa of F-Secure.

The draft-ietf-secsh-filexfer originally had co-authors Tatu Ylonen and
Sami Lehtinen, but they dropped out around version 10 of the draft in
June 2005.

As near as I can figure, versions of the SFTP protocol are spread out
over different iterations of the draft-ietf-secsh-filexfer document.

Version 3 was enumerated first in the -02 draft.

	Version 2: Added SSH_FXP_RENAME

	Version 3: Added SSH_FXP_READLINK, SSH_FXP_SYMLINK
		   SSH_FXP_EXTENDED, SSH_FXP_EXTENDED_REPLY, and
		   SSH_FXP_STATUS

Drafts -03 and -04 bumped the STFP version to 4

Draft -05 bumped the SFTP version to 5

Drafts -06 thru -13 all played with the SFTP version 6

Given that draft-ietf-secsh-filexfer-13.txt had the latest description
of version 6 of the SFTP protocol and none of the drafts ever were
published as an RFC, there is already a fair amount of confusion with
regard to SFTP versions.

I am actually in favor of some form of the
draft-moonesamy-secsh-filexfer as an informational RFC to document the
packet types being used by SFTP as a way of getting them put into the
http://www.iana.org/assignments/ssh-paramters/ssh-parameters.xhtml
document so that everyone who implements some fraction of them uses the
same packet type definitions.

If this means that the SFTP version needs to be at some other version
than 3 or 4 or 6, then so be it.

OpenSSH has said that it implements draft-ietf-secsh-filexfer-02.txt
and provides a copy of it in http://www.openssh.com/txt/

What are the differences between draft-ietf-secsh-filexfer-13 and
draft-moonesamy-secsh-filexfer-00 ?

Well, packet 20 is not listed in the draft-ietf-secsh-filexfer-13, but
is named SSH_FXP_SYMLINK in moonesamy.

Also moonesamy does not define packets 21 (SSH_FXP_LINK, 22
(SSH_FXP_BLOCK), 23 (SSH_FXP_UNBLOCK).

So, did anyone ever implement packet types 21, 22, and 23?
If so, what SFTP version did you call it and what do they do?

	-- Mark

---

From: S Moonesamy <[email-masked]>
Date: Mon, 15 Jul 2013 00:51:17 -0700

At 05:50 12-07-2013, Rich Whalen wrote:
>The protocol is more of a file access protocol than a file transfer protocol.
>This re-introduction of Version 3 of the protocol has the problem of 
>not addressing the problem of exchanging text files on dissimilar 
>systems. Though OpenSSH is a very common implementation there are 
>other implementations on systems that use a line break mechanism 
>that is different from Unix/Linux.  Many commercial users of SFTP 
>implementations use it to transfer files between dissimilar systems 
>and often encounter problems with text files that use different line 
>break sequences. While the EXTENDED operation allows for vendor 
>specific extensions, the problem is that they are VENDOR specific, 
>and a company implementing a SFTP utility does not want to try to 
>determine which implementation of the protocol they are dealing with 
>and implement one of a variety of text file access methods.

Thanks for the feedback.  I'll comment below.

At 07:42 12-07-2013, denis bider (Bitvise) wrote:
>A fair number of implementations, including ours, implement SFTP 
>versions 4 and 6, as specified in:
>
>Just because one open source implementation chooses to be stuck in 
>the past - apparently because SFTP version 3 is simplistic, and 
>offered most of what is needed on their target platform - doesn't 
>mean it should get to dictate the standard.
>
>The latest SFTP version is 6. Restarting standardization at 3 
>doesn't mean implementations of 4 and 6 are going to go away. It in 
>fact means that two concurrent SFTP version trees are going to exist 
>in the future. I think this is a poor decision, and I do not support it.
>
>If OpenSSH chooses to be stuck in the past and implement an older 
>version of the protocol known as SFTP version 3, then the OpenSSH 
>project can document the version they implement, but based on one 
>implementation, that doesn't need to be an internet standard.

The draft is not about dictating any Internet standard.  I understand 
that there are a number of implementations that implement different 
versions of the expired drafts.  I am also aware of the file access 
protocol discussion and the discussion about vendor specific extensions.

As I mentioned previously my effort is about documentation what 
exists.  It is not about making implementations of 4 and 6 go away.

Regards,
S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Mon, 15 Jul 2013 01:14:16 -0700

Hi Mark,
>published as an RFC, there is already a fair amount of confusion with

Yes.

>same packet type definitions.

The initial intended status was Informational.  I switched it before 
I-D submission as it doesn't affect the existing text.

>than 3 or 4 or 6, then so be it.

I would look at it in terms of how much effort is required.  Choosing 
between 3, 4, or 6 is itself an effort which might discourage anyone 
from doing anything. :-)

>draft-moonesamy-secsh-filexfer-00 ?

See 
http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-secsh-filexfer-13.txt&url2=http://tools.ietf.org/id/draft-moonesamy-secsh-filexfer-00.txt

Regards,
S. Moonesamy

---

From: Rich Whalen <[email-masked]>
Date: Fri, 12 Jul 2013 12:50:53 +0000

The protocol is more of a file access protocol than a file transfer protocol.
This re-introduction of Version 3 of the protocol has the problem of not addressing the problem of exchanging text files on dissimilar systems. Though OpenSSH is a very common implementation there are other implementations on systems that use a line break mechanism that is different from Unix/Linux.  Many commercial users of SFTP implementations use it to transfer files between dissimilar systems and often encounter problems with text files that use different line break sequences. While the EXTENDED operation allows for vendor specific extensions, the problem is that they are VENDOR specific, and a company implementing a SFTP utility does not want to try to determine which implementation of the protocol they are dealing with and implement one of a variety of text file access methods.

Richard Whalen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of S Moonesamy
Sent: Friday, July 12, 2013 8:19 AM
To: Peter Gutmann
Cc: [email-masked]
Subject: Re: SSH File Transfer Protocol - draft-moonesamy-secsh-filexfer-00

Hi Peter,

Regards,
S. Moonesamy

---

From: Albert Lunde <[email-masked]>
Date: Mon, 15 Jul 2013 04:29:34 -0500

> trying to pursue the previous efforts.

Van Dyke software seems to have implemented features from the later SFTP 
drafts in their products.   I have used them, and can say that they are 
useful in getting a more faithful transfer of files between Windows systems.

---

From: "Mark D. Baushke" <[email-masked]>
Date: Mon, 15 Jul 2013 06:08:19 -0700

Hi Folks,

[+cc Richard Kettlewell (see the archives of ietf-ssh
with this Subject: thread for more information)]

There seems to be a fairly good chart given in

    http://www.greenend.org.uk/rjk/sftp/sftpversions.html
and http://www.greenend.org.uk/rjk/sftp/sftpimpls.html

writted by Richard Kettlewell <[email-masked]>
who also appears to have a drop-in "Green End SFTP Server"
implementation documented in http://www.greenend.org.uk/rjk/sftpserver/

I am not sure of the accuracy of the data provided, but it
may be useful for SFTP implementers to check it out.

It does suggest that draft-moonesamy-secsh-filexfer-00 may
want to pick up more definitions as to names and attributes
than it presently provides.

	Enjoy!
	-- Mark

---

From: Joseph Galbriath <[email-masked]>
Date: Mon, 22 Jul 2013 10:40:11 -0600

On 2013/07/12 8:42, denis bider (Bitvise) wrote:
> past - apparently because SFTP version 3 is simplistic, and offered most
> of what is needed on their target platform - doesn't mean it should get
> to dictate the standard.

I did find openssh's reluctance to look beyond the posix filesystem
world somewhat frustrating.

I will admit that the drafts grew much larger than I wanted, but we did
make efforts to make sure implementations didn't have to implement
things that didn't want or could not support.

> The latest SFTP version is 6. Restarting standardization at 3 doesn't
> mean implementations of 4 and 6 are going to go away. It in fact means
> that two concurrent SFTP version trees are going to exist in the future.
> I think this is a poor decision, and I do not support it.
>

I agree with this.

Thanks,

Joseph

> -----Original Message----- From: S Moonesamy

---

From: Joseph Galbriath <[email-masked]>
Date: Mon, 22 Jul 2013 09:40:22 -0600

On 2013/07/13 9:34, Mark D. Baushke wrote:
> [...]

>    http://tools.ietf.org/html/draft-galb-filexfer-extensions-00

http://tools.ietf.org/id/draft-ietf-secsh-filexfer-extensions-00.txt
is more up-to-date (if only slightly) and includes several additional
extensions. (Published: January 18, 2006)

> [...]

> is named SSH_FXP_SYMLINK in moonesamy.

The problem here is that OpenSSH implemented packet 20 backwards from
the spec (swapped target and source file).  Others implement the spec
correctly.  And because of backwards compatibility, no one wanted to
change.

So I dropped packet 20 as basically unimplementable and introduced
SSH_FXP_LINK to replace it (and also supported hard links at the
same time).

> If so, what SFTP version did you call it and what do they do?

Yes; we've implemented all three in our products.

Thanks,

Joseph

---

From: Joseph Galbriath <[email-masked]>
Date: Mon, 22 Jul 2013 09:56:13 -0600

>      http://www.greenend.org.uk/rjk/sftp/sftpversions.html

This is a pretty nice summation of the various sftp protocol
versions.

The extensions mentioned as "Defined in draft-ietf-secsh-filexfer-09.txt
but for some reason not later versions" were moved from the main
filexfer draft to the extensions draft to reduce the size of the main
draft and make it clear that it wasn't necessary to implement them
to have a conforming implementation.  (Maybe we should of have done
this with more features, like the block/unblock stuff as well.)

I just posted a link to that draft in another part of this
thread, but here it is again:

http://datatracker.ietf.org/doc/draft-ietf-secsh-filexfer-extensions/

Thanks,

Joseph

---

From: S Moonesamy <[email-masked]>
Date: Mon, 22 Jul 2013 10:48:24 -0700

Hi Joseph,
>SSH_FXP_LINK to replace it (and also supported hard links at the

An alternative is to document the OpenSSH case and mention that it 
can cause an interoperability issue.

Regards,
S. Moonesamy

---

From: Damien Miller <[email-masked]>
Date: Tue, 23 Jul 2013 10:05:08 +1000 (EST)

On Fri, 12 Jul 2013, denis bider (Bitvise) wrote:

> the version they implement, but based on one implementation, that doesn't need
> to be an internet standard.

I think "the version of sftp that you can actually use on the Internet" would
make a fine informational RFC.

-d