Re: SFTP v6?

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

denis bider wrote:
> > 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.
>
>
> I proposed in my previous email to the list the following simple change
> which solves this problem:
>
> If the client supports a contiguous range of versions, it should send the
> highest version it supports in INIT. Otherwise it should send the highest of
> the first contiguous set of versions it supports, e.g. if it supports 3,4,6,
> it should send 4.
>
> This means that if the client supports 4,6 it can send 4 and does not need
> to implement 3. No yuck here. :)

But, if the server only support 6, it must still respond
respond with 4, even though it does not support 4.

Then, if the client doesn't send a 'version-select' the
server must close the channel, because it can't speak
the protocol.

Rather than getting a nice error message about the server
not supporting the version, the user will likely see
strange behavior, because the version 4 client won't be
expecting a channel after version exchange is complete
to mean 'version unsupported.'  It thought the version
stuff was already sorted out.

Ugh.

On the other side of the coin, let's say we have a 4,6
client, which advertises 4 in it's INIT packet.  Now,
the server is a 3,6 server, so it responds 3.  The
client now needs to negotiate down to 3.

That's not so bad, I guess.  (I don't think I allowed
it in the original language, but that could be fixed :-)

The third problematic case is a a client that supports
1,2,6.  Such a client can not send 2, because 2 doesn't
support extensions.  So it must send 3.

Now, what if that client actually meets a version 3 server?
(A highly likely event.)  It is now stuck.  It can't jump
to six, nor can it fall back to 2 where it could actually
interoperate.  So a client really must support, at a minimum,
version 3.

Ugh.

> > So I'll make an alternate proposal:
>
>
> The SFTP module can be implemented separately from the SSH server, as we do.
> This proposal requires the SSH server to know about complexities of the SFTP
> protocol and to invoke the SFTP module differently depending on what verb
> was used to start it.

Not really; it just requires the SSH server to pass the name
of the subsystem being started to the subsystem.

This could be as simple as invoking the sftp-server module
by a different name, or having the config file setup in a
way such that the 'file-share' subsystem invokes
'sftp-server -file-share' and the 'sftp' subsystem invokes
'sftp-server' ... or it might be more complicated
in some implementations.

But it shouldn't require your SSH server to know anything about
the SFTP protocol... it just has to support a new subsystem, and
the subsystem has to know it's name (or you have to have separate
modules.)

In all honesty, I think that the new version exchange is how
it should have been done originally.  And I think that it solves
a number of outstanding problems in the protocol that we've
been reluctant to address because of backwards compatibility
issues, including:

  - the version problem we've been discussing
  - extensions from the client on startup (these have
    been very useful on the server side... originally they
    were there for the client to, but had to be removed for
    backwards compatibility.)
  - Better failure mode when there isn't a compatible version.
    (In fact the draft is currently silent on how to deal with
    this and there isn't a great way to do so with the current
    scheme.  With the new scheme, both sides know that the version
    exchange has failed, and which versions the other supports.)

    We've actually tried to make some changes for better failure
    mode before too.

> This also violates independence of SFTP from the SSH protocol. Each
> underlying protocol must now think up its own rules for starting old versus
> new versions of SFTP.

I'm not sure I follow this argument.

Since any hypothetical non-SSH implementation doesn't actually
have subsystems, it already had to think up its own rules for
starting the protocol.

I don't know of any actual non-SSH implementations.

Any new non-SSH implementation should just always use the
new version exchange, or in other words, the 'file-share'
version semantics.

It should also probably just use the latest protocol version
and not have any of this mess, since it is new and doesn't
have to worry about interoperating with old.

> I think that's much uglier.
>
> Doesn't my proposal above solve all of the gripes about people having to
> advertise versions they don't actually support? It's a straightforward
> change and if that's the only real problem thus far identified we have a
> good solution I think (if Niels agrees).

Unfortunately, no, it really doesn't.  At least I don't see
how yet.

I was initially in favor of the version re-negotiate scheme
(it was basically the solution I had in the back of mind
if I ever got a chance to solve this problem.)

But as I've thought about the possible interoperability
interactions, I've become convinced that it would actually
be pretty fragile, and could lead to non-obvious failures
(like the one I described at the top.)

Thanks,

Joseph