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

False. A replayed ciphertext is a genuine message, so it decrypts and verifies perfectly; you need freshness (nonce/timestamp/sequence number), which secrecy does not provide. See Message Authentication Codes (MAC) & HMAC.

False. It gives a shared secret no eavesdropper can read (secrecy) but proves nobody's identity (no authentication), so an active attacker runs two exchanges and sits in the middle.

False. Amplification/reflection attacks make the server or reflector spend far more than the attacker ($A=c_s/c_a\gg 1$), so a small attacker can flood a large victim.

False. The collapse condition is $\lambda \ge B/T$; the attacker simply doubles the SYN rate $\lambda$ and the queue fills again. The real fix is allocating no state (SYN cookies).

False. A MAC proves integrity and authenticity, but a captured message's MAC is still valid on resend — you must also bind a nonce or timestamp into the MACed data.

True. The server encodes connection state inside the sequence number instead of reserving memory, so no state is held until the client's ACK proves it is real, killing the cheap-attack/expensive-defense gap.

True. TLS adds internal sequence numbers to every record, so a replayed record is out of order and rejected — freshness is built in, unlike bare encryption.

False. BCP 38 blocks spoofed source IPs at the network edge, which cripples reflection attacks, but a botnet using real IPs still floods you legitimately-looking.

True. Replay never touches the plaintext; the attacker copies the valid ciphertext and re-sends it, letting the receiver do the same action twice.

A DDoS uses thousands of botnet/spoofed IPs and reflectors; per-IP blocking cannot scale, and blocking reflectors punishes innocent servers.

The error: it works because hosts cache ARP replies without verification (IP→MAC), so a forged reply redirects traffic at the host, not because the switch misroutes.

Encryption isn't the point — safety comes from the fresh random challenge $r$: an old captured response won't verify against a new $r$, so replay fails even without encryption.

HSTS does not encrypt anything; it forces the browser to use HTTPS, preventing an attacker from stripping the connection down to plain HTTP.

The 60-byte query is the attacker's cost; the ~3000-byte reply hits the victim, so amplification $A\approx 50$ makes it strong precisely because the sent packet is tiny.

Encryption without identity verification still lets an attacker run two encrypted channels (one with each party); you must authenticate the keys via certificates or signatures.

Little's Law holds for the long-run average regardless of the arrival pattern; you only need average rate $\lambda$ and average hold time $T$.

The spoofed owner never sends the final ACK, so the connection stays half-open and the server holds the slot until timeout $T$ — that held state is the exhausted resource.

So the resolver's large reply is sent to the victim (reflection), hiding the attacker and pointing amplified traffic at the target.

A signed public value proves it came from the real party; the attacker cannot forge that signature, so they can't substitute their own key into the middle.

If the nonce were outside the MAC, the attacker could change it freely; MACing $m\Vert n$ ties freshness to integrity so a tampered nonce fails verification. See Transport Layer — TCP three-way handshake for where sequence numbers play this role.

The amplification factor is $A=c_s/c_a$; making each attack request expensive drives $A$ down so one attacker can no longer overwhelm the server.

Encryption alone hides content but not identity; only authentication guarantees the other end is who they claim, closing the relay attack.

No — a message captured and replayed within the same window before clearing still has an unseen nonce; you need either a persistent set or a timestamp window $\Delta$ tighter than reuse.

Legitimate messages may fall outside $|T_{\text{now}}-T_s|\le \Delta$ and be wrongly rejected, or $\Delta$ must be widened, which enlarges the replay window — clock sync is a real dependency.

The queue is exactly full on average; any additional legitimate SYN finds no slot, so service degradation begins precisely at this boundary, not strictly above it.

No — from $\lambda \ge B/T$, as $T\to 0$ the required attack rate $\to \infty$, so the attacker cannot fill the queue; fast timeouts are a genuine mitigation.

Yes, easily — with no memory of past nonces, every replayed message looks new; statelessness must be paired with timestamps or signed sequence numbers to stay safe.

SYN cookies stop the state-exhaustion half-open trick, but a large enough botnet completing real handshakes can still exhaust bandwidth or CPU — cookies are not a cure for volumetric DDoS.