On Fri, Aug 23, 2024 at 05:11:11PM +0200, Matthieu Baerts wrote: > >>> With that said, from an implementation perspective, it would seem right > >>> to make sure that most TCP tunables also work with MPTCP. > >> > >> That's what we tried to do. All "common" ones are supported, but it is > >> not always easy to define what is "common" and what is not! There are > >> many obscure/specific socket options out there :) > > > > I agree :-) For example we're using other horrors such as TCP_REPAIR, > > which was initially defined for CRIU, and that we're using to silently > > destroy a connection without responding. It's extremely effective against > > HTTP botnets as they keep their connection pending and do not consume > > anything locally. I don't know if you have it, but if you're interested > > in giving it a try, I can help you set it up in haproxy for a test. > > Wow, nice bazooka :-)
:-) > Here is what we can currently find in the MPTCP code in the kernel: > > /* TCP_REPAIR, TCP_REPAIR_QUEUE, TCP_QUEUE_SEQ, TCP_REPAIR_OPTIONS, > * TCP_REPAIR_WINDOW are not supported, better avoid this mess > */ > > Maybe a new socket option would be better if the idea is only to > silently drop connections? :) Yes, probably. Right now it's done directly in the action itself (tcp_exec_action_silent_drop()), and we already detect if the option is supported, so that would just be a matter of checking more explicitly for conn->ctrl->proto == mptcp and using the other option. In any case the code *tries* to make use of this, and will fall back to other methods. One of them is to try to change the TTL of the socket before closing (so that the RST doesn't reach the client). And when all of this fails, the connection is closed anyway, so it's just not silent. As such, there's no harm at all in not supporting this at all, it's just less optimal. > (If these botnets are using "plain" TCP, the TCP_REPAIR socket option > will work!) Ah, good to know! I guess we still have quite some time ahead before they start playing with mptcp by default, so for most use cases it will be fine! Willy
