Re: SFTP v6?

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

Niels Möller wrote:
> Joseph Galbraith <galb-list%vandyke.com@localhost> writes:
>
>
> > 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.)
>
>
> Thanks for the correction. Let's see if I understand what this implies
> for interoperability. The failure, for traditional version exchange,
> seems to be
>
>   * Client supporting version 3 and 6.
>   * Server supporting version 3 and 4.
>
>   =>  V_U = 4  =>  communication failure.
>
> Is this correct?

Yes, I believe this is the case.

[...]

> I agree this is a clean solution, in line with how the rest of the ssh
> protocol works. However, let's compare how it will work in practice
> during the transition period (next few years), with particular focus
> on our failure case: a client supporting versions 3 and 6, and an old
> server supporting versions 3 and 4.

[...description omitted for brevitty...]

> Do I understand your proposal correctly?

Yes, I think you do.

> Now compare this to the
> "kludge" that can be used without any changes to the current protocol:

[...description omitted for brevitty...]

I suppose that the kludge isn't that bad.

> In this case (which I think is the most central problematic case which
> we're trying to address) I don't see a big win in introducing
> "file-share". It makes things only slightly easier for the client, and
> slightly more complex for the server.
>
> And when having this choice, I usually prefer putting the complexity
> in the client. The reason is that complexity always increases the risk
> for bugs, and bugs usually have a much worse security impact in the
> server than in the client.

In general I agree, I'd rather have complexity in the client than the
server, however, in this case, I think the additional complexity in
the server is pretty small for 'file-share' and the additional
complexity in the client for 'kludge-mode' is significantly higher
degree than increased complexity for 'file-share'.

In fact, 'kludge-mode' requires the entire channel to go down and
be reopened.  'file-share' experiences a failure to start a subsystem,
and so requests a different one, but shouldn't require the channel
to go down.

Put another way, I have a lower layer (connection) that starts an
upper layer protocol (sftp).  In kludge mode, that upper layer now
has to:

 a. pass back private data to the lower, connection, layer (the server
    sftp version) and a request the connection layer to restart
    the sftp layer with the version as a parameter.

    --or--

 b. Emulate the lower layer itself to start a new channel.

With file-share, this complexity occurs along a more natural border
(at least in my software), because the channel doesn't have to go
down.

In addition, their are several reasons I feel strongly about the
'file-share' proposal.

1. I believe it is the better version negotiation protocol.

2. It works the way you thought it did :-), with client and
   server both announcing their versions to the other.

   As you noted, this is the way many protocols work,
   and I think it is more intuitive.

3. It is familiar to SSH implementors in it's specific
   algorithm (choose first item on client list also on
   servers.)

4. When a version negotiation failure occurs, both sides
   know why, because they both have the same information.

   This leads to better error messages and easier trouble
   shooting for sys admins and tech support.

   In fact, with the current draft, if the server doesn't
   support the clients version at all (v2-4 client, v6
   only server), the server has to close the connection,
   there is no way to communicate to the client why it
   did so.

   Until we had this discussion, I would have assumed, as
   a tech support, admin, or implementor, that the server
   had a bug and crashed, not that there was a version
   problem.

5. It allows extension of the startup protocol on both
   sides, not just the server.

6. For a brand new latest-version-only implementation,
   it reduces complexity.  There is one less packet type, one
   less error condition on each side (the server sent me a client
   init packet, or visa versa.)

   So, it reduces burden on new implementations while only adding
   a little complexity to existing implemenations.

   This is important because one presumes there will be more
   implementations after we get to RFC, that don't want / need
   to be burden with all of our intermediate baggage.

7. It is faster (saves half a round trip.)

   Even in compatibility mode, when the client has to fall back
   to 'sftp', it is only one extra round trip, as compared
   to kludge mode which requires a channel open, subsystem
   request, sftp-init, and sftp-version, and channel close
   (5 round trips) before it can fall back to the version
   that will inter-operate.

   [Note this is least significant to me, but still a property
    of the proposal.]

In other words, outside of the fact that it solves the
version problem we've been discussing, I think it is
just plain a better way to go.

Thanks,

- Joseph