Once a packet leaves the local network, equipment neither the sender nor the receiver controls handles it. Routers forward it based on tables built from announcements other routers make. The two endpoints then exchange data using a transport protocol whose only identifiers are the addresses, port numbers, and sequence numbers inside the packets themselves.

Two trust assumptions run through everything that follows. Routers trust what their neighbors announce about which networks they can reach. Hosts trust the addresses and sequence numbers in the packets they receive. We begin with routers as targets and with forged source addresses, then examine how the Internet’s networks exchange routes with BGP and how those routes are hijacked. Next, we cover the transport layer: how TCP connections are guessed, flooded, and reset, and what UDP does and does not check.

Two terms describe where an attacker sits. An on-path attacker is somewhere the victim’s packets pass through, such as a compromised router or the gateway position from Part 1, and can see and alter them. An off-path attacker is anywhere else on the Internet, can send packets but cannot see the victim’s, and has to guess anything it needs to know.

Routers as Targets

Compromising a router gives an attacker an on-path position for everything that passes through it: the attacker can redirect, delay, or drop traffic, and read anything that is unencrypted.

A router is a special-purpose computer with an operating system and an administrative interface. Attackers can target it like any other computer. Like many other appliances, routers often ship with the default administrative password. Those passwords are not secret: websites such as routerpasswords.com collect the default username and password for thousands of router models. Attackers use the same lists. Many home and small-office routers also expose their management interface to the Internet and never receive firmware updates. In October 2016, the Mirai botnet assembled hundreds of thousands of routers, cameras, and video recorders by logging in with a short list of factory-default username and password pairs. Part 4 returns to that attack.

A compromised router sees every packet, including the encrypted ones, but it cannot decrypt a TLS session. It can, however, choose where the packets go. The defenses are the same as for any exposed computer: change default credentials, keep the management interface off the Internet, apply firmware updates, and monitor configuration changes.

Forging Source Addresses

IP spoofing lets an off-path attacker hide its own address, claim to be a host that a service trusts, or direct a server’s replies at a victim who never sent a request.

Routers forward a packet based on its destination address. Most do not check whether the source address belongs to the network the packet came from. A host can therefore write any source address into a packet. Unless a filter along the way rejects it, the packet is delivered with the false address. Spoofing has a built-in limit. Replies go to the forged address, not to the attacker, so a spoofed packet cannot by itself complete a login or hold a conversation. That limit is why the blind TCP attacks below have to guess what the reply contained. It is also what makes spoofing useful for the reflection attacks in Part 4, where the attacker wants a server’s reply to go to someone else.

The fix has been known for a long time. In May 2000, the Internet Engineering Task Force published a best-practice document, BCP 38, asking every network operator to perform ingress filtering: drop any packet leaving a customer’s network whose source address does not belong to that customer. Deployment is voluntary and uneven. Measurements by the Spoofer project at CAIDA, a network measurement group at the University of California, San Diego, have found for years that a substantial fraction of networks still forward spoofed packets. An attacker needs only one.

Routing Between Networks

The Internet is a network of networks. Each one is an autonomous system (AS), a set of address prefixes and routers under a single administration: an Internet service provider, university, cloud provider, or large company. Each AS has a unique number. Rutgers is AS 46. The global routing system has more than 75,000 of them.

Announcements and Paths

Autonomous systems exchange routing information with the Border Gateway Protocol (BGP). An AS announces each prefix it owns to its neighbors. A neighbor that accepts the route prepends its own AS number and announces it in turn. An announcement that reaches a distant router therefore contains the list of autonomous systems the route passes through, the AS path. Each AS decides by policy which routes to accept and which to pass on to which neighbors.

Taking part requires a BGP session with a neighboring AS. An ordinary host cannot announce a route. The attacks below require routing access: a customer connection to a provider that doesn’t filter announcements, a compromised router, or control of an AS.

Choosing Among Routes

A router picks the most specific prefix that matches the destination. A route to 192.0.2.0/25, which covers 128 addresses, wins over a route to 192.0.2.0/24, which covers 256, for any address inside the smaller block. Wherever a more specific route is accepted and installed, it wins regardless of path length or who announced it. Among routes to the same prefix, the router applies its local policy and then prefers the shortest AS path.

BGP Hijacking

A BGP hijack is an unauthorized announcement of someone else’s addresses. Wherever it is accepted, it pulls traffic for those addresses into the attacker’s network, where the traffic can be dropped, inspected and forwarded, or answered by an impostor.

