Re: SFTP v6?

[Joseph Galbraith <galb-list%vandyke.com@localhost>]

Niels Möller wrote:
> "denis bider" <ietf-ssh%denisbider.com@localhost> writes:
>
>
> > if the version extension scheme we're talking about is what I proposed, it
> > does seem to solve the problem at hand in the simplest complete way.
>
>
> I think it is the need for completeness that I want to challenge. The
> sftp version negotiation mechanism was decided a long time ago, and it
> appears to be adequate for most other protocols. I believe it should
> work well to live with that decision and its limitations, and *not*
> try to retrofit a very different version negotiation scheme into the
> protocol.
>
> To make it a little more concrete, I'll make a counterproposal, and
> explain the assumptions that are behind it, to see if the rest of you
> will shoot it down. First, assumptions:
>
>   * sftp version 3 is widely deployed now.
>
>   * sftp version 6 will be (we hope) widely deployed soon.
>
>   * current deployment of sftp version 4 and 5 is quite marginal. (If
>     you want to correct me on this, please differentiate between
>     server and client deployment, it makes a difference).
>
> The simple version negotiation scheme is
>
>   V_S = max { version numbers supported by the server }
>   V_C = max { version numbers supported by the client }
>   V_U = min (V_S, V_C)    # version to use
>
>   If V_U is supported by both parties, negotiation is successful, and
>   V_U is the version that is used on the wire. Otherwise, negotiation
>   fails.

This is almost the way it works, but not quite.

V_C = max { version numbers supported by the client }
V_U = highest version supported by server <= V_C

(V_S doesn't actually exist on the wire.)

A minor difference... but...

[...]

> > If you don't care to implement it, it won't burden your client
> > implementation at all - you can continue to send the highest version you
> > support and that will work just as fine.
>
> Is that really correct? If I connect to a 3,6 server, that server will
> advertise version 3 (it *has* to, if it wants to interoperate with old
> 3,4 clients, and that is the entire point of the extended version
> negotion, right?). If I'm a version 6 only client, and I don't
> implement the proposal, my interpretation of this will be that the
> server is an old version 3 server, and that I can't communicate with
> it, so I will just display an error message and disconnect.

No, this is not correct.

There is actually no problem with the existing version scheme for
_servers_ supporting discontigous protocol versions.  This is
because the _client_ MUST send it's version first.  And the
server doesn't actually send it's version, it sends the version
to use.

So, the server simply waits for the clients version, and picks
the highest protocol version that it supports that is less than
or equal to the clients version and sends that as V_U.

> > On the server side, this method will burden you only if you wish to offer
> > your highest version to clients which support non-contiguous version
> > ranges.
>
> As I understand it, a server or client that supports only version 6
> still has to implement the proposal (i.e., advertise version 3, which
> it does *not* support at all, in the initial version exchange, and
> negotiate version 6 in the new second phase), or else it will not
> interoperate at all with clients that support version 3 and 6. That's
> why I find it so ugly.

See above for client supporting only version 6.

A client that wishes to support discontigous ranges
will behave as follows:

  1. It must send version 3 or higher during initial
     exchange, because if it doesn't the server can't
     send back an extension packet describing it's
     extended version options.

     This implies that in order to support server's
     that don't implement the new version scheme, which
     include v3,4, and 5 servers (of which I know of at
     least on of each), it MUST actually support the version
     3 protocol variant.  YUCK.

  2. It will look for the 'version' extension in the servers
     SSH_FXP_VERSION packet.  If the server doesn't send the
     packet, then the server doesn't support the protocol.

     This implies that a server that doesn't support the new
     protocol will interoperate with this client as if it only
     supported the clients lowest contiguous range of protocols.

  3. If the 'version' packet is available, and contains a version
     higher than that which is currently negotiated, the client
     sends a 'version-select' (I like that name much better than
     what I used in the draft.)

So, yes, if you implement a version 6 client, you'll need to be
able to support enough version 3 to get through the extension.
And I agree, that is gross.

So I'll make an alternate proposal:

SFTP (which stands for Secure File Transfer Protocol) is not
a file transfer protocol.  If it were a file transfer protocol,
it would have operations like get and put.  Instead it has
operations like open, read, write, and close.

Therefore, I suggest that we change the name of the subsystem
to 'file-share'

The 'file-share' protocol supports all versions of the 'sftp'
protocol, with the minor exception that version exchange
consists of:

Server and client both send (without waiting to receive):

FXP_INIT2
string version-list
<extension-data>

version-list is comma separated string of versions,
in order of preference.  For example.  "6,2,1"

The version to use is the first version on the clients
list that is also on the server list.

Now:

- People with existing implementations only need a little
  bit of parameterization based on subsystem name to use
  the same piece of code to support 'sftp' and 'file-share'.

  Unix out-of-process implementations, might, for example,
  simply hard-link the sftp server binary to sftpd and
  fileshared.  Or they might pass the subsystem name on
  the command line.

  In proc implementations have similar options available.

  In fact, implementors can (and SHOULD I think) make the
  switch to 'file-share' independent of implementing
  the latest protocol version.

- Older clients continue to work without change (they
  talk to the older 'sftp' subsystem.)

- Newer clients will have to attempt to start the
  'file-share' subsystem, and if that fails, start
  the 'sftp' subsystem.

  This could cost one additional round trip when talking
  to a downlevel server, but, when talking to newer
  servers, it actually saves half a round trip because
  the server no longer waits for the clients version
  before sending it's own, and in addition, appropriate
  client extensions can be batched up and sent during
  init (something that couldn't be done before because of
  compatibility problems.)  Which could save even more.

- The new version negotiation scheme is:

  a. familiar to all ssh implementors.
  b. flexible enough to handle any future needs I can think
     of.
  c. more graceful than the old, especially in the way it fails.
     In particular, the client can now tell the user what versions
     the server _does_ support (which is really useful to me
     as an implementor or sys admin try to help a befuddled
     user.)

I actually think the name change is a cleaner solution.
Niels does raise a good point about a version 6 only
server having to lie and support version 3 in order to
work with discontigous clients.  This does seem very
ugly to me.

However, I do think we need to do one or the other
of these proposals.  I don't think simple language
change is sufficient with implementation advice is
sufficient.

The problem is indeed, temporary, for some definition
of temporary.  But, I suspect we will be seeing version
3 in use for another 5 years, at least.  That definitely
puts it on my mid to long range radar.

My pessimistic evaluation is that it will be more like
5-7 years after we hit RFC status before we don't have
customers that want to interoperate with a version
client or server.

I also suspect if we give people with existing
implementations a way to get to the latest version with
less pain the problem will be more temporary (i.e., newer
versions will be out there sooner for people to start
upgrading to, and the sooner they start the more temporary
our problem.)

- Joseph