Worked examples — Network security — DDoS, man-in-the-middle, replay attacks, countermeasures

See the parent: (Hinglish version).

---

The scenario matrix

Each row is a case class — a distinct kind of situation the maths of this topic can hand you. Every example below is tagged with the cell(s) it covers.

#	Case class	What makes it distinct	Worked in
C1	DDoS below threshold	$\lambda <B/T$ — server survives	Ex 1
C2	DDoS at/above threshold	$\lambda \ge B/T$ — service collapses	Ex 2
C3	Amplification factor	ratio $A=c_s/c_a$, reflection maths	Ex 3
C4	Degenerate input	$T=0$ (instant timeout) or $B=\infty$	Ex 4
C5	Limiting behaviour	what happens as $\lambda \to \infty$ or $T\to \infty$	Ex 4
C6	Replay caught	nonce already in "seen" set	Ex 5
C7	Replay slips through	timestamp window $\Delta$ too wide	Ex 6
C8	MITM key mix-up	two DH keys $K_1\ne K_2$, detect via auth	Ex 7
C9	Real-world word problem	CDN sizing / cost of proof-of-work	Ex 8
C10	Exam-style twist	combined defence, "which fix and why"	Ex 9

Before we start, one symbol we reuse everywhere:

---

Ex 1 — DDoS below threshold (Cell C1)

