Why does spoofing still work in 2026?

Because the network that deploys ingress filtering gains almost nothing from it. It prevents its own customers from forging source addresses, which protects everyone else on the internet. That incentive shape — cost here, benefit elsewhere — is why a practice documented in 2000 remains unevenly deployed, and it is a policy problem rather than a technical one.

What is the difference between strict and loose uRPF?

Strict checks that the best route back to the source points out of the interface the packet arrived on, which is correct on a single-homed customer edge and wrong wherever routing is asymmetric. Loose only checks that a route to the source exists anywhere, which never drops legitimate traffic and only catches sources from entirely unrouted space. Feasible-path sits between them and is the usual compromise on multihomed edges.

Where should ingress filtering be applied?

As close to the source as possible — at the customer edge of an access network, where the set of legitimate source addresses is small and known. Applied far from the source it becomes both less effective and more likely to drop something legitimate.

Does ingress filtering protect me from attacks?

Not directly, and being honest about that matters. It prevents your network being used to attack others. What protects you is everyone else deploying it, which is why it is properly framed as a shared obligation rather than a security product.

How do we check whether our own network permits spoofing?

Send packets with a source address you do not own from inside your network toward a host you control outside it, and see whether they arrive. If they do, your egress path permits spoofing. Run it from each network segment rather than once, because filtering is applied per interface and is rarely uniform.

Mitigation technique

Ingress Filtering: BCP 38, BCP 84 and uRPF

Last updated: August 2026 · The control that protects other people · Reading time ~11 min

A guarded inner boundary checking what leaves as well as what enters, standing for a filter applied at a network border on the way out.

Ingress filtering discards packets whose source address could not legitimately have come from the interface they arrived on. It is the countermeasure to spoofing, and therefore to reflection. Its defining property is that it protects everyone except the network that deploys it — which is why it has been standard practice since 2000 and is still not universal.

Every reflection attack depends on one thing: the attacker’s ability to put someone else’s address in the source field and have the network deliver the answer to that someone else. Remove that ability and the entire amplification family stops working.

That is what ingress filtering does, and it has been documented practice since 2000 RFC 2827. It is also the clearest example in networking of a control whose economics fight its adoption.

The incentive problem

A network that filters its own customers’ source addresses prevents those customers from spoofing. The beneficiaries are every other network on the internet. The cost — configuration, support calls, occasional legitimate traffic dropped — falls entirely on the network doing it.

Nothing about the technology is hard. The reason a quarter-century-old best practice is still not universal is that the party paying is not the party benefiting, which is a policy and procurement question rather than an engineering one. NIST frames it alongside FlowSpec and RTBH as one part of an interdomain picture for exactly this reason NIST SP 800 189.

The modes and what each breaks

Appliance	What it checks	Safe on multihomed edges	Failure mode
Strict uRPF	Best route to the source points out this interface	No	Drops legitimate asymmetric traffic
Feasible-path uRPF	Any known route to the source uses this interface	Usually	Misses spoofing within accepted prefixes
Loose uRPF	A route to the source exists at all	Yes	Catches only unrouted space; weak
Access list	Source matches a configured prefix list	Yes	Goes stale when allocations change

Strength and safety run in opposite directions down this table, which is the whole operational difficulty of the control.

Strict uRPF is correct wherever routing is symmetric, which means a single-homed customer edge. Deploy it on a multihomed edge and it discards legitimate traffic that arrives on a different interface from the one the best route points at — a failure that presents as intermittent unreachability and is very hard to diagnose from the customer’s side RFC 3704.

Feasible-path uRPF accepts a packet if any known route to its source uses that interface, which tolerates the common asymmetry cases while still rejecting sources you have no route for. This is the usual answer on a multihomed edge.

Loose uRPF checks only that a route exists somewhere. It never drops legitimate traffic and catches only sources from entirely unrouted space, which is a genuine if narrow win — a meaningful share of spoofed traffic uses unallocated addresses.

