Subject: Re: SSH v3?

From: [email-masked] (Niels Möller)
Date: Wed, 02 Dec 2015 09:34:58 +0100

denis bider <[email-masked]> writes:

> - On connections prone to random errors (wireless), large transfers
> are bound for disconnects at a rate of 2^-16 per error. TCP just
> corrupts the data in this case. SSH detects the corruption, but cannot
> recover from it.
> - A TCP connection can be reset by a single spoofed RST packet from
> anyone who knows the IP address and port number of one of the end
> points.

So you're basically saying that tcp sucks. That's not very ssh specific.

Maybe it would make sense with some mechanism to let ssh reconnect after
a tcp connection fails. You may also want to have a look at mptcp,
which, among other things, can let a connection survive failure of a
single tcp flow.

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

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.

---

From: denis bider <[email-masked]>
Date: Tue, 1 Dec 2015 22:23:24 +0000

TCP is not reliable:

- On connections prone to random errors (wireless), large transfers are bound for disconnects at a rate of 2^-16 per error. TCP just corrupts the data in this case. SSH detects the corruption, but cannot recover from it.
- A TCP connection can be reset by a single spoofed RST packet from anyone who knows the IP address and port number of one of the end points.

Further:

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

TCP is neither reliable, nor secure. Its weaknesses break SSH sessions beyond recovery. It's the single biggest weakness of SSH in practice.

----- Original Message -----
From: Niels "Möller" 
Sent: Tuesday, December 1, 2015 05:51
To: denis bider 
Cc: Damien Miller ; Simon Tatham ; Simon Josefsson ; [email-masked] 
Subject: Re: SSH v3?

denis bider <[email-masked]> writes:

> SSHv3 is based on UDP, not TCP.

Why??? To me, a reliable byte stream as provided by tcp seems like a
building block fitting ssh needs pretty well.

If you want to do that, and support filetransfers or anything else with
the potential to use significant bandwidth, and get it blessed by ietf,
you'd have to implement your own congestion control.

Not that I have anything against congestion control work in general. I
have even given in to the temptation and designed my own, during my phd
studies. See https://www.lysator.liu.se/~nisse/network-book/. But I
don't think this is the right place for congestion control work.

Regards,
/Niels

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 5 Dec 2015 23:37:17 +0000

denis bider <[email-masked]> writes:

>TCP is neither reliable, nor secure. Its weaknesses break SSH sessions beyond
>recovery. It's the single biggest weakness of SSH in practice.

TCP is good enough for most purposes.  SSH's initial purpose was to replace
telnet and FTP, which a TCP-based mechanism does admirably.  It's only when
SSH2 tried to also be a VPN that problems arose.  So for people using it for
its initial purpose, it's just fine.

Another problem with switching to UDP is that you now have to emulate TCP's
reliable transport using UDP.  Your SSH implementation needs to reinvent a lot
of TCP just to work, which is a lot of pain and complexity to deal with.  Not
to mention that every single new implementation gets to make all the mistakes
that have been bred out of TCP stacks over the last 20-30 years all over
again.

(I don't really have anything against an option to do SSH over UDP if people
want to, which means you've now got SSH trying to compete with both IPsec and
DTLS, but I don't want to see it made mandatory.  Approximately, oh, 100.0% of
my users use SSH as a secure telnet and FTP, not a VPN).

Peter.

---

From: Olivier Bonaventure <[email-masked]>
Date: Sun, 6 Dec 2015 23:13:28 +0100

Niels, Denis,
> which, among other things, can let a connection survive failure of a

Indeed, mptcp can cope with several of the issues that you mention. Upon 
reception of a (spurious, fake, middlebox-generated,...) RST, MPTCP can 
preserve the connection and restablish a subflow.

MPTCP is also able to use different paths simultaneously, which brings 
interesting benefits and challenges from a security viewpoint.

MPTCP has been standardised by the IETF (RFC6824), and there are 
implementations for Linux (http://www.multipath-tcp.org), Apple (iOS and 
Macos ship it but only enable it for Siri), FreeBSD (partial) and Oracle.

It is also possible to better integrate a security protocol like SSH 
with the underlying MPTCP. I wrote a first step in this direction last 
year for TLS :

https://tools.ietf.org/html/draft-bonaventure-mptcp-tls-00

A similar approach could be used for SSH. Basically, the main idea is to 
delegate the authentication of the received data to MPTCP so that MPTCP 
can detect packet errors and recover at this layer (e.g. by releasing a 
subflow and restating another one) without forcing the security protocol 
to terminate the session because an invalid data was received.

Olivier