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

• (a) Replay. Broken assumption: ek valid message sirf ek baar valid hota hai. Note karo ki attacker ne kuch bhi decrypt nahi kiya — genuine bytes, faked freshness.
• (b) DDoS (distributed). Broken assumption: server ke paas sabke liye enough resources hain. "Many machines" = distributed.
• (c) MITM (ARP spoofing ke zariye). Broken assumption: main seedha real party se baat kar raha hoon.

• SYN cookies → DDoS (specifically SYN floods: jab tak client prove nahi karta ki woh real hai, state allocate mat karo).
• CA-signed certificate → MITM (authentication: public key ko domain name se bind karo).
• Nonce → Replay (freshness: ek repeated nonce reject kar diya jaata hai).

KYA: hum chahte hain sabse chhota $\lambda$ jo occupied slots ko ceiling $B$ tak pahuncha de. Little's Law kyun: Little's Law kehta hai kisi system ke andar items ki average number $L=\lambda W$ hai, jahan $\lambda$ arrival rate hai aur $W$ har item ka time-inside hai (dono symbol list mein defined hain). Yahan ek "item" ek half-open connection hai, uski arrival rate SYN rate $\lambda$ hai, aur uska time-inside exactly hold time hai, isliye $W=T$. Substitute karne par milta hai $L=\lambda T$. Yeh rate × time-inside se "system mein average kitni cheezein hain" answer karta hai — koi simulation nahi chahiye. ${\lambda }_{\min }=\frac{B}{T}=\frac{512}{30}\approx 17.07\text{SYN/s}.$ Toh ~18 spoofed SYNs per second ki ek trickle already ek naive server ko jam kar deti hai. Woh tiny number exactly isliye hai kyun SYN floods dangerous hain — attacker ko barely paseena aata hai.

(a) $A=\frac{c_s}{c_a}=\frac{3000\text{bytes}}{60\text{bytes}}=50$ (ek pure bandwidth ratio — upar aur neeche same unit). (b) Reflected bandwidth $=A\times (\text{attacker bandwidth})=50\times 2\text{Mbit/s}=100\text{Mbit/s}$. Kyun matter karta hai: victim attacker ke output ka $50\times$ dekhta hai, aur source IPs innocent resolvers ke hain — tum sirf attacker ko blocklist nahi kar sakte.

• $104.2$ par: $|104.2-100.0|=4.2\le 5$ → accept.
• $106.2$ par: $|106.2-100.0|=6.2>5$ → reject (message "bahut purana" hai, capture expire ho gaya hai). $\Delta$ kyun exist karta hai: yeh ek trade-off dial hai — chhota $\Delta$ replays faster block karta hai lekin clock skew/network delay mein toot jaata hai; bada $\Delta$ lag tolerate karta hai lekin longer replay window chodta hai.

• SYN cookies: server koi state hold nahi karta, isliye effectively $B\to \infty$ (fill karne ke liye koi queue nahi) → ${\lambda }_{\min }=B/T\to \infty$. Direction: ${\lambda }_{\min }$ bina bound ke rise karta hai. Formula ab apply nahi hota; flood woh memory exhaust nahi kar sakta jo kabhi use hi nahi hui.
• Adaptive/short timeout (SYN-RECV recycling): server purani half-open entries early drop kar deta hai, isliye effective $T$ shrink hota hai. Kyunki ${\lambda }_{\min }=B/T$ hai, chhota $T$ ${\lambda }_{\min }$ raise karta hai — attacker ko queue full rakhne ke liye faster bhejna padega, kyunki har slot jaldi free ho jaata hai.
• Rate limiting (per source): treat it as an effective ceiling. Agar limiter sirf ${\lambda }_{\text{cap}}$ SYNs per source admit karta hai, toh ek single source ko queue collapse karne ke liye ${\lambda }_{\text{cap}}\ge B/T$ satisfy karna hoga — jo woh usually nahi kar sakta. Direction: per-source ${\lambda }_{\min }=B/T$ unchanged rehta hai, lekin koi ek source actually deliver kar sakta $\lambda$ us se neeche cap hai, isliye akela attacker ${\lambda }_{\min }$ tak nahi pahunch sakta. Aggregate mein ab bhi $B/T$ hit karne ke liye attacker ko kam se kam $\lceil (B/T)/{\lambda }_{\text{cap}}\rceil$ distinct sources chahiye — aur spoofing/botnets exactly itne saare IPs supply karte hain, naive per-IP limits ko defeat karte hue. Yahi loophole figure s01 highlight karta hai (green floor = SYN-cookie fix jo $B$ entirely remove kar deta hai).

