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-00A 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