Summary

  • Strict uRPF can reject legitimate asymmetric traffic, while loose uRPF gives up interface directionality; RFC 8704 defines per-interface feasible-path sets intended to reduce that false-positive gap.
  • The method inherits the quality of its BGP, prefix-filtering and relationship inputs. It does not authenticate a customer contract, prove deployment or eliminate the cost of larger and changing validation state.

Analysis

Source address validation asks a deceptively hard question: could a packet bearing this source legitimately have arrived on this interface? At a single-homed edge, the forwarding table may provide a clean answer. At a multihomed boundary, the path selected for return traffic can differ from the path used by the packet. Direction is evidence, but a single best route is not the whole authorization record.

BCP 38 established the purpose of ingress filtering: stop traffic with spoofed source addresses near the point where it enters the network and make abuse more traceable. RFC 3704 described several implementations. Strict uRPF looks up the source in the forwarding information base and requires the incoming interface to match the selected return interface. That is simple and strong where paths are symmetric. It can also drop valid traffic when policy or multihoming makes them asymmetric.

Loose uRPF avoids many of those false drops by asking only whether any route to the source exists. The cost is directionality. A source prefix reachable somewhere in the routing table may still be implausible on the interface where the packet appeared. The check can reject unrouted or special-use space without enforcing the narrower customer boundary that operators often need.

RFC 8704 updates that trade-off. It defines an RPF list for each interface: the prefixes that may legitimately appear as sources there. Enhanced feasible-path uRPF expands that list beyond the single best path, but not to every route in the table. Under Algorithm A, if the router received a route for a prefix from an origin AS on an interface, other appropriately vetted prefixes originated by that AS can become feasible on that interface. The method uses evidence from paths that were available even when policy selected another one for forwarding.

That expansion is conditional. RFC 8704 assumes that routes under consideration have already been vetted through prefix filtering and, where used, route-origin validation. A route learned from the wrong party is not made trustworthy because an algorithm can place it in an RPF list. The source set is only as defensible as the routing inputs and the operator's understanding of which adjacency they represent.

For more difficult ISP-customer topologies, Algorithm B allows additional flexibility across an identified customer cone. This can cover legitimate sources whose routes do not appear directly on every acceptable customer-facing interface. It also increases dependence on accurate business-relationship information. A stale cone or misclassified peer can widen the admission boundary beyond what the contract permits.

RFC 8704 discusses using ROA and Internet Routing Registry information to augment RPF lists. These sources can improve prefix-to-origin evidence, but they do not by themselves prove that a particular interface is authorized to carry the traffic. Route authorization and interface authorization remain different claims.

The operational bill is real. More feasible paths mean larger RPF state. BGP changes can make that state transient, so implementations need careful update behavior rather than abrupt acceptance gaps. Operators need observability for list membership, rejected sources, route changes and exceptions. None of the cited sources establishes universal implementation support, present deployment or a measured reduction for a named network.

The IETF's active SAVNET work confirms that the accuracy problem remains open: existing mechanisms may admit spoofed traffic or block legitimate traffic. Its charter is evidence of a continuing standards problem, not evidence that a future architecture is already available. RFC 8704 should therefore be treated as a bounded current method, not the final word on source validation.

Sources