1. Compute steady-state occupancy using Little's Law $L=\lambda T$. $L=20\times 30=600\text{ slots}.$ Why this step? Little's Law (Little's Law) says the average number of items sitting in a system equals arrival-rate $\times$ time-in-system. Here items = half-open connections. We use it because we care about how many slots are occupied on average, not about any one connection.

2. Compare to capacity $B=1024$. $L=600<1024=B.$ Why this step? The collapse condition from the parent is $\lambda \ge B/T$. Equivalently $\lambda T\ge B$. Since $600<1024$, the queue never fills — there is always a free slot for a real user.

---

Ex 2 — DDoS at/above threshold (Cell C2)

1. Find would-be occupancy $L=\lambda T=50\times 30=1500$ slots. Why this step? This is how many slots the flood wants to hold — it can exceed $B$.

2. Cap it at $B$. Real occupancy $=\min (B,\lambda T)=\min (1024,1500)=1024$. Why this step? You physically cannot hold more than $B$ slots. Look at the red line in the figure hitting the ceiling.

3. Rejection fraction. Once full, a slot only frees at rate $B/T=34.13$/s, but demand (attacker + legit) arrives far faster. Fraction of attacker SYNs that find room $=(B/T)/\lambda =34.13/50=0.683$; the rest, and virtually all legit users arriving to a full queue, are dropped. Legit rejection $\approx 1-(B/T)/\lambda$. $\text{reject frac}\approx 1-\frac{34.13}{50}=0.317\to \text{about }32\%\text{of the queue churn is real users being pushed out.}$ Why this step? We turn "queue full" into a number: the server can only admit $B/T$ new connections per second, so any excess arrival rate is lost.

---

Ex 3 — Amplification factor (Cell C3)

1. Amplification factor $A=c_s/c_a$ where $c_s$ = bytes the victim receives, $c_a$ = bytes the attacker sends. $A=\frac{3072}{64}=48.$ Why this step? Reflection attacks make the resolver pay the outbound cost. $A$ measures how much bigger the reflected reply is than the trigger — this is the whole point of picking ANY.

2. Attacker's own outbound rate. $2000\times 10=20000$ queries/s $\times 64$ bytes $=1,280,000$ bytes/s $=1.28$ MB/s. Why this step? We need the attacker's cost to then multiply by $A$.

3. Victim-bound flood. $1.28\text{ MB/s}\times 48=61.44$ MB/s $=61.44\times 8=491.52$ Mbps. Why this step? Every attacker byte becomes $A$ victim bytes. Multiply by $8$ to convert MB/s to Mbps (bandwidth is quoted in bits).

---

Ex 4 — Degenerate & limiting inputs (Cells C4, C5)

1. (a) $T=0$ — instant timeout (this is essentially SYN cookies). $L=\min (B,\lambda \cdot 0)=\min (B,0)=0$. Why this step? If no state is ever held (freed instantly / never allocated), no flood can accumulate. Occupancy is $0$ regardless of $\lambda$. Immune. This is exactly why SYN cookies work — they push $T$ effectively to $0$.

2. (b) $B\to \infty$ — infinite queue. $L=\min (\infty ,\lambda T)=\lambda T$, finite for finite $\lambda$. Why this step? You "never reject" — but memory is a resource too, so $\lambda T$ slots of RAM still get consumed. The parent's "bigger $B$" mistake lives here: you traded a full-queue failure for an out-of-memory failure.

3. (c) $\lambda \to \infty$. $L=\min (B,\infty )=B$; the queue saturates instantly and stays pinned. Why this step? The limit shows the worst case is bounded by $B$ — occupancy can't exceed the ceiling — but every legit user is rejected. Doomed unless $T$ is small.

4. (d) $T\to \infty$. $\lambda T\to \infty$ for any $\lambda >0$, so $L=\min (B,\infty )=B$; the queue fills at any attack rate given enough time. Why this step? A server that never times out half-open connections is defeated by even a trickle. This is why timeout $T$ exists at all.

---

Ex 5 — Replay caught by a nonce (Cell C6)

1. Server checks the seen-set. $n=17\in \text{seen}$ → reject, before even recomputing the MAC. Why this step? Freshness is the first gate. A replayed nonce is definitionally not fresh; see Message Authentication Codes (MAC) & HMAC for how the tag is formed.

2. Eve tries $n=18$ (a value not yet seen), keeping the old $t$. Why this step? She's attacking the freshness check by supplying a "new" nonce.

3. MAC verification fails. The server recomputes ${\text{MAC}}_K(m\Vert 18)$ and compares to Eve's $t$, which was ${\text{MAC}}_K(m\Vert 17)$. Since $18\ne 17$ the inputs differ, so the tags differ (except with negligible probability $2^{-\ell }$ for an $\ell$-bit MAC). Reject. Why this step? The MAC binds $n$ to $m$ under secret key $K$. Eve can't forge a tag for $n=18$ without $K$. This is why the nonce lives inside the MAC, not beside it.

---

Ex 6 — Replay slips through a loose window (Cell C7)

1. First replay at $103.0$ s. $|103.0-100.0|=3.0\le 5=\Delta$ → accepted (replay succeeds!). Why this step? Within the window, a timestamp alone cannot distinguish a fresh message from a replay — it only checks age, not uniqueness.

2. Second replay at $108.5$ s. $|108.5-100.0|=8.5>5$ → rejected (too old). Why this step? The window is the only defence; once the message ages past $\Delta$ it expires.

3. The fix. Add a seen-set (nonce) inside the window, or shrink $\Delta$. With a nonce, even the $103.0$ s replay is caught, as in Ex 5. Why this step? This is the parent's core lesson: a timestamp bounds the attack window but a nonce closes it. Wide $\Delta$ = wide replay window.

---

Ex 7 — MITM key mix-up in Diffie–Hellman (Cell C8)

1. Public values. $A=g^a\mathrm{mod}p=5^6\mathrm{mod}23$, $B=g^b\mathrm{mod}p=5^{15}\mathrm{mod}23$, Eve's $E=g^e\mathrm{mod}p=5^3\mathrm{mod}23=125\mathrm{mod}23=10$. Why this step? DH exchanges $g^{\text{secret}}\mathrm{mod}p$ in the open; the secret exponent stays private. Eve substitutes her $E$ for both sides — that's the man-in-the-middle.

2. Alice's key (she thinks she shares with Bob, actually with Eve): $K_1=E^a\mathrm{mod}p=10^6\mathrm{mod}23$. Compute: $10^2=100\equiv 8$, $10^3\equiv 80\equiv 11$, $10^6=(10^3{)}^2\equiv 11^2=121\equiv 6$. So $K_1=6$. Why this step? Alice raises the value she received (Eve's $E$) to her own secret — the standard DH combine.