Explicit access lists are the most precise option where the customer’s prefixes are known and stable, and the most likely to go stale when an allocation changes and nobody updates the list.

What it works against

Source-address spoofing, and therefore reflection and amplification — the entire family documented in the amplification factors dataset. A world with universal ingress filtering has no memcached amplification problem, because the forged source never leaves the attacker’s network.

It also makes attribution possible. Spoofed sources are why “block the attacking addresses” is usually bad advice; unspoofed sources make source-based responses viable.

What it does not work against

Anything using real source addresses. Botnet traffic from compromised hosts carries genuine sources, and application-layer floods complete handshakes, which requires a real address. Ingress filtering is invisible to both.

Your own inbound problem. It filters what leaves, not what arrives. A network with perfect egress filtering is exactly as exposed to being attacked as one without.

Operational risk

Strict mode on the wrong interface is the classic outage: intermittent failures for a subset of customers whose traffic is asymmetric, with no obvious cause at either end.

Stale access lists silently block a customer who has been allocated new space.

Uneven application. Filtering configured on some edges and not others gives false assurance; an attacker only needs the segment that was missed.

Tunnelled and encapsulated traffic may present source addresses that look wrong to a naive check, which is a common source of surprise on networks that added tunnels after the filtering.

False-positive risk

Concentrated entirely in strict mode on asymmetric paths, where it is severe and hard to trace. The safe deployment pattern is strict at single-homed customer edges, feasible-path or loose further in, and explicit lists where the prefixes are genuinely known — rather than one mode applied uniformly because it is simpler to document.

How to verify

From each internal segment, attempt to send packets with a source address you do not own to a host you control outside. Anything that arrives shows an unfiltered path.
Confirm which uRPF mode is configured on each external interface, and whether that interface is genuinely single-homed.
Check for customers whose traffic is asymmetric before enabling strict mode anywhere.
Review access lists against current allocations, with a date.
Re-run the first test after any topology change, because the segment that was added is the one that was missed.

Sources

Frequently asked questions

Why does spoofing still work in 2026?: Because the network that deploys ingress filtering gains almost nothing from it. It prevents its own customers from forging source addresses, which protects everyone else on the internet. That incentive shape — cost here, benefit elsewhere — is why a practice documented in 2000 remains unevenly deployed, and it is a policy problem rather than a technical one.
What is the difference between strict and loose uRPF?: Strict checks that the best route back to the source points out of the interface the packet arrived on, which is correct on a single-homed customer edge and wrong wherever routing is asymmetric. Loose only checks that a route to the source exists anywhere, which never drops legitimate traffic and only catches sources from entirely unrouted space. Feasible-path sits between them and is the usual compromise on multihomed edges.
Where should ingress filtering be applied?: As close to the source as possible — at the customer edge of an access network, where the set of legitimate source addresses is small and known. Applied far from the source it becomes both less effective and more likely to drop something legitimate.
Does ingress filtering protect me from attacks?: Not directly, and being honest about that matters. It prevents your network being used to attack others. What protects you is everyone else deploying it, which is why it is properly framed as a shared obligation rather than a security product.
How do we check whether our own network permits spoofing?: Send packets with a source address you do not own from inside your network toward a host you control outside it, and see whether they arrive. If they do, your egress path permits spoofing. Run it from each network segment rather than once, because filtering is applied per interface and is rarely uniform.

Sources

RFC 2827 (BCP 38) — Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing
IETF · 2000-05 · standard · accessed 2026-08-15
RFC 3704 (BCP 84) — Ingress Filtering for Multihomed Networks
IETF · 2004-03 · standard · accessed 2026-08-15
Defines the strict, feasible-path and loose uRPF modes and when each is safe.
NIST SP 800-189 — Resilient Interdomain Traffic Exchange
NIST · 2019-12 · standard · accessed 2026-08-15

Published: August 2026 · Last reviewed: August 2026

Reviewed means the sources above were re-read on that date; the text is only reissued when something material changed.

This guide is updated as vendors release new models and pricing. How we compare vendors