On Wed, Jan 29, 2025 at 02:47:19PM +0300, Mikhail Ivanov wrote: > On 1/29/2025 2:33 PM, Matthieu Baerts wrote: > > On 29/01/2025 12:02, Mikhail Ivanov wrote: > > > On 1/29/2025 1:25 PM, Matthieu Baerts wrote: > > > > Hi Mikhail, > > > > > > > > On 29/01/2025 10:52, Mikhail Ivanov wrote: > > > > > On 1/28/2025 9:14 PM, Matthieu Baerts wrote: > > > > > > Hi Mikhail, > > > > > > > > > > > > Sorry, I didn't follow all the discussions in this thread, but here are > > > > > > some comments, hoping this can help to clarify the MPTCP case. > > > > > > > > > > Thanks a lot for sharing your knowledge, Matthieu! > > > > > > > > > > > > > > > > > On 28/01/2025 11:56, Mikhail Ivanov wrote: > > > > > > > On 1/27/2025 10:48 PM, Mickaël Salaün wrote: > > > > > > > > > > > > (...) > > > > > > > > > > > > > > I'm a bit worried that we miss some of these places (now or in future > > > > > > > > kernel versions). We'll need a new LSM hook for that. > > > > > > > > > > > > > > > > Could you list the current locations? > > > > > > > > > > > > > > Currently, I know only about TCP-related transformations: > > > > > > > > > > > > > > * SMC can fallback to TCP during connection. TCP connection is used > > > > > > > (1) to exchange CLC control messages in default case and (2) > > > > > > > for the > > > > > > > communication in the case of fallback. If socket was connected or > > > > > > > connection failed, socket can not be reconnected again. There > > > > > > > is no > > > > > > > existing security hook to control the fallback case, > > > > > > > > > > > > > > * MPTCP uses TCP for communication between two network interfaces > > > > > > > in the > > > > > > > default case and can fallback to plain TCP if remote peer does not > > > > > > > support MPTCP. AFAICS, there is also no security hook to > > > > > > > control the > > > > > > > fallback transformation, > > > > > > > > > > > > There are security hooks to control the path creation, but not to > > > > > > control the "fallback transformation". > > > > > > > > > > > > Technically, with MPTCP, the userspace will create an IPPROTO_MPTCP > > > > > > socket. This is only used "internally": to communicate between the > > > > > > userspace and the kernelspace, but not directly used between network > > > > > > interfaces. This "external" communication is done via one or multiple > > > > > > kernel TCP sockets carrying extra TCP options for the mapping. The > > > > > > userspace cannot directly control these sockets created by the kernel. > > > > > > > > > > > > In case of fallback, the kernel TCP socket "simply" drop the extra TCP > > > > > > options needed for MPTCP, and carry on like normal TCP. So on the wire > > > > > > and in the Linux network stack, it is the same TCP connection, without > > > > > > the MPTCP options in the TCP header. The userspace continue to > > > > > > communicate with the same socket. > > > > > > > > > > > > I'm not sure if there is a need to block the fallback: it means only > > > > > > one > > > > > > path can be used at a time. Thanks Matthieu. So user space needs to specific IPPROTO_MPTCP to use MPTCP, but on the network this socket can translate to "augmented" or plain TCP.