The attacker needs routing access. The vulnerability is that BGP does not verify that an AS is authorized to announce a prefix or that the AS path in an announcement is real. A router that doesn’t filter its neighbors’ announcements accepts what the neighbor sends and passes it on. An announcement can reach routers worldwide within seconds.

The simplest hijack announces exactly the victim’s prefix. Routers near the hijacker may prefer the shorter path, while routers elsewhere keep the legitimate route. The more effective form announces a more specific prefix. The victim announces a /22, the hijacker announces a /24 inside it, and every router that accepts the /24 prefers it. Prefix filters and origin validation, described below, limit how far either kind spreads. Once the traffic arrives, the hijacker can do three things with it:

1. Drop it. The addresses become unreachable, which is a denial of service.

2. Inspect it and forward it on to the real destination, which is an adversary-in-the-middle position at the scale of a network. Encrypted traffic passes through unread.

3. Respond to it. The hijacker runs a server at the hijacked address that impersonates the real one.

A related failure is the route leak, in which an AS passes on routes it learned from one provider or peer to another. Traffic then flows through a network that was never meant to transport it. Route leaks are usually configuration mistakes.

YouTube, February 2008

On February 24, 2008, Pakistan Telecom announced the prefix 208.65.153.0/24 to block YouTube in Pakistan. YouTube announced its addresses as 208.65.152.0/22, so the Pakistani announcement was more specific. Pakistan Telecom’s international provider, PCCW, a Hong Kong telecommunications company, accepted and propagated the announcement. Within minutes, routers worldwide sent YouTube traffic to Pakistan, where it was discarded. YouTube recovered by announcing two /25 prefixes, which were more specific still, and PCCW withdrew the bad route about two hours after it appeared. The incident was a configuration mistake rather than an attack. A prefix filter at PCCW would have stopped it at the first hop.

MyEtherWallet, April 2018

On April 24, 2018, an attacker announced five /24 prefixes belonging to Amazon’s Route 53 DNS service from the AS of an Internet provider in Columbus, Ohio. Several large transit providers, the networks that forward traffic between other networks for a fee, accepted and propagated the announcements. For about two hours, DNS queries that should have reached Amazon’s name servers went to servers the attacker controlled.

The attacker responded to only one kind of query: lookups for myetherwallet.com, a website for managing Ethereum cryptocurrency wallets. Those were answered with the address of a copy of the site hosted in Russia. The copy lacked a valid certificate, so browsers showed a warning, but some users clicked through and entered their credentials. Attackers stole about $150,000 in cryptocurrency. The hijack and forged DNS answers defeated everything except certificate validation, which held for every user who didn’t click past the warning.

Softaculous, August 2026

Hijacks haven’t stopped, and the newest ones defeat certificate checks. Hetzner, a large German hosting provider, announces the block 162.55.0.0/16. In August 2026, a small hosting network announced 162.55.80.0/24, a smaller block inside it. Routers that accepted the announcement preferred it because it was more specific. The addresses belonged to Softaculous, a company that sells server management software to web hosting providers. They included the servers that distribute updates for its Virtualizor product. The hijack was active for roughly 22 hours within a 33-hour window, and at its peak most of the Internet’s routing vantage points saw the forged route.

The attacker used the position to obtain a legitimate certificate. Certificate authorities verify that an applicant controls a domain by connecting to it. The hijack routed that connection to the attacker, so the authority issued a certificate for the Softaculous and Virtualizor names. Browsers and update clients saw a valid certificate and didn’t raise a warning. Servers that checked for Virtualizor updates during the hijack received a modified package that installed a backdoor. The update client did not verify a signature on the package.

The chain was a route hijack, then a fraudulent domain-control check, then a valid certificate, then a malicious update accepted without independent verification. The company responded by signing its update packages, which stops the backdoor regardless of how traffic is routed. That protection holds only if the client already has the key that verifies the signature, rather than downloading it through the same hijacked path.

Defending Routing

Because BGP cannot verify an announcement, defenses add verification from outside the protocol and reduce how far a bad announcement can spread.

Filtering and Monitoring

Operators configure prefix filters on each connection to a neighbor. A customer filter lists the prefixes the customer can announce, and the router rejects anything else. Filters stop most accidental hijacks at the first hop. Limiting the number of prefixes accepted from a neighbor prevents a route leak from flooding the table. Monitoring services watch BGP announcements collected from routers worldwide and alert a prefix owner when someone else announces their addresses or a more specific part of them. Detection takes seconds; the response, which involves contacting the announcing AS and its providers, takes longer.

Signing Route Origins with RPKI

The Resource Public Key Infrastructure (RPKI) adds the check that BGP lacks: a signed statement of which AS is allowed to announce a prefix.

