Re: SFTP v6?

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

Joseph Galbraith <galb-list%vandyke.com@localhost> writes:

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

At least conceptually, ssh channels are farily lightweight. Ok, a
typical implementation with sftp as a separate process will spawn one
process for each channel, which wastes some resources, but I'm not
sure optimal resource usage is important for the backwards compatibility
case.

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

I'm not sure if you're thinking about the server or client now, but as
far as I can see, the interface is clean in both cases.

The sftp client asks the lower layer (ssh connection) for a session
channel, and asks it to start the sftp subsystem. And it sometimes
does that twice. But it's identical both times, no "private data"
involved. Then, the request for a session channel may or may not imply
a new ssh connection, but that's an implementation issue. One case
that I expect to be common when efficiency matters, is to keep an ssh
connection in the background, like the lsh gateway mode, or the
corresponding feature in recent openssh. Then *all* sftp sessions
channels to the same host will reuse an existing connection, no matter
which versions they want to use.

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

It's more complete than version negotiation in most protocols. Most
protocols seem to work fine without completeness, though.

I think the reason we seem to be getting into trouble is the rapid
increments to the version number, with corresponding changes that
aren't backwards compatible at all. Development of most other internet
protocols (including ssh!) pays more attention to backwards
compatibility, and bumps the protocol version number very rarely.

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

Just some tangential comments: If we go this way, then the "version
numbers" need not be numbers at all, they can be arbitrary names, with
no ordering attached by the protocol. Then an alternative approach
(which I'm not advocating) is to delete version negotiation from the
sftp protocol completely, just have different subsystem names, sftp1,
sftp3, sftp6, .... The client asks for the subsystem type it wants, in
can make multiple requests in any order of its choice.

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

I think this is one of the stronger arguments for your proposal.

I tend to be somewhat negative to all general protocol changes (as I'm
sure you've noticed ;-), but I guess I ought to be less conservative
with sftp than with ssh proper.

Regards,
/Niels