Syn flood...
The current thrust of the effort in the TCP stack is to make sure that we cover all the corner cases, and build a functional testing framework to check regressions and protocol traces versus other implementations. It's also quite remarkable how thin on the ground test suites are for TCP...
Once all this is done, then I have an alpha-grade multipath TCP implementation to merge in, and defences like SYN cookies will be parameterised options that can be activated in a unikernel in response to traffic surges.
> Syncookies are discouraged these days. They disable too many valuable TCP features (window scaling, SACK) and even without them the kernel is usually strong enough to defend against syn floods and systems have much more memory than they used to be. So I don't think it makes much sense to add more code to it, sorry.
"I can trivially prevent any inbound client connections with 2 threads of syn flood. Enabling tcp_syncookies brings the connection handling back up to 725 fetches per second."
"This data compellingly supports the continued value of the syncookie and that position seems to have won the day."
Of course this refers to the Linux TCP/IP stack, the Mirage stack is completely different so it remains to be seen what measures will be effective against syn floods.
;_;