Neeche use ki gayi notation (use se pehle defined):

• Ek shared secret $K$ woh single number hai jise do parties DH run ke baad dono jaanti hain; koi bhi jo sirf wire read kare us compute nahi kar sakta.
• Double-arrow $X\stackrel{\text{shared secret }K}{\leftrightarrow }Y$ padhte hain: "$X$ aur $Y$ ne ek DH exchange complete kiya hai aur ab jointly secret $K$ hold karte hain." Yeh ek relationship label hai, equation nahi — arrow dono taraf point karta hai kyunki shared secret symmetric hai (dono sides same $K$ hold karti hain).

DH kya deta hai: har side wire par ek public value bhejti hai (Alice aur Bob ki DH public values), aur doosri side ki public value plus apna private number se woh shared secret compute karti hai. Ek eavesdropper jo sirf public values read kare woh secret derive nahi kar sakta. Toh passive listener ke against secrecy real hai. Phir bhi kyun fail hota hai: Eve active hai, passive nahi. Woh har public value intercept karti hai aur apni substitute kar deti hai, do alag DH exchanges run karti hai. Neeche, $K_1$ aur $K_2$ do resulting shared secrets hain (public values nahi): $K_1$ woh secret hai jo Alice aur Eve milkar compute karte hain, aur $K_2$ woh secret hai jo Bob aur Eve compute karte hain. $\text{Alice}\stackrel{\text{shared secret }{K}_1}{\leftrightarrow }\text{Eve}\stackrel{\text{shared secret }{K}_2}{\leftrightarrow }\text{Bob}.$ Alice sochti hai $K_1$ Bob ke saath shared hai; Bob sochta hai $K_2$ Alice ke saath shared hai — lekin dono secrets actually Eve ke paas hain. Eve har message ko us side ki key se decrypt karti hai aur doosri se re-encrypt karti hai, invisibly relay karti hai. Missing property: authentication. DH kabhi nahi poochta "kya yeh public value really Bob ki hai?" Cure yeh hai ki DH public values ko sign karo (certificate key ko identity se bind karta hai) — exactly wahi jo TLS handshake Public Key Infrastructure & Certificates use karke karta hai.

(a) Used nonces ka "seen" set hamesha ke liye grow karta hai (memory). Agar tum use memory save karne ke liye clear karo, toh ek previously-used nonce phir se acceptable ho jaata hai → purana replay kaam karta hai. Pure nonce = ek session ke andar perfect lekin unbounded state. (b) Timestamps assume karte hain ki client aur server ke clocks agree karte hain ($\Delta$ ke andar). Agar attacker server ka clock push kar sakta hai (e.g. NTP spoof karna) ya agar $\Delta$ generous hai, toh ek captured message itna "fresh" rehta hai ki replay kiya ja sake. Timestamps memory bound karte hain (koi set nahi) lekin use clock-trust assumption ke liye trade karte hain. Best practice: dono combine karo — ek short timestamp window plus ek nonce set jise sirf current $\Delta$ ke andar dekhe gaye nonces yaad rakhne chahiye, memory bounded rakhte hue.

Message: $m\Vert n\Vert t$ jahan

• $m$ = actual request ("transfer ₹1000 to Bob"),
• $n$ = ek fresh nonce (kabhi reuse nahi hota),
• $t={\text{MAC}}_K(m\Vert n)$ = dono request aur nonce par ek tag.

Server accept rule — teeno hold hone chahiye:

1. $t\stackrel{?}{=}{\text{MAC}}_K(m\Vert n)$ recomputed → proves integrity + authenticity (sirf $K$ ka holder ise bana sakta tha; $m$ untampered).
2. $n\notin \text{SeenSet}$ → proves freshness (replay nahi).
3. Accept par, $n$ ko SeenSet mein insert karo.

MAC $n$ bhi kyun cover karta hai: agar tag sirf $m$ par hota, toh Eve ek new $n$ swap kar sakti, $m$ par purana valid tag rakh sakti... lekin tag ab $m\Vert n$ se match nahi karega — good. Iske ulta agar hum sirf $n$ MAC karte, woh $n$ rakh ke $m$ change kar sakti. Dono ko ek tag ke neeche bind karna freshness ko integrity se tie karta hai. Yeh Message Authentication Codes (MAC) & HMAC use karta hai.

Challenge–response (request $m$ bound in, mandatory):

