Source address validation limits IP spoofing by checking whether a packet's claimed source is legitimate at the boundary where the packet arrives. A provider can reject a customer's packets if their source addresses fall outside the customer's permitted prefixes. The filter reduces the range of addresses the customer can impersonate.

The check depends on what the interface is expected to carry. A source address allowed on one customer's connection may be blocked on another customer's connection. Reverse-path checks can derive that decision from routing information, but the selected mode must allow the network's legitimate asymmetric and multihomed traffic.

Define the Sources Allowed on Each Connection

A source-prefix access list establishes which addresses a connected network may use. The list must include every prefix allowed on that connection, including addresses added during renumbering or used through another authorized transit arrangement. An incomplete list can reject genuine traffic.

Consider a hypothetical lab example using documentation address space. Customer A is allowed to send packets with sources in 192.0.2.0/24, and Customer B is allowed sources in 198.51.100.0/24. On A's connection, a packet claiming source 192.0.2.17 passes that prefix check. A packet claiming 198.51.100.17 fails it, even though the second range is permitted elsewhere in the lab. These addresses illustrate the policy and are not production allocations.

The distinction matters because a global list of reserved or unallocated space cannot establish which customer may use an otherwise allocated public address. To restrict customers to their own prefixes, the filter must check which connection a packet arrived on as well as its source address.

Place the Check Where Traffic Enters the Protected Network

At a provider's customer-facing interface, ingress validation examines traffic entering from the customer. From the customer's perspective, that traffic is leaving its network. The provider's ingress filter and the customer's egress filter therefore check traffic traveling in the same direction.

A filter close to the originating network can prevent inappropriate sources from traveling farther. A receiving service cannot assume that every upstream network filters spoofed sources. By the time the service's own filter drops a packet, the packet has already consumed bandwidth on the service's access link.

The policy also needs the correct routing instance and packet context. Traffic in separate VPNs may use overlapping addresses without sharing an allowed source set. Allowing an address in one VPN does not make that address valid in another VPN.

Strict uRPF Checks the Return Interface

Strict unicast reverse path forwarding, or strict uRPF, looks up the packet's source in the forwarding table and checks which interface leads back to that source. In the basic model, the arrival interface must be the interface selected for forwarding toward that source.

For a hypothetical router with interfaces A and B, assume its selected route toward source 203.0.113.9 uses A. A packet from that source arriving on A passes the basic strict check. The same packet arriving on B fails that check, even if B is a legitimate way for the sender's traffic to arrive.

The packet's destination has not changed between the two cases. The failure concerns the source lookup and arrival interface. Checking only whether the router can forward the packet toward its destination would miss the reason for the rejection.

A customer network with one connection to its provider may meet this requirement. A network using two providers, traffic engineering, or unequal forward and return paths needs closer examination. Successful routing toward a source through A does not prove that all genuine packets from that source must arrive through A.

Feasible Paths Allow More than the Selected Best Path

Feasible-path uRPF considers acceptable alternative reverse paths, rather than only the best path selected for forwarding. It can retain directionality while allowing traffic to arrive over a legitimate path that is currently less preferred.

Return to the two-interface example. Suppose the router has a best route toward 203.0.113.9 through A and an eligible alternative through B. If the implementation includes B in the feasible reverse-path set, the packet arriving on B can pass. If the router does not include B in that set, enabling feasible-path uRPF alone will not make the packet pass.

When a customer advertises different prefixes to different providers, ordinary feasible-path checking may miss a valid source prefix. Enhanced feasible-path uRPF can associate received prefixes that share an origin autonomous system (AS), the network that announces them. The router can use those relationships to build source-validation lists from routes beyond the best paths installed for forwarding.

In a hypothetical example, a customer originates two prefixes but advertises a different one over each connection. A router that permits only the prefix advertised on the first connection may reject genuine traffic using the other source prefix. A correctly populated enhanced list can include the related prefix when the required origin and customer information are available. Missing origin or customer information can still prevent the router from recognizing a valid source.

Loose uRPF Checks Whether the Source Is Reachable

Loose uRPF requires a usable route toward the source but does not require that route to use the packet's arrival interface. It can accommodate asymmetric arrival, while providing a weaker restriction on which network may claim the source.

In the hypothetical A-and-B case, a usable route through A can allow a packet arriving through B to pass a loose check. The loose check does not establish that the source is allowed to arrive on B. A packet carrying an address from someone else's routed prefix may therefore pass even though a customer-specific access list would reject it.

Default-route treatment affects the value of this check. If a default route counts as sufficient reachability for every source, the filter may permit sources that have no explicit route. Check how the router model and software release treat default routes in the table used for source validation.

Check Linux and Junos Behavior

Linux exposes IPv4 reverse-path filtering through the rp_filter setting, with strict and loose modes. Its configuration is distinct from enabling IP forwarding. A host with several interfaces can be affected by reverse-path validation even when it is not intended to operate as an Internet transit router.

Junos supports unicast RPF for IPv4 and IPv6, with behavior that can depend on the router hardware and forwarding configuration. Check which modes the router supports and which table it uses to look up the source. An ordinary destination-route display does not automatically prove that the source-validation lookup used the same table.

Before enabling validation, identify the permitted source prefixes, the reverse paths available to the check, and the rules the platform applies. Selecting a mode does not ensure that the router has all the route information needed to accept legitimate traffic.

Verify Legitimate Asymmetry before Activation

Before deployment, test both permitted and disallowed source addresses, including cases where legitimate traffic arrives on a different path. Testing only the preferred link while both providers are healthy leaves the multihoming case unresolved.

  1. Record the interface, address family, permitted source prefixes, and selected validation mode.
  2. Inspect the source lookup and any alternative paths used by that mode.
  3. Check an authorized source on each intended connection in an isolated or authorized environment.
  4. Exercise the planned failure and recovery cases, recording the routing state at each point.
  5. Confirm that an unauthorized source fails the intended check and that the drop is attributable to that check.

These are proposed verification steps, not results from a test performed here. A request timing out does not identify which filter dropped it. Compare the test traffic with the filter's counters or diagnostics and the route to the source at the time of the test.

After renumbering, a changed source prefix must be reflected in the validation inputs before legitimate traffic depends on it. With routing-derived validation, recovery timing can also matter: the source-validation set and the forwarding route may not change at the same moment.

A Permitted Prefix Does Not Authenticate an Application

A prefix-level rule cannot distinguish every host within that prefix. A compromised sender may still forge another permitted address in the same range, and an attack using its own legitimate source can remain possible. Source validation therefore limits particular forms of spoofing without proving the identity or intentions of the sender.

Application authentication still needs its own credentials and protocol checks. When an incident requires evidence about a specific host, preserve the attachment and time as well as the accepted source address. Passing a prefix check does not identify a particular account or device.