Re: SFTP v6?

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

Niels Möller wrote:
> 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.

Client...

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

But in order for kludge mode to work, the second time
it starts the sftp subsystem, it has to pass down
the server version it got from the first attempt.  (So
that the second time around the client can send the
version that will have the server pick the right version.)

(In our software, it is all one process, but different objects.)

The problem is that kludge mode requires me to either
reset an an object (complex) and give that object a
way to ask the lower layer to restart it's underlying
transport, or to persist some state from the object (the
version from the sftp server) and provide a way to restart.

'file-share', at least for my implementation, works the way
you are describing, because I don't have to get into the
middle of the sftp protocol before finding out it doesn't
work.  The lower layer starts one, and if it doesn't work,
it starts the other.

> [...]

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

On the other hand, it seems like there were several
occasions were we punted on a problem or choose a
sub-optimal solution because we had to maintain
backwards compatibility.

So it does swing both ways.

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

Yes; that had occurred to me.  I'm not sure we'd ever take
advantage of it, but it is possible.

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

Yes, this is a very significant point.

I tried to change the version negotiation back when
I first started editing sftp so that the server sent
back it's version (V_S rather than V_U)... which
at least gives the server something valid to send
when version negation fails, but we had to back
it out because of backwards compatibility.

The other argument that is strong to me is that
the new proposal works better than what we have
for someone implementing only the latest version.

I.e., the protocol we go to RFC with will be simpler,
not more complex, because of it.  (Even if clients and
servers doing backwards compatibility do get a little
more complex.)

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

I tend to be quite negative towards protocol changes in SSH proper...
however, sftp hasn't gone to last call yet (for good reason...) and
so isn't in the same semi-frozen state as the SSH proper.

(I hope to get there soon though :-)

Joseph