Re: [rfbhackers] using SSH2

[Michael O. <mic...@al...>]

On Thu, Jan 17, 2002 at 10:40:41AM +1100, Andrew van der Stock wrote:
> It'd be better if we tracked IETF's secsh rather than ssh2 per se.

Yeah, the secsh group work is actually what I meant by SSH2.

> Also, secsh/ssh2 is fairly large, which is a consideration for smaller
> clients. 

Have you taken a look at the size of a minimal secsh client?  The only
required algorithms are 3des-cbc, hmac-sha1, diffie-hellman-group1-sha1,
and publickey/dss authentication.  There are no required compression
algorithms, and I don't think there are any required channel types on
the client side.  I think it could be pretty small.  There is a good
argument about packet size in the Architecture draft.

> However, you are right, if we go to secsh for the transport (and I like the
> idea of using its channels), we can't be on port 5900 and allow RFB 3.x
> clients to connect as the server gets to talk first. We'd have to choose
> another port. We could have a fall through that starts the negotiation after
> RFB 4.x is selected, like we do at the moment, to fix that, but we wouldn't
> be a pure secsh enabled protocol.

We could define a new port, encourage 3.x compatibility on the old ports
(and over tunnels), and forget about fall-through.  I don't know how
strongly people feel about this issue.

> Prioritization is a method of fixing interactivity problems. I wanted to
> ensure that all packets are not too large, and that things like file
> transfers were done when literally nothing else was happening so as to not
> freeze the interface. 

That would definitely be a good thing.  It seems like we should be able
to build this on top of secsh channels.

By the way, have you been in contact with the ORL people at all?  I
noticed the draft mentions an internal version (and I've seen their web
page about it), but I was wondering if they have had any input or made
any statements for or against an open protocol discussion (and the
potential hijacking of their protocol name :-)

-- 
Mike Ossmann, Tarantella/UNIX Engineer/Instructor
Alternative Technology, Inc.  http://www.alttech.com/