On February 24, 2008, an engineer at Pakistan Telecom, the country’s largest telecommunications provider, configured a router to block YouTube inside Pakistan. Within minutes, most of the world could no longer reach YouTube. Nobody broke into YouTube’s servers. The router announced to neighboring networks that it had the best path to YouTube’s addresses, and those networks accepted the announcement and passed it along.
The protocols that move data across the Internet mostly lack built-in authentication. A router accepts routing announcements from its neighbors. A host accepts a reply that says which hardware address belongs to an IP address. A name server’s reply is believed because it arrived. Replacing these protocols is hard because they run on billions of devices, so the defenses are checks added around them.
Four outcomes recur in everything that follows, and they are not the same: redirecting traffic so it passes through or ends at the attacker, reading its contents, impersonating a service, and denying service. An attacker who controls the path can redirect encrypted traffic or drop it without reading it. Each attack below is described by what it requires, what it exploits, and which outcome it produces.
We begin with how a packet travels from a laptop to a web server, since the attacks only make sense against that background. We then examine attacks on the link layer, the protocols that run within a single local network. Part 2 covers routing between networks and attacks on BGP, together with the transport layer. Part 3 covers DNS, and Part 4 covers denial-of-service attacks.
How a Packet Reaches Its Destination
A network moves packets, chunks of data with a header that says where they came from and where they are going. Every other mechanism in this section exists to get a packet from one program to another program on a different machine.
Addresses and Local Networks
Every Ethernet or Wi-Fi interface has a MAC address, a 48-bit identifier usually assigned by the manufacturer and written as six pairs of hexadecimal digits, such as b4:96:91:cf:f4:a4. It identifies an interface only on the local network it is attached to. It is not a reliable identity: software can change it, and modern phones and laptops randomize their Wi-Fi addresses on purpose.
An IP address identifies a host across networks. An IPv4 address is 32 bits, written as four decimal numbers, such as 128.6.4.2. IPv6 addresses are 128 bits long and were introduced because the world ran out of IPv4 addresses. IP addresses are allocated in blocks called prefixes. The notation 128.6.0.0/16 means the first 16 bits identify the network, so all addresses from 128.6.0.0 through 128.6.255.255 belong to that block, which Rutgers uses.
Two kinds of addresses are never routed across the Internet. Private addresses such as 192.168.1.1 or 10.0.0.5 are used inside homes and organizations. The loopback address 127.0.0.1 always means the computer itself. Both come up in Part 3.
A local network is a set of devices that can send frames, the link layer’s unit of data, directly to one another through a switch or a Wi-Fi access point. A switch has many physical ports, one cable per port. It learns which MAC address is reachable through each one by watching the source addresses of arriving frames. A frame for a known destination is forwarded only to that port. Devices on the same local network share a broadcast domain, because a frame sent to the broadcast address reaches every one of them.
A router connects a local network to other networks. A host that needs to reach an address outside its own network sends the packet to the router, known as the default gateway, which forwards it toward its destination.
Joining a Network
A laptop that connects to a network doesn’t have an address yet. It broadcasts a request using the Dynamic Host Configuration Protocol (DHCP). Any DHCP server that receives the request may offer an IP address, the default gateway address, and a DNS server address. The laptop selects one offer, usually the first to arrive, and confirms it with that server. Nothing in the exchange proves that the server was authorized to make the offer.
To send a packet to another host on the same local network, the laptop needs that host’s MAC address. The Address Resolution Protocol (ARP) provides the mapping for IPv4. The laptop broadcasts a request asking which device has a given IP address. The device with that address replies with its MAC address, and the laptop caches the reply. Reaching the default gateway works the same way.
Layers
Network software is organized in layers, and each layer adds its own header to the data it is given:
-
The link layer moves frames between devices on the same local network. Ethernet and Wi-Fi are link layer technologies, and MAC addresses belong to this layer.
-
The network layer moves packets from the source host to the destination host across any number of networks. The Internet Protocol (IP) defines this layer, and routers operate here.
-
The transport layer delivers data to the right program on the destination host. A port number identifies the program, so a packet addressed to port 443 goes to the program listening there, usually a web server. A port number has nothing to do with a switch’s physical ports; the term applies to both. The two transport protocols are TCP and UDP.
-
The application layer is the protocol the programs themselves speak: HTTP for the web, SMTP for email, and DNS for name lookups. TLS encrypts a connection and authenticates the server. It runs on top of TCP and beneath HTTP, and people usually group it with the application layer. Applications commonly use TLS libraries above the operating system’s TCP/IP stack.
An Ethernet frame contains an IP packet, which contains a TCP segment, which contains HTTP data. Each link wraps the packet in a new frame, since each hop is a different local network with different MAC addresses. Routers use the destination IP address to forward the packet and update a few header fields on the way. Firewalls, address translators, and proxies along the path can inspect or change more.
TCP and UDP
The Transmission Control Protocol (TCP) gives two programs a reliable, ordered stream of bytes. Before any data is sent, the two sides exchange three messages to set up a connection. Each byte is numbered with a sequence number, so the receiver can reorder data, detect gaps, and acknowledge what it received. Lost segments are retransmitted. Email, file transfer, and most of the web run over TCP.
The User Datagram Protocol (UDP) sends individual messages with none of those mechanisms. A program hands UDP a message, and UDP sends it. DNS, voice and video calls, online games, and time synchronization use UDP because a connection would add delay and the application can handle lost messages itself. An application can also build its own reliability on top of UDP. HTTP/3, the newest version of the web protocol, runs over QUIC, which provides connections, ordering, and encryption over UDP.
Names
People use names such as www.rutgers.edu, but packets are addressed to IP addresses. The Domain Name System (DNS) translates names into addresses. A host sends a query to a resolver, a server usually operated by the organization’s IT group or the user’s Internet service provider. If the resolver does not have the answer cached, it asks a chain of other servers, starting at the root of the name hierarchy, until it reaches one that is authoritative for the domain. Part 3 examines this process in detail.
A Web Request, Step by Step
Consider a laptop plugged into an Ethernet jack on campus, using IPv4 and loading https://www.rutgers.edu over TCP. The following steps happen before the first byte of the page arrives:
-
The laptop joined the network earlier and received its IP address, the gateway address, and a DNS server address from DHCP.
-
The DNS server is outside the laptop’s local network, so the laptop needs the router’s MAC address. If it is not cached, the laptop sends an ARP request and caches the reply.
-
The browser asks the resolver for the address of
www.rutgers.edu. The query is a UDP message, sent in a frame addressed to the router. The resolver replies from its cache or looks up the name. -
The laptop starts a TCP connection by sending a SYN segment. The Ethernet frame that holds it is addressed to the router’s MAC address, and the IP packet inside the frame is addressed to the web server.
-
The router, and every router after it, looks up the destination address in its routing table and forwards the packet to the next router. When the packet crosses from one organization’s network into another’s, the route it follows was chosen based on announcements exchanged between the two networks using the Border Gateway Protocol (BGP).
-
The SYN arrives at the web server, which replies. The laptop and the server complete the TCP handshake and set up a connection.
-
The browser and server run a TLS handshake over that connection. The rest of the exchange is encrypted, and the server has proven its identity with a certificate.
-
The browser sends an HTTP request, and the server sends the page.
Nearly every step relies on a message that the recipient cannot verify, and each of those steps is the target of an attack:
| Step | Protocol | Attack |
|---|---|---|
| 1. Receive network configuration | DHCP | A rogue DHCP server supplies the attacker’s gateway or DNS server |
| 2. Find the router’s MAC address | ARP | A forged ARP reply redirects traffic to the attacker |
| 3. Translate the name to an address | DNS | A forged reply sends the browser to the attacker’s server |
| 4. Send the frame to the router | Ethernet | A switch with an overflowed CAM table copies the frame to other ports |
| 5. Route packets across networks | BGP | A false route announcement pulls traffic into the attacker’s network |
| 6. Set up a connection | TCP | A flood of connection requests exhausts the server |
| 7. Authenticate the server and encrypt | TLS | The server’s certificate is verified, so this step resists forgery |
| 8. Send a request | HTTP | A flood of requests exhausts the application |
Step 7, the TLS handshake, is the only one that includes authentication and encryption. It protects the contents of the exchange and the server’s identity. It doesn’t prevent packets from being redirected, delayed, or dropped, and several of the attacks that follow are designed to work around it.
Why the Protocols Trust
The Internet’s design follows the end-to-end principle, stated in a 1984 MIT paper. Application-specific functions such as reliability, security, and error recovery belong in the communicating hosts, not inside the core of the network.
The argument has two parts.
First, only the endpoints can tell whether a function was performed correctly for the application. A network can deliver every packet, but only the receiving application can confirm that the file it assembled is the one that was sent. The network’s version of the check does not remove the need for the application’s.
Second, a function built into the network imposes its overhead on every application, including those that don’t need it. A voice call or a DNS lookup doesn’t need guaranteed in-order delivery. A network that provided it anyway would slow those applications down to serve the others. IP therefore does not guarantee delivery or ordering. TCP at the endpoints retransmits lost data and reorders it for the applications that need that, and TLS at the endpoints provides security.
The protocols that run the network were also designed for a much smaller Internet. ARP was specified in 1982, DNS in 1983, and BGP in 1989, and none of them includes cryptographic authentication.
Replacing them is impractical because every operating system, router, and name server implements them. Security has instead been added around them: TLS for encrypted, authenticated connections; DNSSEC for signed name records; RPKI for signed routing authorizations; and checks built into switches, routers, and resolvers. An attacker who can send a message that looks like what a protocol expects is still usually believed.
Attacks on the Local Network
Most attacks in this section require the attacker to be on the same local network as the victim; the evil twin instead creates a network that the victim joins. Local access can come from an open Wi-Fi network in a coffee shop or airport, a compromised machine inside an organization, or a device plugged into an unused Ethernet jack in a conference room. From that position, the attacker exploits the assumption that every device on the local network is telling the truth.
Overflowing a Switch’s CAM Table
A CAM table overflow attack makes a switch copy frames it would normally deliver to one port onto other ports, so that an attacker on one of those ports can read any unencrypted traffic among them.
A switch stores its table of MAC addresses and ports in content-addressable memory (CAM), a kind of memory searched by content rather than address. The switch presents a destination MAC address, and the memory returns the matching port in a single step. That is what lets a switch forward frames at wire speed. CAM is expensive, so the table is small, often a few thousand entries.
The attacker needs a port on the switch. The vulnerability is that a switch learns addresses from incoming frames and the CAM table has a fixed size. The attacker floods the switch with frames carrying invented source MAC addresses until the table is full. On a vulnerable switch, the switch copies a frame for a destination missing from the table to all other ports on the same logical network because it no longer knows where to send it. Destinations still in the table are switched normally.
The result is eavesdropping on part of the traffic crossing the switch: passwords and session cookies sent over unencrypted protocols, and the names of the hosts the victims talk to. The attacker also copies encrypted traffic, but cannot read it.
The defense is port security on a managed switch, which an administrator can configure. The switch is told how many MAC addresses may appear on each port, or which specific addresses are allowed. It can disable a port or raise an alert when the limit is exceeded. Unmanaged switches, the kind sold for home use, usually don’t have these controls.
Poisoning ARP Caches
ARP cache poisoning places the attacker’s machine between a victim and its router, so that the attacker can read, alter, drop, or delay the victim’s traffic without the victim noticing.
The attacker needs to be on the victim’s local network. The vulnerability is that ARP does not authenticate replies. A host that receives an ARP reply updates its cache with the mapping it contains. In many operating systems, it does so whether or not it asked. Unsolicited announcements are a normal part of the protocol. A device that boots or changes its address broadcasts a gratuitous ARP, an unrequested announcement of its own mapping, so there is nothing suspicious about one arriving.
Consider one laptop, one router, and the attacker. The laptop’s cache correctly maps the router’s IP address to the router’s MAC address. The attacker sends the laptop a forged reply claiming that the router’s IP address belongs to the attacker’s MAC address. The laptop replaces the mapping. Every packet it sends to the router now goes to the attacker’s machine instead. The attacker sends the router a second forged reply claiming the laptop’s IP address, redirecting the laptop’s inbound traffic as well. The attacker forwards everything on to its real destination, so the laptop doesn’t see any disruption. The same procedure can be repeated for any other host whose cache accepts the forged mappings. The attack is also called ARP spoofing, and tools that automate it are freely available.
The result is redirection. The attacker can read any unencrypted application data, modify anything that isn’t authenticated, and drop or delay anything. A correctly validated TLS session protects its contents. The attacker can neither read nor alter the data, and a browser rejects a certificate that does not match the site’s name. The attacker still sees which addresses the victim talks to, still reads any unencrypted protocol, and can still block the traffic. Content protection and availability are different properties.
Switches can also validate ARP messages. Dynamic ARP Inspection (DAI) is a feature of managed switches that checks every ARP reply against a table of known IP-to-MAC bindings and drops replies that do not match. The table is usually built by monitoring DHCP traffic, as described below. Critical hosts can also be given static ARP entries that replies cannot overwrite, but static entries do not scale to networks where devices come and go.
The IPv6 Equivalent
IPv6 has the same attack with the same goal: redirecting a victim’s traffic through the attacker’s machine.
IPv6 replaced ARP with the Neighbor Discovery Protocol (NDP), which trusts every message on the local network just as ARP does, including the message that tells hosts which router to use. An attacker can claim a neighbor’s address to intercept its traffic, or claim to be the router. Many networks that never deployed IPv6 still have hosts that listen to those messages, so the attack works even where nobody thought IPv6 was in use. Managed switches have inspection features for NDP equivalent to the ARP and DHCP checks in this section.
Spoofing DHCP
DHCP spoofing lets the attacker supply a victim’s network configuration, including where the victim’s traffic goes and which name lookups it trusts.
The attacker needs to be on the victim’s local network. The vulnerability is that a DHCP client can’t tell an authorized server from any other machine that answers. The attacker runs a rogue DHCP server. If the victim selects the attacker’s offer (usually because the attacker answered first), the victim configures itself as the attacker requests. The attacker can supply two kinds of false configuration:
-
A false default gateway, so that all of the victim’s outbound traffic goes through the attacker’s machine. This gives the same position as ARP poisoning, with one exchange rather than a continuous stream of forged replies.
-
A false DNS server, so that the attacker controls which address every name resolves to. The victim types the correct bank name and reaches a server the attacker runs. Part 3 covers this family of attacks under the name pharming.
A separate attack, DHCP starvation, denies service instead. The attacker requests leases for thousands of invented MAC addresses until the legitimate server has run out of addresses to hand out. New devices then cannot join the network, or will accept a rogue server’s offer because it is the only one. The two attacks are often combined.
The defense against spoofing is DHCP snooping on a managed switch. The administrator marks the ports that lead to the real DHCP server as trusted. The switch drops DHCP server replies that arrive on any other port. The switch also records every lease it sees in a binding table that maps each IP address to a MAC address and a port. Dynamic ARP Inspection uses that table to validate ARP replies. Blocking rogue replies does not stop starvation, since the attacker is sending requests, not replies. Starvation is limited by port security and by capping the rate of DHCP requests per port.
Crossing VLAN Boundaries
VLAN hopping gets the attacker’s frames into a network segment that was supposed to be isolated from the attacker’s, such as the finance servers from a guest port, without passing through the router or firewall between them.
Organizations divide one physical network into virtual LANs (VLANs) so that, for example, accounting, engineering, and guest devices are on separate logical networks even though they share the same switches. A switch associates each port with a VLAN. Frames on a link between two switches, called a trunk, include a tag that says which VLAN each belongs to. Traffic between VLANs must go through a router or firewall. The access rules that make the separation useful must be configured there.
The attacker needs a port on a switch. The vulnerability is a switch configuration that lets an end device act like another switch. In switch spoofing, the attacker’s machine sends the messages that switches use to negotiate trunk links with one another. A switch with automatic trunk negotiation enabled converts the attacker’s port into a trunk and begins forwarding the trunk’s VLANs to it. A second technique, double tagging, exploits a different default and is described in the sidebar. As a result, the attacker can send frames into, and, in the switch-spoofing case, receive frames from, VLANs the design meant to keep apart.
The defenses are to disable trunk negotiation on every port that connects to an end device and to configure trunks by hand with only the VLANs they need. Unused ports go into an isolated VLAN, so that plugging a device into a spare jack yields nothing.
Rogue Access Points
An evil twin access point gives an attacker the gateway position ARP poisoning does, without joining the victim’s network. A fake login page on it collects whatever the victim types into it.
The attacker needs to be within radio range of the victims. The vulnerability is that a Wi-Fi network is identified by a name that anyone can broadcast. On an open network, such as an airport’s free Wi-Fi, there is nothing else to check. The attacker sets up an access point with the same name. A victim whose device chooses it, or who selects it by hand, connects to the attacker’s equipment. The attacker’s equipment then runs the DHCP and DNS servers the victim is told to use.
The result is the same redirection ARP poisoning produces, with the same limit. TLS protects the contents of validated sessions, and the attacker reads only unencrypted traffic. The fake login page is the exception, since it is the attacker’s own page, and whatever the victim enters goes directly to the attacker.
A password-protected network stops an attacker who does not know the password, since the victim’s device cannot complete the connection with an impostor. If the attacker also knows the shared password, it doesn’t identify the legitimate operator. Enterprise Wi-Fi authenticates the network to the client and the client to the network, but only if the client is configured to validate the authentication server’s certificate.
What Each Attack Requires and Produces
The attacks in this section differ in what the attacker needs and what the attack achieves:
| Attack | Required access | What is exploited | Result |
|---|---|---|---|
| CAM table overflow | A port on the switch | The switch learns any source address | Copies of other devices’ frames |
| ARP cache poisoning | Same local network | Hosts accept unauthenticated ARP replies | Victim’s traffic routed through the attacker |
| NDP spoofing | Same local network | Hosts accept unauthenticated neighbor and router messages | Victim’s traffic routed through the attacker |
| DHCP spoofing | Same local network | Clients cannot verify a DHCP server | Attacker chooses the victim’s gateway and DNS server |
| DHCP starvation | Same local network | The server’s address pool is finite | New devices cannot join |
| VLAN hopping | A port on a switch with permissive defaults | Trunk negotiation or native VLAN handling | Frames cross a segment boundary |
| Evil twin | Radio range, and a victim who connects | A network name proves nothing | Victim’s traffic routed through the attacker |
The protocols weren’t designed to authenticate anything, so the switch is configured to verify what they don’t. It checks which ports may send DHCP replies, which address bindings are genuine, and how many addresses a port may claim. Encryption at the transport layer then limits what an attacker who gets past those controls can do with the traffic.
Lecture 10: Part 1 | Part 2 | Part 3 | Part 4
Lecture 10 Study Guide | List of terms