What is IP Spoofing?

IP spoofing is the act of forging the source address in an IP packet header so that it appears to come from a different host. Because the Internet Protocol was designed for a small, trusted research network, there is no built-in mechanism to verify that the source address in a packet actually belongs to the sender. This single architectural decision has been the root cause of some of the largest distributed denial-of-service (DDoS) attacks in internet history, and defending against it remains one of the hardest unsolved problems in network security.

How IP Packets Work

Every packet transmitted across the internet carries an IP header. The header contains, among other fields, a source address and a destination address. Routers along the path use the destination address to forward the packet toward its target. The source address tells the destination where to send replies.

Here is the structure of an IPv4 header, with the fields relevant to spoofing highlighted:

Crucially, routers along the forwarding path do not normally inspect or validate the source address. They only care about the destination address for making forwarding decisions. This means a sender can write any IP address into the source field, and the packet will be delivered to the destination as if it came from that address. The destination has no way to tell the difference — it sees a perfectly valid packet with a plausible source.

Why IPv4 Makes Spoofing Easy

IP was designed in 1981 (RFC 791) for a handful of universities and government research labs that trusted each other. Source address validation was unnecessary in that environment. Three decades and billions of connected devices later, this trust-based design has become a critical vulnerability:

• No built-in authentication — The IPv4 header has a checksum for integrity but no mechanism to prove that the source address is genuine. The checksum only detects bit errors, not deliberate forgery.
• Stateless forwarding — Routers forward packets independently. There is no session state that would let a transit router verify "this packet claiming to be from 8.8.8.8 actually entered the network from the direction of Google (AS15169)."
• Asymmetric routing — On the internet, the path from A to B is often different from the path from B to A. This makes it impossible for a router to simply check whether a packet arrived from the "right" direction based on the destination route.
• NAT hides the problem — Network Address Translation rewrites source addresses as a normal part of its operation, which means "source address rewriting" is not inherently suspicious from a protocol standpoint.

IPv6 does not fundamentally solve this problem. While IPsec was originally envisioned as mandatory for IPv6, practical deployment has not required it, and IPv6 packets can be spoofed just as easily as IPv4 in the absence of filtering.

How Attackers Use IP Spoofing

IP spoofing is not useful for establishing TCP connections — the three-way handshake requires the attacker to receive the SYN-ACK reply, which goes to the spoofed address, not the attacker. But spoofing is devastatingly effective for two categories of attacks: reflection/amplification and flooding.

Amplification Attacks

In an amplification attack, the attacker sends a small request to a public server (the "reflector") with the source address spoofed to be the victim's address. The server sends its response — which is much larger than the request — to the victim. By using thousands of reflectors simultaneously, the attacker can generate traffic volumes far exceeding their own bandwidth.

Common amplification vectors and their amplification factors:

• DNS — A 60-byte query can produce a 4,000+ byte response (especially with DNSSEC-signed records or ANY queries). Amplification factor: roughly 28-54x.
• NTP — The monlist command returns a list of recent clients. A 234-byte request can generate over 100 packets. Amplification factor: up to 556x.
• Memcached — The UDP interface allows get requests on pre-loaded keys. A 15-byte request can return megabytes of data. Amplification factor: up to 51,000x. The 1.35 Tbps attack on GitHub in February 2018 used this vector.
• SSDP — Universal Plug and Play discovery protocol. Amplification factor: roughly 30x.
• CLDAP — Connection-less LDAP over UDP. Amplification factor: 56-70x.
• Chargen — An ancient test protocol (port 19) that returns a continuous stream of characters. Nearly infinite amplification.

Without IP spoofing, none of these attacks would work. The responses would go back to the attacker, not the victim. Spoofing is the enabler that makes amplification-based DDoS attacks possible.

SYN Floods

A SYN flood exploits the TCP three-way handshake. The attacker sends a massive volume of TCP SYN packets — each with a different spoofed source address — to a target server. The server allocates resources for each half-open connection (storing state in its SYN queue) and sends SYN-ACK replies to the spoofed addresses. Those replies go nowhere useful, and the connections never complete.

The server's connection table fills up with these half-open connections, and legitimate users are unable to establish new connections. The server is not overwhelmed by bandwidth — it is overwhelmed by state exhaustion. Modern mitigations like SYN cookies (which avoid allocating state until the handshake completes) help, but large-scale SYN floods with spoofed sources remain a potent attack vector.

