I'm not keen on putting in SYN cookies and other DOS mitigations until the core TCP stack is really solid. TCP is a protocol that is a remarkable survivor in the face of small bugs that cause packet loss (fast retransmit kicks in, for example), but the manifestation of these bugs ends up being slow throughput.
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.
i wasn't familiar with syncookies, but the article you linked to says
> 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.
You probably only want to enable syn cookies when you are under heavy attack, but from the same article:
"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.
