How it works
Networks that forward packets carrying implausible source addresses allow an attacker to impersonate a victim or hide their own infrastructure. Nothing in IP itself verifies that a source address belongs to the sender.
What spoofing actually buys an attacker
IP has no mechanism for verifying that the source address in a packet header belongs to the machine that sent it. The field is simply data the sender writes. Whether a forged packet is delivered depends entirely on whether the networks along the path choose to check.
Spoofing provides two distinct capabilities, and conflating them causes confusion about what defences apply. The first is concealment: an attacker whose traffic carries forged sources cannot be blocked by source address, because the addresses being blocked are not theirs. The second is redirection, which is more consequential — by forging the victim's address as the source of a request, the attacker causes an innocent third party to send the response to the victim. This is the mechanism that makes reflection and amplification attacks possible at all.
Spoofing is largely confined to connectionless traffic. A protocol requiring a handshake before useful work — TCP, or anything built on it — forces the attacker to receive the response in order to continue, which they cannot do if the response is being delivered somewhere else. This is why reflection attacks are overwhelmingly UDP-based, and why the same techniques do not translate directly to TCP services.
Why the internet still permits it
The fix has been documented since 2000. BCP 38 specifies that a network should not forward packets whose source address could not legitimately have originated from the direction they arrived. A customer network assigned one prefix should never emit traffic claiming to come from another.
The obstacle is incentive rather than difficulty. Filtering protects everyone except the network implementing it: a provider who filters spends effort and gains nothing directly, while the benefit accrues to whoever would otherwise have been attacked. Deployment has therefore been partial for two decades, and while a majority of networks now filter, a persistent minority does not — and a minority is entirely sufficient, because an attacker only needs one network that will forward forged packets.
Backscatter: the victim's-eye view
If your address is being used as the forged source, you receive the responses. Unsolicited replies arrive from servers you never contacted — often legitimate, well-run infrastructure, because reflectors are usually ordinary services rather than compromised hosts.
The diagnostic signature is asymmetry: substantial inbound traffic with no matching outbound requests, arriving from many distinct sources that share a protocol rather than an owner. Reading this as a hostile scan from those servers is a common misdiagnosis and leads to blocking innocent infrastructure. The servers are not attacking you; they are answering a question they were told you asked.
The same signal is also how the wider internet measures attack activity. Backscatter reaching unused address space provides a view of spoofed traffic in aggregate, which is where much published DDoS telemetry originates.
Filtering at the network edge
Source validation is straightforward where the topology is simple and harder where it is not.
- Strict unicast reverse path forwarding accepts a packet only if the route back to its source points out the interface it arrived on. Correct on single-homed customer links, actively harmful on multihomed networks with asymmetric routing, where it discards legitimate traffic.
- Loose uRPF accepts a packet if any route to the source exists. It survives asymmetric routing but only rejects sources that are entirely unrouted, which is a much weaker guarantee.
- Access lists built from the prefixes a customer is actually assigned are the most precise option and the most operationally demanding, because they must be maintained as assignments change.
- Filtering reserved, private and unallocated ranges arriving on external interfaces catches the least sophisticated spoofing and costs almost nothing to maintain.
What you can control as an operator
You cannot stop other networks forwarding forged packets toward you, and no configuration on your own equipment changes that. What you can control is whether your network contributes to the problem, and whether your services can be conscripted as reflectors.
Egress filtering is the first obligation: traffic leaving your network should carry only source addresses you are responsible for. This prevents a compromised host inside your estate from being used to attack a third party, and it is entirely within your control.
The second is ensuring your services cannot amplify. Any connectionless service reachable from the internet that answers a small request with a large response is a usable reflector. Restricting those services to the clients that need them removes your infrastructure from the attack surface regardless of what any other network does.
Verifying your own network
Assume filtering is absent until tested, because misconfiguration is common and silent — a filter that has stopped matching produces no error, only permitted traffic.
Test from inside your own network by attempting to emit a packet with a source address you do not own and confirming it does not leave. Public spoofing measurement projects offer the same check from an external vantage point and will report whether your network appears to permit forged sources. Both are worth running periodically rather than once, since a routing change or hardware replacement can quietly remove a filter that was correct when it was written.
Also known as
What defenders may observe
- Responses arrive for requests the host never sent
- Source addresses fail routing plausibility checks
- Traffic patterns are asymmetric — inbound with no matching outbound
- Sources include reserved, unallocated or internal address space
Prevention and mitigation
- Deploy source address validation at network ingress and egress (BCP 38)
- Apply unicast reverse path forwarding where the routing topology supports it
- Require request validation before emitting large responses
- Filter reserved and internal ranges arriving from external interfaces
Initial response priorities
- Engage the upstream provider or scrubbing service.
- Preserve flow, edge and routing telemetry.
- Apply narrowly scoped filtering and validate legitimate reachability.
Use your approved incident-response plan and adapt decisions to your environment. This is educational guidance, not a substitute for live incident leadership.