Source Address Validation: BCP38 and BCP84

The internet engineering community recognized the spoofing problem early. In 2000, the IETF published BCP38 (RFC 2827), titled "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing." The concept is simple: networks should filter outbound traffic and drop any packet whose source address does not belong to the network sending it.

For example, if a customer network is allocated the prefix 198.51.100.0/24, the ISP's edge router should only accept packets from that customer with source addresses within 198.51.100.0/24. Any packet claiming to be from 8.8.8.8 or any other address outside that range should be silently dropped.

BCP84 (RFC 3704, published 2004) extended BCP38 with more specific guidance for multihomed networks and additional filtering techniques. It describes several approaches:

• Strict mode — Only accept packets if the source address would be routed back out the same interface (strict reverse path). This is the most secure but can break in networks with asymmetric routing.
• Feasible path mode — Accept packets if the source address appears in any route the router knows about via that interface, including backup paths. This handles asymmetric routing better.
• Loose mode — Only check that the source address exists somewhere in the routing table. This catches obviously bogus addresses (like unallocated space) but does not prevent spoofing of real addresses.
• ACL-based filtering — Explicit access control lists specifying which source prefixes are permitted on each interface. The most precise but requires manual maintenance.

The BCP38 Deployment Problem

BCP38 has been a best-practice recommendation for over two decades. Despite this, deployment is far from universal. The CAIDA Spoofer project, which measures the ability of networks to send spoofed packets, consistently finds that roughly 25-30% of autonomous systems still allow spoofing from at least some portion of their address space.

The deployment problem is fundamentally economic: the network that deploys BCP38 does not directly benefit. Ingress filtering protects other networks from attacks originating inside your network. It is a cost you bear for the benefit of the broader internet. This creates a classic commons problem — every network would benefit if everyone filtered, but each individual network has little incentive to invest in filtering.

Deployment is poorest among:

• Access networks in developing regions — ISPs with limited engineering resources or older equipment that does not support filtering efficiently.
• Networks with complex multihoming — Asymmetric routing makes strict-mode filtering difficult without careful tuning.
• Hosting providers — Some hosting and cloud providers allow customers significant control over the packets they emit, including source addresses.
• Legacy enterprise networks — Organizations running outdated edge infrastructure that predates BCP38-aware features.

Several initiatives have tried to improve adoption. The Mutually Agreed Norms for Routing Security (MANRS), overseen by the Internet Society, includes anti-spoofing as one of its core actions. MANRS participants commit to implementing source address validation. Major IXPs and regional NOGs (Network Operator Groups) also promote BCP38 adoption through training and peer pressure.

uRPF: Unicast Reverse Path Forwarding

The most common technical implementation of source address validation on modern routers is uRPF (Unicast Reverse Path Forwarding), defined in RFC 3704. uRPF works by checking the source address of incoming packets against the router's own routing table (the Forwarding Information Base, or FIB):

• Strict uRPF — The router checks whether a packet arriving on interface X has a source address that the router would route back out via interface X. If not, the packet is dropped. This is the strongest form but fails with asymmetric routing.
• Loose uRPF — The router only checks whether the source address exists in the FIB at all, regardless of which interface. This catches packets with completely bogus source addresses (RFC 1918 space, unallocated blocks) but does not prevent an attacker from spoofing any valid, routed address.
• Feasible-path uRPF — A middle ground: the router accepts the packet if the source address appears in any route received via the ingress interface, including non-best routes. This handles multihoming and asymmetric routing while still catching spoofed packets from the wrong direction.

Strict uRPF on customer-facing interfaces at the network edge is the gold standard. It is computationally cheap on modern hardware (it leverages the FIB that the router already maintains), adds negligible latency, and stops spoofed packets before they ever enter the transit network.

How RPKI Helps

RPKI (Resource Public Key Infrastructure) does not directly prevent IP spoofing — it validates BGP route origins, not individual packets. However, RPKI contributes to the anti-spoofing ecosystem in several important ways:

