Mptcp support

[evrardco]

The first commit on this branch of our fork is a patch aimed at providing openssh with MPTCP support, the rest are to udapte the man pages and config according to the new MPTCP support.

MPTCP stands for multipath tcp, it can be seen as an extension to tcp sockets which allows the use of multiple network interface at the same time, or to switch from one to another seamlessly. The support for MPTCP is native in the more recent linux kernels, so it is only natural that it becomes native for openssh as well.

The changes to the code base are minimal and the use of MPTCP is controlled by a yes/no configuration parameter "UseMPTCP". This port was made during the OpenWeek event of this year at UCLouvain, in collaboration with Professor Olivier Bonaventure, his research team (mainly François Michel and Maxime Piraux) along with a few students, including me (Colin Evrard), Maxime Postaire and Simon Arys.

The main part of our work was about testing the implementation under various conditions, including real world ones, which is all described in this blog post article.

[djmdjm]

Sorry, we're not willing to support a protocol that is only available on one of the platforms that OpenSSH supports. If/when MPTCP becomes more widely supported we can reconsider.

Until then I recommend that users who want MPTCP to use a ProxyCommand on the client or an equivalent wrapper for sshd

[voidpointertonull]

Sorry, we're not willing to support a protocol that is only available on one of the platforms that OpenSSH supports. If/when MPTCP becomes more widely supported we can reconsider.

Could you elaborate on what lead to this decision and conclusion?

While obviously your point of view can be understood better once you expand on that, as I see the current decision to be hasty and possibly misguided given that:

• The new parameter merely signals opting into protocol extensions without actually having to support them. You've surely seen that it's just an extra parameter affecting one of the parameters of a single syscall, everything else is boilerplate, so there is no need for protocol supporting code.
• While MPTCP is indeed not widespread yet, the experimental standard RFC 6824 ended up having implementations for many platforms. You are likely thinking only of the currently pushed RFC 8684, which indeed may have a native implementation on only a single platform currently. Regardless of which standard is being used, programs need to opt into using the extensions, and while I am not fully certain that opting in is done the exact same way, there will be surely no cross-platform standard for syscall details either.
• Even though kernel-level support may be lacking, note that RFC 8684 can be already considered multi-platform even if it's not natively supported yet on multiple platforms: https://github.com/ngi-mptcp/curl/wiki/Multipath-TCP-on-Windows-10
• I believe there's not much to support to begin with given how trivial the provided code is, and how well it is constructed to be out of the way by default unless it's explicitly turned on by the user. Of course I honor your desire to include only what you deem worthy, but one of the significant reasons why I'm inquiring how high is the bar is, because the project seems to support odd niches too, like providing workarounds for the broken and hostile platform, Android.

I hope I could put this small pull request in a different light, and I humbly request you to reconsider the inclusion.
While you are correct regarding wrappers and shims working like they always were, I am looking forward to such friction points getting removed which is an important step in solving the chicken and egg problem of both individual project maintainers, and OS developers avoiding considering support before mass adoption.

The only horse I have in the race is the continuous need to look for ways to improve both the performance and reliability of my SSH connections because even when not working in quite isolated areas as far as internet connectivity goes, I am not fortunate enough to have a high speed or at least reliable connection.
While the OpenSSH project is surely not supposed to solve all of the problems of the world, given the (unfortunately removed) roaming, and the compression option, it does appear to be concerned with such reliability and performance problems which is at least partially resolved by MPTCP.

[cpaasch]

MPTCP is supported on macOS as well. So, that would make it 2 platforms already.

[kilobyte]

The patch as-is makes ssh gripe: setsockopt socket 3 IPV6_TCLASS 16: Operation not supported — this seems like a kernel issue though, thus I'm mostly noting this for the benefit of others who want to test.

[kilobyte]

This patch is extremely non-intrusive: almost all it does is:

if (option)
  IPPROTO_MPTCP
else
  ai->ai_protocol

plus a crapload of lines of option parsing. This doesn't strike me as something that's a maintenance burden.

[tbarbette]

These 4 lines would solve the main reason people use Mosh instead of SSH, I think. That is connection breaking when you hop between WiFi/Ethernet/mobile.

Out of the main 3 platforms, only Windows does not implement mptcp, but WSL can still benefit from it. From what I see around me, people are largely leaving putty&friends for SSH in WSL.

[sskras]

@cpaasch commented on Sep 15, 2022:

MPTCP is supported on macOS as well. So, that would make it 2 platforms already.

Is that implementation of v0 (RFC 6824) or v1 (RFC 8684) already?

[cpaasch]

@cpaasch commented #335 (comment):

MPTCP is supported on macOS as well. So, that would make it 2 platforms already.
Is that implementation of v0 (RFC 6824) or v1 (RFC 8684) already?

macOS supports both, v0 and v1. It tries v1 first and has logic to fallback to v0,...