1. Server → Client: ek fresh random challenge $r$. Kyun: $r$ unpredictable hai, isliye ek stored purana response useless hai; aur server freshness own karta hai, isliye koi unbounded client set nahi chahiye — $r$ naturally per session single-use hai.
2. Client → Server: pair $m\Vert {\text{MAC}}_K(r\Vert m)$. Kyun: tag dono fresh challenge $r$ aur request $m$ cover karta hai, isliye client prove karta hai ki woh $K$ jaanta hai abhi, is $r$ ke liye, aur $m$ tag tod ke tamper nahi kiya ja sakta. ($m$ bind karna required hai, optional nahi — warna ek attacker jo valid ${\text{MAC}}_K(r\Vert m)$ dekh chuka hai koi bhi request usse attach kar sakta.)
3. Server: ${\text{MAC}}_K(r\Vert m)$ recompute karo us $r$ se jo usne abhi issue kiya tha; accept karo iff yeh match karta hai aur $r$ still outstanding hai, phir $r$ discard karo. Agla session ek naya $r$ issue karta hai → kal ki reply verify nahi kar sakti.

L4.1 se trade-off: ek extra round-trip lagta hai, lekin server ko sirf currently outstanding challenges yaad rakhne hain, na ki har nonce jo kabhi dekha gaya ho.

Ek metric dhyan mein rakho: effort per request. $A=c_s/c_a$ ek request ke liye server ki effort ka attacker ki effort se ratio hai; attacker sirf tab jeetta hai jab $A\gg 1$. SYN cookies $c_s$ lower karke $c_s\to$ ≈ $c_a$ drive karte hain: server connection state initial sequence number ke andar encode karta hai jo woh wapas bhejta hai, kuch bhi store nahi karta. Toh ek spoofed SYN ab server ko ek cheap SYN-ACK computation aur koi held memory nahi — $c_s$ "30 s of RAM" se collapse hokar "ek hash" ho jaati hai. $c_s$ ab $c_a$ jitni chhoti hone par, $A=c_s/c_a\approx 1$ milta hai: attacker ko ab leverage nahi milta; server ko hurt karne ke liye use utna spend karna padega jitna server karta hai, jo ek botnet ke liye ab profitable nahi raha. Proof-of-work / CAPTCHA $c_a$ raise karke $A\to 1$ drive karte hain: woh client ko CPU burn karne (hash puzzle solve karo, PoW) ya human time (CAPTCHA padho) force karte hain server ka expensive kaam karne se pehle. Ab $c_a$ balloon hoti hai — maano puzzle attacker ko utna cost karta hai jitna request serve karna server ko — isliye $A=c_s/c_a\approx 1$. Ek akela attacker lazily millions of costly requests generate nahi kar sakta, kyunki ab har ek unhe real CPU ya ek human cost karta hai. Unifying idea: attack poora $A\gg 1$ par jeeta hai. $A\to 1$ force karne ke exactly do levers hain — $c_s$ shrink karo (cookies: unverified clients ke liye expensive kaam mat karo) ya $c_a$ grow karo (PoW/CAPTCHA: client ko pehle pay up front karwao). Dono woh asymmetry destroy karte hain jisne flood profitable tha.

(a) Over-limit factor $=\frac{\lambda }{{\lambda }_{\min }}=\frac{200}{17.07}\approx 11.7\times$. Pre-fix queue almost barah-guna swamped hai — real users ke liye total collapse. (b) Cookies ke saath koi backlog queue fill karne ke liye nahi hai: state sequence number ke andar rehti hai, automatically free hoti hai kyunki kabhi store hi nahi hui. $200$ SYN-ACK computations/sec trivial CPU hai; koi resource exhaust nahi ho raha, isliye collapse condition $\lambda \ge B/T$ ka reference karne ke liye koi $B$ nahi hai. Attack ka leverage ($A$) gone hai.

DDoS ki broken assumption ::: server ke paas sabke liye enough resources hain. MITM ki broken assumption ::: main real party se baat kar raha hoon (authentication missing). Replay ki broken assumption ::: ek valid message sirf ek baar valid hota hai (freshness missing). SYN-flood collapse condition ::: $\lambda \ge B/T$. SYN cookies $A=c_s/c_a$ mein kya change karte hain ::: woh $c_s$ slash karte hain (koi held state nahi) isliye $A\to 1$. Proof-of-work $A=c_s/c_a$ mein kya change karta hai ::: woh $c_a$ grow karta hai isliye $A\to 1$. Plain DH MITM-vulnerable kyun hai ::: yeh secrecy deta hai lekin public values ka authentication nahi. Do fields jo ek MAC ko replay rokne ke liye cover karne chahiye ::: message $m$ aur nonce $n$, ek saath.