Re: SFTP v6?

[nisse%lysator.liu.se@localhost (Niels Möller)]

"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 scheme is used in lots of protocols, including ssh and sftp (at
least up to now).

If both server and client supports a continuous set of version
numbers, this negotiation scheme is perfect: if there is any version
that both parties supports, V_U = max { version numbers supported by
both parties }.

The limitation of this scheme, is that if client or server supports a
discontinuous set of version numbers, negotiation can fail even if
there is some version that both sides support.

Our problem case is: A supports versions { 3, 4 }, B supports { 3, 6
}. Then V_U = 4, which isn't supported by B, and hence negotiation
fails. Hence, A are B not interoperatable, while a different
negotiation scheme could come up with V_U = 3 and succeed.

My first comment is that this can happen only if the client or server
actually advertises 4 (or 5) as V_C/V_S. How much deployed code out
there actually do that?

My counterproposal is to keep the old version negotiation, and add the
following note on version negotiation:

  The sftp protocol uses the traditional version negotiation mechanism
  where each side advertise the highest version number it supports,
  and the smallest of these two numbers are selected for use.
  Communication is possible if this selected version is supported by
  both sides.

  This mechanism is widely used in Internet protocols, but it also has
  some limitations. For example, if one side supports versions 3 and
  4, and the other supports versions 3 and 6, the output of the
  version negotiation is that version 4 should be used. Communication
  fails, even though there is one protocol version, namely 3, that is
  supported by both sides. 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.

  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. In the above example, if either
  side is configured to advertise version 3 as the highest supported
  version, i.e. to pretend that the support for the higher version
  protocol is non-existant, then the output from the version
  negotiation is version 3, which both sides support.

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.

Am I alone in that?

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

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

> I don't know why you label it as "fancy", because fancy is not what
> it is.

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.

Best regards,
/Niels