The five Regional Internet Registries, the organizations that allocate address blocks for different parts of the world, act as certificate authorities and issue a certificate to each organization that holds a block. The holder uses that certificate to sign a Route Origin Authorization (ROA).

An ROA says two things: this AS may announce this prefix, and it may not announce anything more specific than a given length. An ROA for 208.65.152.0/22 with a maximum length of 22 authorizes that one announcement from that one AS. A /24 inside it, from any AS, is unauthorized.

A router that validates routes compares each announcement it receives with the published ROAs, a check called Route Origin Validation. A route passes origin validation when any covering ROA authorizes its claimed origin AS and prefix length. If one or more ROAs cover the prefix and none authorize the announcement, the check marks the route invalid. With no covering ROA, the claim remains unverified, which is still the case for many prefixes. The operator’s routing policy determines which routes to accept or drop, and most large networks now drop invalid routes.

Three conditions have to hold for this to stop a hijack:

1. The legitimate holder has published an ROA.

2. No covering ROA authorizes the announcement.

3. The receiving network drops routes marked invalid.

In 2008 and 2018, neither YouTube nor Amazon had an ROA for the affected prefixes. With an ROA in place and validation enforced, both announcements would have been rejected. RPKI was standardized in 2012. By September 2026, about 70 percent of prefixes in the global routing table were covered by an ROA, and major transit providers drop invalid routes.

The check covers only the origin AS, which the announcer writes. The Softaculous hijacker exploited that: the forged AS path ended in Hetzner’s AS, the legitimate origin. Hetzner’s ROA for the /16 allowed announcements as specific as a /24, so the hijacked /24 matched the ROA and was accepted. An ROA that allowed only the /16 would have made it invalid, and Hetzner tightened its ROAs afterward.

Verifying the Path

Stopping a forged path requires verifying the path itself, not just its origin. BGPsec does that by having each AS sign the announcement as it forwards it, so that a receiving router can verify every hop. It requires every AS on the path to participate and routers that can sign and verify announcements as they arrive. It is almost entirely undeployed. The key point is that origin validation checks the origin AS an announcement claims, not the path the announcement claims to have taken. Path verification is still rare.

Deployment of every routing defense has been slow for the same reasons. The 75,000 autonomous systems are independently operated. A defense helps only where both the announcing and validating networks participate. A mistake in an ROA causes legitimate routes to drop wherever validation is enforced, so a careless operator can cause an outage in their own network. For years, many operators judged that risk greater than the risk of being hijacked.

Transport Layer Attacks

The transport layer delivers data to the right program on a host and, for TCP, provides a reliable connection. Its identifiers are the four numbers in each packet: the source and destination addresses and ports, and, for TCP, the sequence numbers. An attacker who knows or can guess those numbers can inject segments that a receiver will accept. Injection at the transport layer does not defeat cryptographic protection at the application layer. TLS rejects injected data because the attacker cannot produce a valid authentication tag. A password login alone doesn’t give that protection, since an attacker can inject into an authenticated session that is still sent in plaintext.

TCP Connections

A TCP connection begins with a three-way handshake:

1. The client sends a segment with the SYN flag set, containing a randomly chosen initial sequence number. A SYN asks to open a connection and tells the server where the client’s byte numbering starts.

2. The server replies with a segment that has both the SYN and ACK flags set. It acknowledges the client’s sequence number and provides its own initial sequence number.

3. The client sends an ACK that acknowledges the server’s sequence number.

Both sides now know where the other’s byte numbering starts. Every segment after this contains a sequence number for the data it holds and an acknowledgment number for the data it has received. Each side maintains a receive window, the range of byte numbers it is currently prepared to accept. It discards a segment whose sequence number falls outside it. Sequence numbers let a receiver distinguish a segment that belongs to the connection from one that does not, but they were designed to order data, not to authenticate it.

Guessing Sequence Numbers

Predicting a server’s initial sequence numbers lets an off-path attacker complete a TCP handshake while pretending to be another host. If the server trusts that host by its address, the attacker can issue commands as that host.

The attack needs two conditions. The server must trust clients by their source address, as remote-login services in the 1980s and 1990s did. The server’s initial sequence numbers also have to be predictable, which they were when early implementations chose them by adding a fixed amount for each connection and each second. The attacker opens a connection to the server, reads the initial sequence number, and predicts the next one the server will use. The attacker then forges a SYN from the trusted host, never sees the server’s SYN-ACK, and still sends a correctly numbered ACK followed by a command. A 1985 Bell Labs technical report described the attack. Its use on December 25, 1994, against a security researcher’s computers in San Diego became the standard illustration of why a network address is not an identity.

