SYN Floods and the TCP Retransmission Caps That Blunt Them

A SYN flood is one of the oldest denial-of-service techniques on the internet, and it still works because it abuses something TCP has to do: hold state for a half-open connection. When a client sends a SYN, the server replies with a SYN-ACK and parks an entry in its connection table while it waits for the final ACK. An attacker who sprays spoofed SYN packets from addresses that will never reply forces the server to keep those half-open entries alive — retransmitting each SYN-ACK several times, on a timer, before finally giving up. Multiply that by thousands of spoofed sources and the connection table (and the memory behind it) fills with connections that were never real.

On Windows, how long the stack clings to each half-open connection is governed by two registry values under HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters. They are dull, they are decades old, and they are on the CIS Windows Benchmark for a reason.

The two retransmission caps

TcpMaxConnectResponseRetransmissions controls the half-open case: how many times TCP retransmits an unacknowledged SYN-ACK before it abandons the pending connection. This is the knob that matters most during a SYN flood, because every retransmission extends the time a spoofed SYN occupies a slot. It also gates when Windows' built-in SYN-attack protection engages — a lower cap means the stack decides it is under attack sooner and switches to a leaner, stateless response. CIS Windows L1 recommends a value of 2.

TcpMaxDataRetransmissions controls the established case: how many times TCP retransmits an unacknowledged data segment before tearing the connection down. This one shortens how long a stalled, already-established connection lingers — useful against slow-drip resource-exhaustion patterns as well as ordinary flaky links. Windows defaults to 5; CIS recommends 3.

The mental model: one cap shortens the window for connections that were never completed, the other for connections that completed and then went quiet. A hardened host wants both windows short.

Why "absent" is not "safe"

Here is the trap that catches a lot of hardening checklists. On many Windows builds these values are not present in the registry at all — the stack falls back to a built-in default. It is tempting to treat "the key isn't there" as a non-finding, but the default behaviour is exactly the longer retransmission window you are trying to avoid, and the CIS benchmark requires the value to be explicitly set. So the correct posture logic is:

• Hardened — the value is present and at or below the recommended cap.
• Exposed — the value is present but above the cap, or absent entirely (the default window applies).
• Unknown — the value could not be read. Treat this as exposed, not as a pass: a blocked read should surface the risk, never hide it.

WinSentinel's Network Posture module grades exactly this way. It reads both values, classifies each into hardened / exposed / unknown, and fails safe on anything it cannot confirm — so a missing key or a permissions error shows up as a warning rather than a silent green tick.

Checking and fixing it

You can read the current state directly:

Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters' `
  -Name TcpMaxConnectResponseRetransmissions, TcpMaxDataRetransmissions -ErrorAction SilentlyContinue

If the values are missing or too high, the remediation is a pair of single-statement writes (each safe to run on its own, no chaining):

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters' -Name TcpMaxConnectResponseRetransmissions -Value 2

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters' -Name TcpMaxDataRetransmissions -Value 3

Both settings are read by the TCP/IP stack at start-up, so a reboot is required for them to take effect. Neither is a substitute for a network-edge DDoS mitigation — a determined volumetric flood will saturate a link long before these caps matter — but they meaningfully reduce the resources a single host commits to connections that will never complete, and they close a concrete CIS Windows L1 line item.

Where this fits

These two caps sit alongside the other network-layer hardening WinSentinel audits on a single machine — ICMP redirect acceptance, IPv4 and IPv6 source routing, ICMP router discovery, dead-gateway detection, and the NetBIOS / LLMNR / mDNS / WPAD name-resolution poisoning vectors. Individually each is a small registry value; together they are the difference between a workstation that quietly does whatever the local network tells it and one that has been deliberately locked down. WinSentinel checks all of them, explains why each matters, and hands you a copy-pasteable fix — for free, on every machine.