News for hackers. Stuff that matters.
Re:Linux Kernel MultiPath TCP Project by datastoat on Sunday October 16, 2022 @07:09AM (#33222730)
MPTCP is a drop-in replacement -- but its original designers were paranoid about e.g. packet-sniffing middleboxes, so they made it opt-in.

Suppose for example there's a packet-sniffing security appliance along the path, and it only sees packets on one path of the MPTCP flow, and it says "This stream of packets doesn't look like a legitimate TCP flow, so it's probably an attack, so I'll block it."

Re:Linux Kernel MultiPath TCP Project by pid-1 on Sunday October 16, 2022 @09:41AM (#33223549)
Tangencial, but that's also the reason QUIC (used by HTTP/3) was built upon UDP.
Re:Linux Kernel MultiPath TCP Project by usrnm on Sunday October 16, 2022 @10:27AM (#33223843)
Wasn't it used to avoid head of line blocking?
Re:Linux Kernel MultiPath TCP Project by tracnar on Sunday October 16, 2022 @11:14AM (#33224189)
Built over UDP rather than directly over IP. Introducing a new layer 4 protocol on the internet is not realistic for the foreseeable future.
Re:Linux Kernel MultiPath TCP Project by londons_explore on Sunday October 16, 2022 @10:31AM (#33223864)
I think the real answer is to test a lot of middleboxes, come up with some fallback behaviour that will at least work with 99% of them, and then just break the last 1%.

The same happened with Max Segment Size detection - and that mostly works now.