Summary

  • RFC 3704 showed that an ingress filter can reject a legitimate source when strict reverse-path forwarding expects the packet to arrive on the interface selected by the best route back to that source.
  • Feasible-path checks can allow known alternatives, but only when relevant routes are consistently available; loose checks tolerate asymmetry by giving up much of the directional evidence that makes a source filter useful.

The router judged the return path

Picture a packet leaving a multihomed network through Provider B. It carries an address the sender is entitled to use. A router farther along receives it on B-facing interface, looks up that source address, and finds that its preferred route back points toward Provider A. Under strict reverse-path forwarding (RPF), the packet fails. The filter has compared the arrival interface with a route in its own forwarding table; it has not independently established who originated the packet.

That gap between source legitimacy and route symmetry is the problem RFC 3704 took up in March 2004. Published as Best Current Practice 84, it updated RFC 2827, the earlier recommendation for network ingress filtering. The security objective did not disappear when an edge site used more than one provider. What changed was the evidence a router could use: the path a packet actually took need not be the same path the routing system would choose to send traffic back.

RFC 3704 is useful because it refuses to treat “RPF” as one uniform switch. An ingress access list compares each packet's source with prefixes permitted on that interface. It is predictable when current, but a manually maintained list can lag a provider or prefix change. Strict RPF makes a similar decision dynamically: look up the source in the forwarding information base (FIB) and accept the packet only if it arrived on the interface the selected route uses. That makes a compact, inexpensive filter at a symmetric customer edge.

The same simplicity becomes a liability when the return path is asymmetric or the router lacks a legitimate route because of a provider's policy.

More paths change the question

Feasible-path RPF broadens the set of routes that can validate an arrival. Instead of using only the single best route in the FIB, the check can consider alternate paths retained in a routing or RPF-specific table. For a multihomed edge, this can prevent a valid packet from being rejected merely because another path currently wins route selection.

But the route list is not a map of every path that could ever carry the packet. RFC 3704 says feasible-path filtering depends on consistent advertisements reaching the routers that perform the check. A prefix may be present at one provider and absent at another because of route maps or policy. If an advertisement is filtered, the packet can be filtered as well. What looks like a local firewall setting therefore depends on control decisions made across administrative boundaries.

Loose RPF moves to the other end of the trade-off. It asks whether any route to the source exists, not whether that route points to the interface on which the packet arrived. That tolerates asymmetry, but a globally routed spoofed address may satisfy the test. A default route can make “a route exists” an especially weak condition unless the implementation excludes or treats defaults carefully. RFC 3704 therefore limits loose checks' value at the customer-to-provider edge; it describes them as more useful for rejecting unrouted or reserved source space upstream, or checking whether another network appears to perform some filtering.

The document's other remedies make the distributed nature of the problem explicit. An edge may ensure that each provider carries its prefixes, with provider-independent space and BGP where appropriate. A smaller network using provider-based addresses can steer each source prefix toward the provider that assigned it. Access lists can be generated from customer databases instead of being hand-edited. These choices place work at different points; none turns route state into identity.

Filtering is only as complete as its boundary

RFC 3704 also argues that filtering belongs at multiple levels. The first-hop operator is close enough to know which addresses a connected system may use. A more distant router can usually establish only that a source might belong to a reachable prefix. Filtering farther away can still reduce spoofed traffic and improve traceability, but it cannot reveal whether a particular attacker was filtered elsewhere or prove attribution from an accepted address.

The later RFC 8704, published in 2020, updates RFC 3704 with enhanced feasible-path uRPF methods. Its abstract restates the tension: strict checks bind direction tightly, loose checks ignore direction, and ordinary feasible-path checks still have shortcomings. That later work is evidence that the operational problem remained worth refining, not proof that a particular network deployed a method or that every asymmetric topology was solved.

The durable lesson is not “always use strict” or “turn filtering off when paths diverge.” It is to ask what the check actually knows: one selected return route, a maintained set of alternatives, or only the existence of any route. A packet can pass one of those tests and fail another without its source changing. RFC 3704 made the route view part of the security decision—and made route completeness a shared operating responsibility.

Sources