Why does loose-mode uRPF on an internet edge stop far less spoofing than strict mode?

## The check, stated precisely Unicast reverse-path forwarding (uRPF) runs in the forwarding plane, per packet, on ingress to an interface, before any rule base is consulted. It performs one lookup, and the lookup is backwards: instead of asking *where does this packet's DESTINATION live*, it asks *where does this packet's SOURCE live*. The forwarding table is already there and already indexed, so the extra lookup is close to free at line rate. That cheapness is the reason the mechanism exists at all. What the router does with the answer is the mode. **Strict.** The best path back to the source must leave by the interface the packet arrived on. Arrived on the wrong interface, dropped. This is a genuine anti-spoofing control: a host can only successfully claim addresses that the router already believes live behind it. **Loose.** The source must simply have a route somewhere in the table - any route, out any interface. The arrival interface is not considered. **Feasible-path.** A middle position: the arrival interface must match ANY known path to that source prefix, not only the currently selected best one. Alternate paths learned but not installed as best still count. ## Why loose is so much weaker Run the arithmetic on a real edge. The router holds either a full internet table or a default route. In the first case essentially every address that is actually in use has a route; in the second, if the device is configured to let the default route satisfy the check, EVERY address has one. Either way, an attacker forging the address of a real victim - which is the whole point of forging, since the replies must go somewhere the attacker wants them - picks an address that has a route. Loose mode passes it. So the set loose mode actually removes is: sources with no route at all. That is unallocated or reserved space, prefixes withdrawn from routing, and - this is the useful part - any prefix you have deliberately pointed at a discard route. Operators pair loose uRPF with discard routes for known-bad or unallocated ranges precisely to turn a routing decision into a filtering decision at every interface at once. That is a real technique with real value. It is simply not the same as stopping a spoofer. The interview failure is stating that uRPF is enabled at the edge and concluding that spoofing is handled. The correcting fact is that the mode you can actually deploy on a multi-homed edge is the weak one, and the strong one is unavailable exactly where the internet-facing risk lives. ## Why not just use strict everywhere Because strict mode encodes an assumption that routing is symmetric, and on any edge with more than one path that assumption is false. Traffic from a given source may legitimately arrive on the link that is NOT your best return path: a multi-homed neighbour announcing on two links, an estate with two transit providers, traffic-engineering policy that prefers one direction, an inbound path chosen by somebody else's routing policy that you do not control. The packets are real. Strict drops them, silently, at line rate, with the only evidence being a drop counter nobody was watching. Feasible-path exists for exactly this case, and it has a precondition worth stating: it can only accept the backup path if the router actually KNOWS about the backup path. If the neighbour announces the prefix on one link only, or your policy filters the alternate announcement away, feasible-path degrades back into strict and drops the traffic just the same. ## The property that makes uRPF different from an ACL An ACL is a written list. uRPF is a derived policy: its verdict is computed from the forwarding table, so the filter's behaviour changes whenever routing changes. A new peering session, a withdrawn announcement, a failover, a policy tweak by a neighbour - any of these can silently turn a passing packet into a dropped one, or the reverse, with no configuration change on your side. That is the trade. The ACL needs a human to keep it correct; uRPF stays correct for free and stops being predictable. ## Where each mode belongs | Position | Deployable mode | Why | | --- | --- | --- | | Access or user segment with one path out | Strict | Routing is symmetric by construction; no legitimate traffic can arrive on another interface | | Interface to a multi-homed neighbour whose paths you all learn | Feasible-path | Backup paths are known, so the legitimate asymmetry is accepted | | Provider-facing interface on a multi-homed edge | Loose, or nothing | Inbound paths are chosen by other people's policy; strict would drop real traffic in volume | And the outbound half of the problem - stopping your own hosts from forging - is better served by an explicit ACL permitting only your own source prefixes than by any uRPF mode, because that list does not move when routing does.