Lecture 12: Network Security

What this lecture covers

This lecture asks why TCP/IP, the foundation of the internet, was never designed with security in mind, and what that means for attackers. Working from Steve Bellovin's paper on TCP/IP security, Professor Zeldovich walks through how an attacker who can intercept, modify, drop and inject packets can exploit weaknesses in TCP sequence numbers, DNS, and routing protocols.

The lecture sits at the start of a short block on network-level security, right after several weeks on implementation bugs such as buffer overflows and web vulnerabilities. It shifts the focus from buggy code to buggy protocol design, which is much harder to fix because it requires changing every machine that speaks the protocol. After watching, you should be able to explain why guessable TCP sequence numbers let attackers spoof connections, and why later protocol layers (Kerberos, SSL/TLS) had to add cryptography instead of relying on the network.

Key ideas

• Protocol bugs vs. implementation bugs: an implementation bug like a missing bounds check can be patched locally, but a protocol flaw requires every implementation of the protocol to change, which is far harder to coordinate.
• IP spoofing: any host can put an arbitrary source address in an IP packet, since nothing in the base protocol verifies it.
• TCP sequence number guessing: the original TCP spec incremented sequence numbers in a predictable way, so an attacker could guess the server's sequence number and complete a fake three-way handshake while impersonating another host's IP address.
• Off-path connection spoofing: an attacker who can predict SNS doesn't need to see the victim's traffic; it can inject a forged ACK to complete a handshake, as long as the real client doesn't send a reset first.
• Per-connection sequence number randomization: modern stacks derive the initial sequence number from a hash of source/destination IP, source/destination port, and a secret key, so guessing one connection's sequence number no longer reveals another's.
• SYN flooding and SYN cookies: servers that store per-connection state after a SYN packet can be exhausted by fake connection requests; SYN cookies avoid this by encoding the state (source/destination, port, a coarse timestamp, secret key) directly in SNS instead of storing it.
• DNS cache poisoning: because DNS runs over UDP with no handshake, an attacker who guesses the query ID and source port can inject a fake response before the real one arrives, redirecting a client to an attacker-controlled address.
• Amplification and reflection attacks: protocols like DNS, where responses are much larger than requests, let an attacker spoof a victim's address in the request and have the server flood the victim with a much larger response.

Walkthrough

Why TCP/IP was never designed to be secure (0:00)

The lecture opens by asking why a protocol suite as important as TCP/IP has so many known security problems. The answer is historical: TCP/IP was designed roughly 40 years ago for a small number of mutually trusting sites, not for an internet where you don't know most of the machines you're talking to. As the internet grew, its threat model changed faster than its protocols could, and many fixes had to be backwards-compatible patches rather than clean redesigns (the slow, incomplete migration to IPv6 is offered as an example of how hard protocol replacement is).

TCP sequence numbers and connection spoofing (10:00)

The lecture walks through the TCP three-way handshake and explains that the server implicitly trusts a connection because completing it requires acknowledging the server's sequence number SNS, which only the real client should have seen. Early TCP stacks incremented sequence numbers at a fixed, predictable rate (partly to avoid confusing packets across connections), which made SNS guessable. An attacker could send a SYN from a spoofed source address, predict the server's response, and forge the final ACK to complete the handshake as if it were the legitimate client, then inject data into that "connection."

Why this mattered: IP-based trust, RST attacks, and data injection (28:05)

This section covers what attackers could do with spoofable connections: protocols like rlogin that trusted the source IP address as authentication could be tricked into granting access; routers running BGP over TCP could have their sessions reset by guessed sequence numbers, forcing costly route recomputation; and an attacker who could guess a live connection's sequence number could inject commands into an already-authenticated session. The BGP fix described is a clever reuse of the IP TTL field: routers only accept BGP packets with TTL 255, since only an immediate neighbor could have sent one that hasn't been decremented.

Fixing sequence number guessing (39:18)

Modern operating systems compute the initial sequence number as a hash-like function of the source and destination IP/port plus a secret key generated at boot. This keeps the useful property of avoiding stale-packet confusion within one connection, while making sequence numbers for different connections independent of each other, so guessing one no longer helps predict another.

DNS spoofing and DNSSEC (44:20)

Because DNS runs over UDP with a single round trip and no sequence numbers, an attacker who knows a client is querying for a given name can race the real DNS server's response. The main defenses are randomizing the source port and the 16-bit query ID, giving about 32 bits of combined randomness. The lecture also introduces DNSSEC, which signs DNS records with per-zone keys instead of relying on network-level guesswork, and touches on the awkward problem of proving a name does not exist (NSEC/NSEC3) without letting attackers enumerate an entire domain.

SYN flooding and denial of service (53:24)

Because a server must store state after receiving a SYN (to remember the client's sequence number), an attacker can flood a server with spoofed SYNs and exhaust its connection table. SYN cookies solve this by encoding the needed state into SNS itself, computed from the connection tuple, a secret key, and a coarse-grained timestamp, so the server can verify the final ACK without having stored anything. The lecture also covers DNS amplification, where a small spoofed query can trigger a much larger response directed at a victim, and closes with a brief look at routing-layer trust problems in DHCP and BGP.

Before you watch

• Be comfortable with the TCP three-way handshake (SYN, SYN-ACK, ACK) and how sequence numbers are used for in-order delivery.
• Familiarity with basic DNS query/response behavior is helpful.
• This lecture assumes the buffer-overflow and web-security material from earlier in the course as context for why the instructor contrasts protocol bugs with implementation bugs.

Check your understanding

1. Why is a bug in a protocol's specification, such as TCP's, much harder to fix than a bug in a single implementation?
2. Explain how an attacker with a spoofed source address can complete a TCP handshake if the server's sequence numbers are predictable.
3. How does the SYN cookie technique let a server avoid storing per-connection state while still resisting SYN flooding?
4. Why does DNS's use of UDP make it more vulnerable to response spoofing than TCP-based protocols?
5. What makes DNS a good protocol for mounting amplification attacks, and how could the protocol be redesigned to prevent this?