• Accurate routing data for uRPF — uRPF relies on the routing table being correct. If an attacker hijacks a prefix via BGP, they can make spoofed packets from that prefix appear valid to uRPF checks. RPKI Route Origin Validation (ROV) prevents such hijacks, keeping the FIB honest and making uRPF more effective.
• RPKI-based prefix filtering — Networks that drop RPKI-invalid routes also reduce the attack surface for spoofing, because hijacked prefixes cannot be used to confuse uRPF on downstream routers.
• ASPA (AS Provider Authorization) — An emerging extension to RPKI that validates the full AS path, not just the origin. ASPA can detect route leaks and path manipulation that could otherwise be used to evade uRPF by making spoofed traffic appear to arrive from the correct direction.

In this way, RPKI and source address validation are complementary defenses. RPKI secures the control plane (BGP routing), while BCP38/uRPF secures the data plane (packet forwarding). Together, they form a layered defense that is much stronger than either alone.

IP Spoofing and DDoS: The Connection

IP spoofing is the single most important enabler of volumetric DDoS attacks. Without the ability to spoof source addresses, attackers lose two critical capabilities:

1. Amplification becomes impossible — If the attacker cannot forge the source address, reflector responses go back to the attacker, not the victim. The attacker would need to generate the full attack volume from their own infrastructure, which is far more expensive and easily traceable.
2. Attribution becomes feasible — With real source addresses, operators can trace attack traffic back to its origin network and take action. Spoofing provides anonymity that shields the attacker from identification and consequences.

The scale of modern DDoS attacks directly depends on spoofing. The largest recorded attacks — including the 2.5+ Tbps attacks mitigated by major CDNs in recent years — use UDP-based amplification vectors that are only possible because the source address can be forged.

Real-World Incidents

IP spoofing has been instrumental in some of the most significant security incidents in internet history:

The 2018 GitHub Memcached Attack (1.35 Tbps)

In February 2018, GitHub was hit by the largest DDoS attack recorded at that time: 1.35 terabits per second of traffic. The attack used memcached amplification — the attackers sent spoofed UDP requests to thousands of memcached servers with UDP port 11211 exposed to the internet. Each 15-byte request triggered multi-megabyte responses directed at GitHub's IP infrastructure. GitHub's traffic was handled by their network (AS36459), and the attack was mitigated by Akamai Prolexic within 10 minutes, but it demonstrated how a handful of spoofed packets could generate terabits of attack traffic.

The 2016 Dyn DNS Attack

In October 2016, a massive DDoS attack against Dyn, a major DNS provider, took down access to Twitter, Netflix, Reddit, GitHub, and dozens of other sites. While primarily a botnet attack (Mirai), portions of the attack used spoofed source addresses to amplify DNS query traffic. The attack highlighted how DNS infrastructure, which is critical for translating domain names to IP addresses, can be overwhelmed when spoofed traffic targets the resolvers themselves.

The Spamhaus Attack (2013, 300 Gbps)

In March 2013, Spamhaus — an anti-spam organization — was targeted with a DNS amplification attack peaking at 300 Gbps, which was then a record. The attackers used open DNS resolvers as reflectors, sending millions of spoofed DNS queries with Spamhaus's IP as the source. The amplified responses were large enough to congest upstream transit links and cause collateral damage to other networks sharing the same infrastructure.

The Kevin Mitnick Attack (1994)

One of the earliest documented uses of IP spoofing for intrusion (rather than denial of service) was Kevin Mitnick's 1994 attack on Tsutomu Shimomura's computer. Mitnick used IP spoofing combined with TCP sequence number prediction to hijack a trusted rsh session. He spoofed the source address of a trusted host, predicted the TCP sequence numbers for the SYN-ACK (which he could not see because it was sent to the spoofed address), and injected commands into the connection. This attack led directly to improved TCP sequence number randomization in operating systems.

Detecting Spoofed Traffic

Identifying spoofed packets in transit is difficult because, by definition, they look like legitimate packets from the claimed source. However, several techniques provide clues:

• TTL analysis — Packets from the same source address should arrive with similar TTL values (since they traverse similar paths). Spoofed packets often show wildly varying TTLs because they originate from different hosts using different initial TTL values.
• IP ID analysis — The IP identification field is typically incremented sequentially by the sending host. Spoofed packets from multiple attackers claiming the same source will show random, non-sequential ID values.
• TCP behavior — Spoofed SYN packets never complete the handshake. A flood of SYN packets where no source IP ever sends an ACK is a strong indicator of spoofing.
• Geographic inconsistency — A packet claiming to originate from a prefix geolocated in Japan but arriving at a router in Europe via a South American transit link is suspicious. Cross-referencing with BGP data from a looking glass can help identify routing inconsistencies.
• Backscatter analysis — Researchers monitor large unused IP blocks (darknets or network telescopes) for unsolicited SYN-ACK and ICMP responses. These are "backscatter" from spoofed attacks — the reflectors sending replies to addresses that were used as spoofed sources. The volume and nature of backscatter provides insight into global DDoS activity.

Defenses Beyond Source Filtering

Because BCP38 deployment is incomplete, the internet has developed additional defenses that work even when spoofed packets reach their targets:

SYN Cookies

Instead of storing state for every incoming SYN, the server encodes the connection parameters into the TCP sequence number of the SYN-ACK using a cryptographic hash. Only when the client completes the handshake by returning the correct ACK does the server allocate connection state. This makes SYN floods with spoofed addresses harmless — the spoofed addresses cannot return the correct ACK.

Response Rate Limiting (RRL)

DNS servers can limit the rate of identical responses sent to the same destination. If a DNS server sees thousands of identical queries apparently from the same IP (the victim), RRL truncates responses or drops them entirely, reducing the amplification effect.

Flowspec

BGP Flowspec (RFC 5575) allows networks to distribute traffic filtering rules via BGP itself. When a network detects a spoofed attack, it can propagate filtering rules to its upstream providers, which apply the filters closer to the traffic source. This pushes the defense further upstream, closer to where the spoofed packets originate.

Anycast Absorption

Anycast deployments naturally distribute attack traffic across many locations. Since spoofed amplification traffic arrives from reflectors worldwide, anycast distributes it geographically, preventing any single point from being overwhelmed. This is why major DNS providers and CDNs use anycast extensively.

Measuring Spoofability

How do you know whether a network allows spoofing? The CAIDA Spoofer Project maintains active measurement infrastructure that tests networks for spoofing capability. Volunteers run the Spoofer client software, which sends test packets with spoofed source addresses to CAIDA's measurement servers. If the spoofed packets arrive, the network allows spoofing. If they are dropped, the network has filtering in place.

As of recent measurements, roughly 25% of tested autonomous systems allow at least some degree of spoofing. The project publishes results by country, network type, and prefix, giving the community data to push for improved filtering. You can look up any autonomous system in the looking glass and cross-reference it with CAIDA's Spoofer results to understand its filtering posture.

The Future: Closing the Spoofing Gap

Several trends are gradually reducing the internet's vulnerability to IP spoofing:

• MANRS adoption — The Mutually Agreed Norms for Routing Security initiative now includes hundreds of network operators committed to anti-spoofing, collectively covering a significant fraction of global transit.
• Hardware improvements — Modern router ASICs perform uRPF checks at line rate with negligible cost. The performance excuses for not deploying filtering are becoming obsolete.
• Regulatory pressure — Some governments and regulatory bodies are beginning to require source address validation as part of cybersecurity mandates for critical infrastructure.
• RPKI maturation — As RPKI ROV deployment grows, the routing table becomes more trustworthy, making uRPF filtering more reliable and reducing the risk of false positives that discourage deployment.
• Closing amplification vectors — Services like NTP have deprecated the monlist command, memcached has disabled its UDP interface by default, and open DNS resolvers are being systematically reduced. Even without eliminating spoofing, reducing available reflectors shrinks the attack surface.

Complete elimination of IP spoofing would require universal BCP38 deployment — every single AS on the internet filtering at its edges. While that goal is unlikely to be achieved fully, every additional network that deploys filtering makes amplification attacks smaller, slower, and easier to trace.

Investigate Routing Security

You can explore the routing infrastructure that underpins both IP spoofing and the defenses against it. Look up any IP address or network to see its BGP routes, RPKI validation status, and origin AS:

• 8.8.8.8 — Google DNS: check RPKI status and origin AS
• 1.1.1.1 — Cloudflare DNS: see anycast routing paths
• AS13335 — Cloudflare: explore a network with strong anti-spoofing practices
• AS15169 — Google: a major MANRS participant
• AS3356 — Lumen: a Tier 1 transit provider's routing table