Re: SSH v3?

[denis bider <ietf-ssh3%denisbider.com@localhost>]

Hey Bryan -

thank you for sharing this, I was not previously aware of Minion.

The main issue I see is that Minion does in fact seem to require modification at the OS level. Even though the changes needed might be small, this won't fly unless Linux and Windows both decide to support it.

Most SSH implementations I'm aware of are user-mode implementations, by organizations and/or volunteers who are not familiar with, and do not have access to modify, the TCP stack on systems where their SSH implementation runs. This is certainly true for me, I can't change the TCP implementation in Windows.

Without underlying platform support, it seems to me the best that SSH can do is to either (1) implement support for UDP as an ancillary transport for latency-sensitive traffic, or to (2) migrate wholesale to UDP.

My "EST" suggestion rebuilds the whole protocol on top of UDP. But perhaps, implementing support for UDP as an ancillary transport would be a more compatible fit with current SSH usage. And also, as you point out in your paper, it would be a better fit for connections where UDP is not available due to firewall/routing issues.

If you can get Windows + Linux to implement uTCP though, that would have the benefit of avoiding even the firewall/routing issues still faced by UDP.

denis


----- Original Message -----
From: Bryan Ford 
Sent: Wednesday, December 2, 2015 03:39
To: Niels Möller 
Cc: denis bider ; ietf-ssh%netbsd.org@localhost 
Subject: Re: SSH v3?

On 02 Dec 2015, at 09:34, Niels M?ller <nisse%lysator.liu.se@localhost> wrote:
> denis bider <ietf-ssh3%denisbider.com@localhost> writes:
>> - TCP prevents efficient tunneling of datagram flow over an SSH
>> session: introduces unnecessary lag to maintain stream abstraction for
>> applications that don't need it.
> 
> It's definitely possible to tunnel udp over tcp (with or without ssh
> being involved). Whether or not that's good enough depends on the
> application. What are the usecases for udp-tunneling over ssh? You also
> have dtls, which might solve your problem in a better way than ssh (I'm
> sorry I don't know the details of that protocol).

TCP?s enforced in-order delivery on protocols like SSH and TLS that are sometimes used to forward datagrams can indeed create latency problems - and especially ?freezes? in audio/video protocols like Skype that easily tolerate a single dropped frame but freak out when a whole RTT worth of frames gets delayed. 

For that reason I?ve been hoping for a while now that some of these protocols would adopt something like our Minion approach, which allows TCP-based protocols to deliver tunneled datagrams out-of-order:

Fitting Square Pegs Through Round Pipes: Unordered Delivery Wire-Compatible with TCP and TLS
http://dedis.cs.yale.edu/2009/tng/papers/nsdi12-abs

I suspect it wouldn?t be that difficult to evolve OpenSSH protocol to be compatible with Minion and hence able to forward tunneled UDP datagrams out-of-order.  I?d be happy to hear if there?s any interest.  I think it would be easy to incorporate Minion support in OpenSSH in a way that would make things no more complicated for implementations that don?t support it, only a little more complicated for implementations that want to, and ensure that all implementations still interoperate perfectly regardless of which endpoints do and don?t support the out-of-order delivery extension.

Cheers
B