Visual walkthrough — Network security — DDoS, man-in-the-middle, replay attacks, countermeasures

This is the visual companion to 4.3.31 Network security — DDoS, man-in-the-middle, replay attacks, countermeasures. It leans on the TCP three-way handshake and on Little's Law.

---

Step 1 — The honest handshake, so we know what "normal" looks like

WHAT. Two computers that want to talk over TCP do a little three-message greeting before any real data flows: SYN → SYN-ACK → ACK.

WHY. We must draw the normal case first, because the attack is nothing but this greeting left unfinished on purpose. You cannot see the trap until you have seen the door working.

PICTURE. Below, time runs downward. The client (left) says "I want to talk" (SYN). The server (right) answers "OK, and I want to talk too" (SYN-ACK) — and at that instant it must write down who this half-finished connection belongs to, so later it knows what the final message refers to. The client finishes with ACK. Only after the ACK is the connection real.

---

Step 2 — The notebook is finite: meet the backlog queue $B$

WHAT. The "notebook" where the server stores every half-finished handshake has a fixed number of lines. We name that number $B$ (the backlog).

WHY. Every real resource is finite. If the notebook were infinite there would be no attack. Naming the limit $B$ is what turns a vague worry into a number we can push against.

PICTURE. The backlog is drawn as a rack of $B$ slots. A half-open connection occupies one slot from the moment the server sends SYN-ACK until the connection either completes (ACK arrives) or is given up on.

---

Step 3 — A slot is not freed instantly: meet the timeout $T$

WHAT. If the final ACK never comes, the server does not hold the slot forever. It waits a time $T$, then gives up and frees the slot.

WHY. We need to know how long a bad connection squats in a slot, because a slot held for a long time is far more damaging than one held briefly. $T$ is the length of the squat.

PICTURE. One slot's life: filled at SYN-ACK, then a countdown of length $T$. If ACK arrives, it empties early (green). If ACK never arrives — the attacker's whole plan — it stays full for the entire $T$ (amber) and only then empties.

---

Step 4 — The attack: spoof the source so the ACK can never arrive

WHAT. The attacker sends SYN packets that carry a fake (spoofed) return address. He sends them at a rate we call $\lambda$ — Greek letter "lambda," just a name for "how many SYNs per second."

WHY spoof? Two payoffs at once. (1) The server's SYN-ACK flies off to the fake address, which never sends the finishing ACK — so the slot is guaranteed to squat the full $T$. (2) The attacker can't be traced by his source IP. This is the whole engine of the attack.

PICTURE. Attacker fires a stream of SYNs, each stamped with a different innocent-looking fake source. Each one forces a SYN-ACK into the void and pins a slot.

---

Step 5 — Counting the squatters: Little's Law does the arithmetic

WHAT. We want the average number of slots that are occupied at any instant while the attack runs. Call it $L$. We will show $L=\lambda T$.

WHY this tool — why Little's Law and not just "guess"? We have a rate of things arriving ($\lambda$, slots created per second) and a time each thing stays ($T$, seconds per slot). "How many are inside on average?" is exactly the question Little's Law answers, for any system whatsoever, no assumptions about randomness needed. It is the right tool because it converts (rate × stay-time) into (population) — precisely our two known quantities into our one unknown.

$$L=\underset{\begin{array}{c}\text{slots created}\\ \text{per second}\end{array}}{\underbrace{\lambda }}\times \underset{\begin{array}{c}\text{seconds each}\\ \text{slot lingers}\end{array}}{\underbrace{T}}=\underset{\begin{array}{c}\text{slots occupied}\\ \text{on average}\end{array}}{\underbrace{L}}$$

PICTURE. Think of a bathtub. Water pours in at $\lambda$ litres/sec and each litre stays $T$ seconds before draining. The steady water level is $\lambda T$. Slots are litres; the tub level is $L$.

---

Step 6 — The collapse condition: when the tub overflows

WHAT. The server dies for real users the moment the demanded occupancy reaches the physical capacity: $L\ge B$. Substituting $L=\lambda T$ gives the headline result.

WHY. $L$ is how many slots the attack wants to occupy; $B$ is how many exist. Wanting more than exist means the rack is full — new genuine SYNs bounce. Setting $\lambda T\ge B$ and solving for $\lambda$ tells us the exact attack rate that flips the server from "fine" to "down."

$$\underset{L,\text{demanded slots}}{\underbrace{\lambda T}}\ge \underset{\text{available slots}}{\underbrace{B}}⟹\boxed{\lambda \ge \frac{B}{T}}$$

• $\frac{B}{T}$ — read it as "slots available, spread over the time each is held" = the SYN rate the server can just sustain.
• Any $\lambda$ at or above this line saturates the backlog.