The fix was to make initial sequence numbers unpredictable. A 1996 proposal, now standardized as RFC 6528, computes each one from a keyed hash of the connection’s addresses and ports plus a secret, so an attacker cannot infer one connection’s number from another’s. Blind sequence guessing against modern systems is no longer practical. An on-path attacker can still read the real numbers and inject data. Services therefore no longer trust a client by its address, and TLS, which rejects injected bytes that are not part of the encrypted stream, is still needed.

SYN Flooding and SYN Cookies

A SYN flood denies service by filling a server’s table of pending connections, so that the server is running, but new clients cannot connect to it.

An off-path attacker can run this attack. The vulnerability stems from an imbalance in the handshake. When the server receives a SYN, it allocates memory for the connection, sends a SYN-ACK, and waits for the ACK to complete the connection.

If the ACK never arrives, the server holds the half-open connection until a timeout, typically tens of seconds. The client spent one packet; the server spent memory and time. The attack sends SYN segments as fast as possible, usually with forged source addresses so the SYN-ACKs go nowhere and the attacker isn’t identified. The server’s backlog of half-open connections fills up, and it refuses legitimate connection attempts. A single machine can fill a server’s backlog, as in the first widely reported SYN flood that took Panix, a New York Internet service provider, offline for several days in September 1996.

SYN cookies, proposed that same month, remove the memory allocation. Instead of storing the half-open connection, the server encodes what it needs into the sequence number it sends in the SYN-ACK, so it can later check it without remembering the request. When an ACK arrives, the server recomputes the value from the packet’s addresses and ports and compares it with the acknowledgment number. If they match, the ACK came from a client that received the SYN-ACK, and only then does the server allocate the connection.

A SYN cookie proves one thing: that the client can receive packets at the address it claims. It doesn’t prove the client is honest. A bot can still complete the handshake. Cookies protect the pending-connection table, not the server’s bandwidth or processor, so a flood large enough to saturate the link still succeeds.

Resetting Connections

A forged TCP reset terminates a connection the attacker wants stopped, whether one victim’s session or every connection to a destination a censor wants blocked.

A segment with the RST flag set tells the receiver to abandon the connection immediately, which lets a host recover from a crashed peer. An attacker who forges an RST with the right addresses, ports, and an acceptable sequence number can terminate a connection, such as a file download or an SSH session. An on-path attacker has everything needed. China’s national Internet filtering system, usually called the Great Firewall, worked this way in its early years. Researchers showed in 2006 that it monitored web requests for banned keywords and sent forged RST segments to both ends, without otherwise blocking the packets. The system has changed many times since.

An off-path attacker must know the connection’s addresses and ports and then guess a sequence number. Older TCP implementations accepted a reset with any sequence number in the receive window. That left a blind attacker with a few hundred thousand guesses out of four billion. A rule change in 2010, RFC 5961, requires the exact next expected number, which leaves a blind attacker one correct value out of four billion and makes guessing impractical.

TLS does not help here. An on-path attacker can drop packets or inject an accepted reset on an encrypted connection just as easily as on a plain one. Encryption protects a connection’s content, not its availability. Connections whose loss is especially damaging, such as BGP sessions between routers, can use TCP-AO, which attaches a message authentication code to every segment so a forged reset is discarded. It authenticates the neighbor’s segments, not the truth of what the neighbor announces.

UDP

A UDP service that accepts unauthenticated requests cannot treat a packet’s source address as proof of who sent it. An off-path attacker can make such a service send its reply to anyone.

UDP has no handshake, sequence numbers, or connection state, so the transport layer provides nothing a receiver can check a packet against. Everything depends on the application. A UDP service that answers any request it receives will answer a forged one. If the reply is larger than the request, the attacker has amplified the traffic. DNS, NTP, and several other UDP services have been used this way to produce floods measured in terabits per second, which Part 4 covers.

A UDP application can add its own checks. It can require a token that the client echoes back before the server does any expensive work, which checks that the client can receive packets at its claimed address. Authenticating message contents requires a cryptographic authentication tag or signature.

QUIC, the transport under HTTP/3, provides connections, ordering, and encryption over UDP. The defenses in the network are the same as for spoofing in general. Ingress filtering keeps forged packets from leaving the attacker’s network, and services rate-limit their responses so that they are less useful as reflectors.

Lecture 10: Part 1 | Part 2 | Part 3 | Part 4
Lecture 10 Study Guide | List of terms