From: Geliang Tang <tanggeliang@kylinos.cn>
This adds setsockopt support for TCP_MD5SIG and TCP_MD5SIG_EXT options.
The implementation:
- Allows setting these options (getsockopt remains unsupported)
- Applies them only to the first subflow
- Maintains MD5 compatibility limitations with MPTCP
Note that TCP_MD5SIG and TCP_MD5SIG_EXT are unsupported for TCP too.
Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
---
net/mptcp/sockopt.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/mptcp/sockopt.c b/net/mptcp/sockopt.c
index b264185b810d..5b3e54f7d803 100644
--- a/net/mptcp/sockopt.c
+++ b/net/mptcp/sockopt.c
@@ -567,10 +567,12 @@ static bool mptcp_supported_sockopt(int level, int optname)
case TCP_FASTOPEN_CONNECT:
case TCP_FASTOPEN_KEY:
case TCP_FASTOPEN_NO_COOKIE:
+ case TCP_MD5SIG:
+ case TCP_MD5SIG_EXT:
return true;
}
- /* TCP_MD5SIG, TCP_MD5SIG_EXT are not supported, MD5 is not compatible with MPTCP */
+ /* MD5 is not compatible with MPTCP */
/* TCP_REPAIR, TCP_REPAIR_QUEUE, TCP_QUEUE_SEQ, TCP_REPAIR_OPTIONS,
* TCP_REPAIR_WINDOW are not supported, better avoid this mess
@@ -834,6 +836,8 @@ static int mptcp_setsockopt_sol_tcp(struct mptcp_sock *msk, int optname,
case TCP_FASTOPEN_CONNECT:
case TCP_FASTOPEN_KEY:
case TCP_FASTOPEN_NO_COOKIE:
+ case TCP_MD5SIG:
+ case TCP_MD5SIG_EXT:
return mptcp_setsockopt_first_sf_only(msk, SOL_TCP, optname,
optval, optlen);
}
--
2.48.1Hello! On Wed, Jul 30, 2025 at 12:22 AM Geliang Tang <geliang@kernel.org> wrote: > > From: Geliang Tang <tanggeliang@kylinos.cn> > > This adds setsockopt support for TCP_MD5SIG and TCP_MD5SIG_EXT options. > The implementation: > - Allows setting these options (getsockopt remains unsupported) > - Applies them only to the first subflow > - Maintains MD5 compatibility limitations with MPTCP > > Note that TCP_MD5SIG and TCP_MD5SIG_EXT are unsupported for TCP too. Is there even enough option-space to have co-existence of MPTCP with TCP_MD5 ? I don't think so, right ? The only way they can co-exist is if a bunch of other options are disabled. And in that case, do we really want to use non-MD5 on subsequent subflows ? I doubt that, because the goal of TCP-MD5 is to "improve" security. So, shouldn't we rather disable MPTCP always when an app sets TCP_MD5SIG ? Christoph > > Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn> > --- > net/mptcp/sockopt.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/net/mptcp/sockopt.c b/net/mptcp/sockopt.c > index b264185b810d..5b3e54f7d803 100644 > --- a/net/mptcp/sockopt.c > +++ b/net/mptcp/sockopt.c > @@ -567,10 +567,12 @@ static bool mptcp_supported_sockopt(int level, int optname) > case TCP_FASTOPEN_CONNECT: > case TCP_FASTOPEN_KEY: > case TCP_FASTOPEN_NO_COOKIE: > + case TCP_MD5SIG: > + case TCP_MD5SIG_EXT: > return true; > } > > - /* TCP_MD5SIG, TCP_MD5SIG_EXT are not supported, MD5 is not compatible with MPTCP */ > + /* MD5 is not compatible with MPTCP */ > > /* TCP_REPAIR, TCP_REPAIR_QUEUE, TCP_QUEUE_SEQ, TCP_REPAIR_OPTIONS, > * TCP_REPAIR_WINDOW are not supported, better avoid this mess > @@ -834,6 +836,8 @@ static int mptcp_setsockopt_sol_tcp(struct mptcp_sock *msk, int optname, > case TCP_FASTOPEN_CONNECT: > case TCP_FASTOPEN_KEY: > case TCP_FASTOPEN_NO_COOKIE: > + case TCP_MD5SIG: > + case TCP_MD5SIG_EXT: > return mptcp_setsockopt_first_sf_only(msk, SOL_TCP, optname, > optval, optlen); > } > -- > 2.48.1 > >
Hi Christoph, On 31/07/2025 00:19, Christoph Paasch wrote: > Hello! > > On Wed, Jul 30, 2025 at 12:22 AM Geliang Tang <geliang@kernel.org> wrote: >> >> From: Geliang Tang <tanggeliang@kylinos.cn> >> >> This adds setsockopt support for TCP_MD5SIG and TCP_MD5SIG_EXT options. >> The implementation: >> - Allows setting these options (getsockopt remains unsupported) >> - Applies them only to the first subflow >> - Maintains MD5 compatibility limitations with MPTCP >> >> Note that TCP_MD5SIG and TCP_MD5SIG_EXT are unsupported for TCP too. > > Is there even enough option-space to have co-existence of MPTCP with > TCP_MD5 ? I don't think so, right ? > > The only way they can co-exist is if a bunch of other options are > disabled. And in that case, do we really want to use non-MD5 on > subsequent subflows ? I doubt that, because the goal of TCP-MD5 is to > "improve" security. Correct, there is not enough space, and it doesn't make sense to use MPTCP with TCP_MD5. The patch description should be clearer about that: supporting TCP_MD5 makes sense when MPTCP is used by default when creating a socket. With Go, all "stream" listening sockets are MPTCP sockets. MPTCP might not be used, but without this series, we have a "regression" compared to TCP because TCP_MD5 cannot be used. See: https://github.com/multipath-tcp/mptcp_net-next/issues/575 > So, shouldn't we rather disable MPTCP always when an app sets TCP_MD5SIG ? Yes, but no need to do anything else, because a fallback will be done in mptcp_connect() and subflow_check_req(). (even if I guess an extra protection is always OK there). Cheers, Matt -- Sponsored by the NGI0 Core fund.
On Thu, Jul 31, 2025 at 2:40 AM Matthieu Baerts <matttbe@kernel.org> wrote: > > Hi Christoph, > > On 31/07/2025 00:19, Christoph Paasch wrote: > > Hello! > > > > On Wed, Jul 30, 2025 at 12:22 AM Geliang Tang <geliang@kernel.org> wrote: > >> > >> From: Geliang Tang <tanggeliang@kylinos.cn> > >> > >> This adds setsockopt support for TCP_MD5SIG and TCP_MD5SIG_EXT options. > >> The implementation: > >> - Allows setting these options (getsockopt remains unsupported) > >> - Applies them only to the first subflow > >> - Maintains MD5 compatibility limitations with MPTCP > >> > >> Note that TCP_MD5SIG and TCP_MD5SIG_EXT are unsupported for TCP too. > > > > Is there even enough option-space to have co-existence of MPTCP with > > TCP_MD5 ? I don't think so, right ? > > > > The only way they can co-exist is if a bunch of other options are > > disabled. And in that case, do we really want to use non-MD5 on > > subsequent subflows ? I doubt that, because the goal of TCP-MD5 is to > > "improve" security. > > Correct, there is not enough space, and it doesn't make sense to use > MPTCP with TCP_MD5. > > The patch description should be clearer about that: supporting TCP_MD5 > makes sense when MPTCP is used by default when creating a socket. With > Go, all "stream" listening sockets are MPTCP sockets. MPTCP might not be > used, but without this series, we have a "regression" compared to TCP > because TCP_MD5 cannot be used. > > See: https://github.com/multipath-tcp/mptcp_net-next/issues/575 > > > So, shouldn't we rather disable MPTCP always when an app sets TCP_MD5SIG ? > > Yes, but no need to do anything else, because a fallback will be done in > mptcp_connect() and subflow_check_req(). (even if I guess an extra > protection is always OK there). Alright! Now I see the code in subflow_check_req(). But, it looks like we send a RST, no ? I can give it a try later. Christoph > > Cheers, > Matt > -- > Sponsored by the NGI0 Core fund. >
On 31/07/2025 18:02, Christoph Paasch wrote: > On Thu, Jul 31, 2025 at 2:40 AM Matthieu Baerts <matttbe@kernel.org> wrote: >> >> Hi Christoph, >> >> On 31/07/2025 00:19, Christoph Paasch wrote: >>> Hello! >>> >>> On Wed, Jul 30, 2025 at 12:22 AM Geliang Tang <geliang@kernel.org> wrote: >>>> >>>> From: Geliang Tang <tanggeliang@kylinos.cn> >>>> >>>> This adds setsockopt support for TCP_MD5SIG and TCP_MD5SIG_EXT options. >>>> The implementation: >>>> - Allows setting these options (getsockopt remains unsupported) >>>> - Applies them only to the first subflow >>>> - Maintains MD5 compatibility limitations with MPTCP >>>> >>>> Note that TCP_MD5SIG and TCP_MD5SIG_EXT are unsupported for TCP too. >>> >>> Is there even enough option-space to have co-existence of MPTCP with >>> TCP_MD5 ? I don't think so, right ? >>> >>> The only way they can co-exist is if a bunch of other options are >>> disabled. And in that case, do we really want to use non-MD5 on >>> subsequent subflows ? I doubt that, because the goal of TCP-MD5 is to >>> "improve" security. >> >> Correct, there is not enough space, and it doesn't make sense to use >> MPTCP with TCP_MD5. >> >> The patch description should be clearer about that: supporting TCP_MD5 >> makes sense when MPTCP is used by default when creating a socket. With >> Go, all "stream" listening sockets are MPTCP sockets. MPTCP might not be >> used, but without this series, we have a "regression" compared to TCP >> because TCP_MD5 cannot be used. >> >> See: https://github.com/multipath-tcp/mptcp_net-next/issues/575 >> >>> So, shouldn't we rather disable MPTCP always when an app sets TCP_MD5SIG ? >> >> Yes, but no need to do anything else, because a fallback will be done in >> mptcp_connect() and subflow_check_req(). (even if I guess an extra >> protection is always OK there). > > Alright! Now I see the code in subflow_check_req(). But, it looks like > we send a RST, no ? I can give it a try later. Oh, you are right, I missed that. Then probably we need to force a fallback if mptcp_setsockopt_first_sf_only() was successful. (@Geliang: that's why we do need the Packetdrill test :) ) Cheers, Matt -- Sponsored by the NGI0 Core fund.
Hi Christoph, On Wed, 2025-07-30 at 15:19 -0700, Christoph Paasch wrote: > Hello! > > On Wed, Jul 30, 2025 at 12:22 AM Geliang Tang <geliang@kernel.org> > wrote: > > > > From: Geliang Tang <tanggeliang@kylinos.cn> > > > > This adds setsockopt support for TCP_MD5SIG and TCP_MD5SIG_EXT > > options. > > The implementation: > > - Allows setting these options (getsockopt remains unsupported) > > - Applies them only to the first subflow > > - Maintains MD5 compatibility limitations with MPTCP > > > > Note that TCP_MD5SIG and TCP_MD5SIG_EXT are unsupported for TCP > > too. > > Is there even enough option-space to have co-existence of MPTCP with > TCP_MD5 ? I don't think so, right ? > > The only way they can co-exist is if a bunch of other options are > disabled. And in that case, do we really want to use non-MD5 on > subsequent subflows ? I doubt that, because the goal of TCP-MD5 is to > "improve" security. > > So, shouldn't we rather disable MPTCP always when an app sets > TCP_MD5SIG ? I just updated this in v2 as you suggested. Thanks, -Geliang > > > Christoph > > > > > Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn> > > --- > > net/mptcp/sockopt.c | 6 +++++- > > 1 file changed, 5 insertions(+), 1 deletion(-) > > > > diff --git a/net/mptcp/sockopt.c b/net/mptcp/sockopt.c > > index b264185b810d..5b3e54f7d803 100644 > > --- a/net/mptcp/sockopt.c > > +++ b/net/mptcp/sockopt.c > > @@ -567,10 +567,12 @@ static bool mptcp_supported_sockopt(int > > level, int optname) > > case TCP_FASTOPEN_CONNECT: > > case TCP_FASTOPEN_KEY: > > case TCP_FASTOPEN_NO_COOKIE: > > + case TCP_MD5SIG: > > + case TCP_MD5SIG_EXT: > > return true; > > } > > > > - /* TCP_MD5SIG, TCP_MD5SIG_EXT are not supported, > > MD5 is not compatible with MPTCP */ > > + /* MD5 is not compatible with MPTCP */ > > > > /* TCP_REPAIR, TCP_REPAIR_QUEUE, TCP_QUEUE_SEQ, > > TCP_REPAIR_OPTIONS, > > * TCP_REPAIR_WINDOW are not supported, better > > avoid this mess > > @@ -834,6 +836,8 @@ static int mptcp_setsockopt_sol_tcp(struct > > mptcp_sock *msk, int optname, > > case TCP_FASTOPEN_CONNECT: > > case TCP_FASTOPEN_KEY: > > case TCP_FASTOPEN_NO_COOKIE: > > + case TCP_MD5SIG: > > + case TCP_MD5SIG_EXT: > > return mptcp_setsockopt_first_sf_only(msk, SOL_TCP, > > optname, > > optval, > > optlen); > > } > > -- > > 2.48.1 > > > >
Hi Geliang, On 30/07/2025 09:22, Geliang Tang wrote: > From: Geliang Tang <tanggeliang@kylinos.cn> > > This adds setsockopt support for TCP_MD5SIG and TCP_MD5SIG_EXT options. > The implementation: > - Allows setting these options (getsockopt remains unsupported) > - Applies them only to the first subflow > - Maintains MD5 compatibility limitations with MPTCP > > Note that TCP_MD5SIG and TCP_MD5SIG_EXT are unsupported for TCP too. > > Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn> > --- > net/mptcp/sockopt.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/net/mptcp/sockopt.c b/net/mptcp/sockopt.c > index b264185b810d..5b3e54f7d803 100644 > --- a/net/mptcp/sockopt.c > +++ b/net/mptcp/sockopt.c > @@ -567,10 +567,12 @@ static bool mptcp_supported_sockopt(int level, int optname) > case TCP_FASTOPEN_CONNECT: > case TCP_FASTOPEN_KEY: > case TCP_FASTOPEN_NO_COOKIE: > + case TCP_MD5SIG: > + case TCP_MD5SIG_EXT: > return true; > } > > - /* TCP_MD5SIG, TCP_MD5SIG_EXT are not supported, MD5 is not compatible with MPTCP */ > + /* MD5 is not compatible with MPTCP */ Maybe best to update this comment too and move it on top of "case TCP_MD5SIG": /* MD5 will force a fallback to TCP: OK to set while not connected */ > > /* TCP_REPAIR, TCP_REPAIR_QUEUE, TCP_QUEUE_SEQ, TCP_REPAIR_OPTIONS, > * TCP_REPAIR_WINDOW are not supported, better avoid this mess > @@ -834,6 +836,8 @@ static int mptcp_setsockopt_sol_tcp(struct mptcp_sock *msk, int optname, > case TCP_FASTOPEN_CONNECT: > case TCP_FASTOPEN_KEY: > case TCP_FASTOPEN_NO_COOKIE: > + case TCP_MD5SIG: > + case TCP_MD5SIG_EXT: > return mptcp_setsockopt_first_sf_only(msk, SOL_TCP, optname, > optval, optlen); Just to be sure, can you check if this option will correctly fail if the setsockopt(TCP_MD5SIG*) are used after the establishment of the connection? I think it is important to set these MD5 options only if the connection is in CLOSED or LISTENED state. I don't think we want to deal with this socket option for ongoing MPTCP connections. > } Cheers, Matt -- Sponsored by the NGI0 Core fund.
© 2016 - 2025 Red Hat, Inc.