Re: SSH v3?

Niels, Denis,
>
>> - 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.

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