RE: SFTP v6?

["denis bider" <ietf-ssh%denisbider.com@localhost>]

Niels,


I will reply with the technical aspects first.


> > 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 your client sends version 6 and the server supports version 6 it can
respond with version 6.

If the client supports a contiguous range of versions, we can make it OK for
the client to simply advertise the highest version it supports. It would
work fine.


> 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.

This can be fixed. If the client supports a contiguous range of versions, it
should send the highest version it supports in INIT. Otherwise it should set
the highest of the first contiguous set of versions it supports, e.g. if it
supports 3,4,6, it should send 4.

The server should respond with min{advertisedClientVersion,
highestServerVersion} in VERSION. However if advertisedClientVersion is
lower than highestServerVersion, the server should include the
"higher-versions" extension (or whatever it's called) enumerating the higher
versions it supports. In this case the server MUST then accept the
subsequent "SELECTVERSION" packet from the client.

I haven't yet had the chance to read Joseph's wording in the SFTP 6 draft so
I don't know if his wording supports this. If it doesn't we can fix.


Now for the practical aspects of this.


> This is expected to be a rare problem in practice, since at any given
> time, deployment is usually dominated by at most two different versions.

I believe this to be too optimistic. A situation like 3-6 can reoccur with a
future set of versions. Could be several years from now if the need arises
for new features requiring an incremented version. It won't hurt to have
this interoperability support in place then. Or if the past is any
predictor, something like that could even happen again now. Suppose 6 is a
major thing, then a few people implement 7, and then 8 is the next major
thing.

Note that even in a few years' time we will still likely have SFTP versions
3, 4, 5 around.

Right now our SSH server still supports SFTP version 2 only. The features of
SFTP version 2 are all that's needed in a Windows server, so we didn't yet
upgrade. We will upgrade, but right now we have a fairly considerable base
of deployed installations featuring SFTP version 2. A good portion of our
users won't bother to upgrade to the next version and will continue to
advertise SFTP version 2.

That's for how long a deployed version can be expected to persist. I expect
SFTP version 3 will continue to be around for some time to come.


> In order to make communication possible also in situations like the
> above example, where the version negotiation fails, implementations
> that support more than one version of the protocol SHOULD provide
> some mechanism to manually or automatically configure which of its
> supported versions it advertises.

Niels - are any of your clients and servers graphical? Textual configuration
is easy. But providing good and well working graphical configuration for
ANYTHING is much, much more difficult than extending the protocol for it to
work automatically. Adding a new option can even take more than a day some
times. It's an important consideration when implementing anything.

In my experience, if the protocol doesn't provide an easy solution to a
common problem, the result will be chaotic differences between
implementations and haphazard interoperability.


> This proposal sacrifices trivial out-of-the-box 
> interoperability between implementations that support version 
> 3 and 6, and implementations supporting version 3 and 4 
> (interoperability requires either manual configuration, or 
> implementation kludges like sometimes reconnecting and trying 
> a different version). I'm willing to do that sacrifice in 
> order to keep the protocol nice and clean, and because the 
> 3,4-vs-3,6-interoperability problem is rare and temporary.

I'm not willing to do that sacrifice because the burden of implementing this
non-contiguous version negotiation is in my view much smaller than
application-specific remedies that will need to be implemented otherwise,
and the user frustration and loss of interoperability that will result.

Besides - a client that supports a contiguous set of versions does not need
to be impacted in any way. Just the server needs to support this extension
to be interoperable at a higher version with clients implementing
non-contiguous versions.


> It's "fancy", i.e. different and more complicated, compared 
> to the good old way of doing version negotiation. I didn't 
> mean any more than that. Sorry for any confusion.

Look at it this way. If we both spent the time we are spending to discuss
this implementing this extension, we both would have had a server and client
implementation already. :-)


Best regards,

denis