PICTURE. A phase line in the $(\lambda )$ axis: below $B/T$ the server survives (cyan zone), at/above $B/T$ it is denied (amber zone). The boundary is the derived threshold.

---

Step 7 — Edge cases: does the formula still speak sensibly?

WHAT. A formula is only trustworthy if it behaves at its extremes. We check the three degenerate dials.

WHY. The contract: the reader must never meet a scenario we skipped. So we push $T\to 0$, $B\to \infty$, and $\lambda \to 0$ and read what $\lambda \ge B/T$ predicts.

Dial pushed	${\lambda }_{\text{crit}}=B/T$ becomes	Meaning
$T\to 0$ (free slot instantly)	$B/T\to \infty$	No finite attack rate can win — slots empty as fast as they fill. This is the SYN-cookie idea in disguise.
$B\to \infty$ (infinite notebook)	$B/T\to \infty$	Can't fill an endless rack — but real memory is finite, so this is a fantasy.
$\lambda \to 0$ (attacker idle)	$\lambda <B/T$ always	No attack, server safe. Sanity check passes.

PICTURE. Two survival curves of ${\lambda }_{\text{crit}}$ versus $T$: the ordinary case is a falling curve (small $T$ helps a little), but drive $T$ toward $0$ and the safe zone balloons to fill the whole chart.

---

Step 8 — The cure: SYN cookies delete the notebook ($T\to 0$ made real)

WHAT. Instead of writing the half-open connection into a slot, the server encodes the needed state into the initial sequence number it puts inside the SYN-ACK, then keeps no memory at all. When (and if) a real ACK comes back, that ACK echoes the number; the server decodes it and rebuilds the connection on the spot.

WHY it kills the attack. With no slot allocated, there is nothing to fill. In the formula, the server holds zero state, so effectively $B$ is unbounded and $T\to 0$ from the attacker's point of view — both edge cases from Step 7 that sent ${\lambda }_{\text{crit}}\to \infty$. The asymmetry $A$ collapses: a spoofed SYN now costs the server essentially nothing.

PICTURE. Left: old server with a filling rack (dies). Right: cookie server with an empty rack — the state rides inside the packet, not in the server's memory; only a genuine returning ACK reconstructs it.

---

The one-picture summary

The whole story on one frame: SYNs pour in at rate $\lambda$, each pinning a slot for time $T$ (Little's Law → occupancy $\lambda T$), the rack of $B$ slots overflows at exactly $\lambda \ge B/T$ (amber cliff), and the SYN-cookie branch reroutes the state into the packet so the rack stays empty and the cliff vanishes.

Recall Feynman retelling — say it like you're explaining to a friend

A polite computer starts a chat with three quick nods: "hi" (SYN), "hi back" (SYN-ACK), "great" (ACK). The trouble is the server keeps a little sticky note for every chat it's waiting to finish, and it only has room for so many sticky notes — that's $B$. A note gets thrown away after $T$ seconds if the "great" never comes. An attacker sends tons of "hi"s with fake return addresses, so the "great" never comes — every note squats the full $T$ seconds. He sends "hi"s at rate $\lambda$. Little's Law (fill-rate times stay-time equals how many are sitting around) says $\lambda T$ notes are always in use, and once that reaches $B$ the pad is full and honest users get "sorry, no room." Solve it and the magic line is $\lambda \ge B/T$ — and since $B/T$ can be laughably small (like 32 a second), buying a bigger pad doesn't save you; the attacker just writes faster. The real trick is to stop keeping sticky notes at all: the server bakes the note into the reply number itself (a SYN cookie) and remembers nothing. Now there's no pad to fill, the cliff moves to infinity, and the flood pushes against empty air.

Recall Quick self-test

What quantity does Little's Law give us here, and from which two inputs? ::: The average number of occupied slots $L=\lambda T$, from the arrival rate $\lambda$ and the hold-time $T$. Write the exact collapse condition and say what each symbol is. ::: $\lambda \ge B/T$; $\lambda$ = attacker SYN rate, $B$ = backlog size, $T$ = slot timeout. Why doesn't a bigger backlog $B$ fix the SYN flood? ::: The threshold $B/T$ only grows linearly; the attacker simply raises $\lambda$ to keep $\lambda T\ge B$. In the edge-case table, which limit sends ${\lambda }_{\text{crit}}$ to infinity and is achievable in practice? ::: $T\to 0$ (free the slot instantly) — realised by SYN cookies, which keep no state. Why must the cookie use a keyed hash (a MAC-like function)? ::: So an attacker can't forge a valid returning ACK; only the server can produce/verify the encoded sequence number.