DDOS attacks and multi-threading

Question

Does a host create a separate thread for each TCP SYN request? Or it depends on the socket implementation for the host?

Answer 1

Except for user space network stacks the operating system fully handles the complete TCP handshake in the kernel and notifies the application only once the connection is fully established. The kernel part is handled in a lightweight way, i.e. usually there are no kernel threads involved. What's happening in user space after the connection is established depends on the application. Some applications create a new thread or a new process for each new connection while others handle it inside the same thread and process.

Answer 2

The way a network stack handles multiple connections is absolutely Operating System specific. In fact, it's even networking hardware-specific, in that most better network cards can do a lot of the TCP handling themselves.

You cannot, hence, generally assume that a network stack is inherently multithreaded or not – from a pure flow-logical point of view, a network card gets and processes one ethernet packet after the other, and thus, you can always process them sequentially in software.

However, there might be advantages (mainly: being able to split the workload across CPU cores) to making your operating system handle networking in a multi-threaded way. Note that this threading is likely to not have the shape of user-land threads like you probably know them, but of operating system tasks; but there's no guarantee that TCP handling for existing connections isn't done in user land within the context of the process that is using a socket. It's an OS design decision.

On the other hand, there's good reasons to not multithread networking, especially in low-load situations or when there's only one dominant receiver or sender of packets in your user space (mainly: synchronization is hard, and thus, often more expensive than just parsing a TCP header, and you'd actually lose more than you win when deciding which CPU core should handle a packet after one core has already touched it). This again, is often solved very adaptively by operating systems, or on high-end network cards, even in hardware that can be told to transfer packet contents to different memory regions and thus allow certain traffic to be "sticky" to one specific core.

Since this is the information security SE and you implied the topic of DDOS: everything is highly adaptive. But it's save to assume that the state-checking in modern operating systems can pretty much be done before the next network card interrupt comes in, and then, the handling/generation of SYN-ACK packets can done normally in e.g. a main event loop or in worker tasks.

SYN flooding used to be an effective method some 20 years ago. I just don't know whether that is still the case – modern machines just don't care when the table of connections they have to handle in a SYN-but-not-yet-ACK state hits several hundred kilobytes (gaaasp!). Sure, looking up the few SYN requests of legitimate clients might take hundreds of nanoseconds or even several microseconds longer in a halfway efficient data storage format for attack scenarios where the attacker has not gotten a 10Gbit/s lane to your server... My impression is that a mediocre laptop can these days do stateful firewalling (at least with Linux' default conntrack), NATing and TCP handling at full 1Gbit/s wire speed without breaking into too much of a sweat. Saturating these capabilities with entries to a boring table of half-open connections will be pretty hard.