3. Bob's key (with Eve): $K_2=E^b\mathrm{mod}p=10^{15}\mathrm{mod}23$. $10^6\equiv 6$, $10^{12}\equiv 6^2=36\equiv 13$, $10^{15}=10^{12}\cdot 10^3\equiv 13\cdot 11=143\equiv 143-138=5$. So $K_2=5$. Why this step? Same combine, Bob's secret. Note $K_1=6\ne 5=K_2$: Eve holds one key with each side, exactly the parent's picture.

4. The fix — authentication. If Alice signed her $A$ (via Public Key Infrastructure & Certificates / TLS handshake), Eve could not replace $A$ with $E$ without breaking the signature. The mismatch is invisible to secrecy but fatal to authenticity. Why this step? DH gives a shared secret but never proves whose secret. Signing the public value binds identity to key.

---

Ex 8 — Real-world word problem: proof-of-work as a defence (Cell C9)

1. Work per token. Finding $d$ leading zero bits needs on average $2^d=2^{20}=1,048,576$ hashes. Why this step? Each hash output is uniform, so the chance of $d$ leading zeros is $2^{-d}$; expected trials to succeed is $1/2^{-d}=2^d$. This is the attacker's new $c_a$ — we deliberately raised it.

2. Hashes needed per second. $R\times 2^d=1000\times 1,048,576=1.049\times 10^9$ hashes/s. Why this step? $R$ tokens/s each costing $2^d$ hashes.

3. Cores required. $\frac{1.049\times 10^9}{10^7}=104.9\to 105$ cores. Why this step? Divide total hash demand by one core's throughput; round up (you can't rent a fraction of a core).

4. Effect on $A$. Before PoW the attacker paid one cheap packet ($c_a$ small, $A$ huge). Now $c_a$ jumped by $2^{20}$, so $A=c_s/c_a$ collapses toward $1$ or below — the asymmetry that made DDoS worthwhile is gone. Why this step? Recall $A=c_s/c_a$: raising $c_a$ is a direct lever on $A$, exactly the parent's "CAPTCHA / proof-of-work" countermeasure.

---

Ex 9 — Exam-style twist: which single fix, and why? (Cell C10)

1. Screen the DDoS. $\lambda T=20\times 60=1200>B=512$? Yes — $1200\ge 512$, so this would collapse. Why this step? Apply the threshold test $\lambda T\ge B$ first, because if the server is already down, nothing else matters.

2. But re-read: the flood is hypothetical spoofed SYNs — the immediate, guaranteed exploits are the constant MAC (trivially replayable, Cell C6/C7) and plain HTTP (MITM + credential theft, Cell C8). SYN cookies fix only (iii). Why this step? Ranking by exploitability: a constant auth tag is a guaranteed replay any attacker can perform today; DDoS needs a botnet.

3. Pick [B] TLS with certificates — it authenticates the server (kills MITM on HTTP) and wraps traffic so the credential can't be sniffed. But TLS alone does not fix the constant MAC at the application layer. Why this step? TLS closes the widest hole (eavesdrop + MITM + downgrade via HSTS). It's the highest-value single control here.

4. What remains exposed: the constant MAC (needs a nonce — [C]) and the SYN flood (needs [A]). One control can't cover three independent broken assumptions — that is the whole point of the parent's comparison table. Why this step? Each attack breaks a different assumption (freshness / identity / resources), so no single fix is complete.

---

Recall Self-test

A server has $B=2048,T=40$s. Below what SYN rate is it safe? ::: $\lambda <B/T=2048/40=51.2$ SYN/s. A $50$-byte query yields a $2500$-byte reply. What is $A$? ::: $A=2500/50=50$. Timestamp window $\Delta =5$s, message stamped $t=100$, replayed at $t=104$. Accepted? ::: Yes — $|104-100|=4\le 5$ (that's the replay hole). Raising $B$ to defend a SYN flood — good idea? ::: No; attacker just raises $\lambda$ since $\lambda \ge B/T$ still holds. Use SYN cookies ($T\to 0$).