Hello Nicolas, Thank you for the feedback!
On 24/04/2024 17:45, Nicolas CARPi wrote: > Hello, > > On 24 Apr, Dorian Craps wrote: >> This attached patch uses MPTCP by default instead of TCP on Linux. > The backward compatibility of MPTCP is indeed a good point toward > enabling it by default. Nonetheless, I feel your message should include > a discussion on the security implications of this change. > > As you know, v0 had security issues. v1 addresses them, and we can > likely consider that new attacks targeting this protocol will pop up as > it becomes widespread. Indeed, any new features (or code in general) can bring security issues. Same for the protocol. Here it looks like MPTCPv1 addressed all reported issues [1]. > In fact, that's already the case: > > See: CVE-2024-26708: mptcp: really cope with fastopen race > or CVE-2024-26826: mptcp: fix data re-injection from stale subflow > or CVE-2024-26782 kernel: mptcp: fix double-free on socket dismantle > > The three CVEs above are all from April 2024. :-) There were no CVEs linked to MPTCP before Linux being a CNA earlier this year [2]. Now any fixes could automatically get a CVE even if there is no proven security issues [3]. For example, I don't think CVE-2024-26826 can cause security issues, and TCP also got some CVEs recently [4] :) But anyway, here the CVEs are linked to the implementation in the Linux kernel, not the protocol (MPTCPv1). > Given that MPTCP v1 is relatively new (2020), and that we do not have > real assurances that it is at least as secure as plain TCP, I would > humbly suggest inverting the logic, and making it an opt-in option. > > This way, a vulnerability impacting MPTCP would only impact users that > enabled it, instead of 100% of HAProxy users. In a few years, making it > the default could be reconsidered. I understand that it is safer, first, to have an option to enable MPTCP support, then enabling it by default later. But I admit that "In a few years" sounds like "a very long time"! MPTCP has been introduced in 2020, 4 years ago, after more than two year of development. So it had time to mature a bit in 6+ years :) Still under, TCP is being used, it is not a full network implementation. When MPTCP is enabled on the server side, it will only be used when clients request it, without impacting "plain" TCP connections. So enabling it will only impact connections where the client asked to use MPTCP. I agree that it increases the attack surface, but like any new features, no? :) > Please note that I'm simply voicing my concern as a user, and the core > dev team might have a very different view about these aspects. > >> It sounds good to have MPTCP enabled by default > Except when looking at it through the prism of the increased attack > surface! ;) > >> IPPROTO_MPTCP is defined just in case old libC are being used and >> don't have the ref. > Shouldn't it be defined with a value, as per > https://www.mptcp.dev/faq.html#why-is-ipproto_mptcp-not-defined ? > (sorry if it's a dumb remark, I'm not a C dev) IPPROTO_MPTCP is a constant, it is 262. It is just that at build time, some old libC might not have IPPROTO_MPTCP. To avoid compilation errors, IPPROTO_MPTCP is defined if it was not before. MPTCP support is checked at run time. [1] https://datatracker.ietf.org/doc/html/rfc8684#name-security-considerations [2] http://www.kroah.com/log/blog/2024/02/13/linux-is-a-cna/ [3] https://docs.kernel.org/process/cve.html [4] https://lore.kernel.org/linux-cve-announce/?q=s%3Atcp Cheers, Matt -- Sponsored by the NGI0 Core fund.
