Unicast Reverse Path Forwarding Concepts and Configuration

When connected to public networks, one common method to initiate an attack is to utilize IP source address spoofing. When using this method, the hacker attempts to send traffic into the network with a source address that is known or trusted by the target. If no protection exists, the organizational network will allow the traffic and potentially be open to a number of different attack types. This article explores the Unicast Reverse Path Forwarding (Unicast RPF) feature and how it can be configured to deal with these issues.

Unicast Reverse Path Forwarding Concepts

In the past, the best solution for these problems was to build a set of access lists that would manually be able to block traffic that was coming in from an external interface but sourced from an IP address that existed within the internal network. When dealing with only a small network, this configuration is typically not that big of a problem, as the list of IP addresses to guard against can be rather short and relatively easy to maintain. However, when dealing with a larger organization, the maintenance needed to keep up these access lists (ACLs) with the ongoing allocation of addresses within the organization is time-absorbing. The other problem with ACLs is that they limit the rate in which traffic could be forwarded, which can greatly affect network performance.

To deal with this in a way that solved these problems and required only a small amount of maintenance, the Unicast RPF feature was developed. When using the Unicast RPF feature, all traffic that comes into a configured interface is checked to ensure that the interface that would be used to route traffic back to the source address is the same interface that was used to receive the traffic. This feature performs the same function as the previously-configured ACLs did, with considerably less configuration and hassle. The one caveat of using Unicast RPF is that it only permits traffic whose return path (source interface and address) matches the best reverse path (symmetric routing), thus it does not work well when multiple connections (multi-homing) exist. To deal with this problem, a second version of Unicast RPF was later developed called “loose mode”; when using this mode only the address is matched against the FIB allowing the traffic to be received on any interface. This mode does not provide as much protection as the original “strict mode” but is more effective than having no protection.

The main prerequisite of Unicast RPF is that it relies on the Forwarding Information Base (FIB) that is generated by the Cisco Express Forwarding (CEF) feature; because of this, CEF must be enabled before Unicast RPF.

It is also a good idea to know in what order traffic is processed within a device; Figure 1 below shows this order.

Unicast Reverse Path Forwarding Configuration

The configuration of the Unicast RPF feature is very simple and is only required to be configured on the incoming interface. The steps below detail how the Unicast RPF feature is configured:

The Unicast RPF “loose mode” configuration is rather similar but requires a different command; the steps to configure Unicast RPF “loose mode” are shown below:

Unicast Reverse Path Forwarding Configuration Example

The functionality of this feature can be a little hard to understand, so I’ve included an example that utilizes the functionality of Unicast RPF. Figure 2 shows the topology of the example that we’ll use:

As shown in this example, the correct path from the 10.10.10.0 network to the 20.20.20.0 network is through R2 and R4. If Unicast RPF (“Strict mode”) was configured on R1’s F0/0 and F0/1 interfaces, traffic to and from the 10.10.10.0 and 20.20.20.0 network would pass fine, as long as it was received on the F0/0 interface. If an attacker attempted to send traffic to the 10.10.10.0 network through R3 using a source address of 20.20.20.10 without the Unicast RPF feature enabled, traffic could pass through and reach the destination. With the Unicast RPF feature enabled, the device (in this case R1) will check if the “best” return path is using the F0/1 interface where the traffic was received; when the “best” return path is shown to be through the F0/0 interface the Unicast RPF check will fail and the traffic will be dropped.

Using this same example, if the Unicast RPF (“Loose mode”) was configured, traffic would be allowed onto the 10.10.10.0 network as the 20.20.20.0 network is in the CEF FIB as a reachable network and the source interface would not be checked.

Summary

The best situation to use the Unicast RPF feature is when a site only has a single path out of the network; this way all of the functionality of the “strict mode” can be utilized. However, in many ISP networks, it is common for networks to have multiple paths out of the network. Before the “loose mode” was developed, the Unicast RPF feature was unusable; with its development, some of the functionality can be used in these situations. The Unicast RPF feature is unique from other features in that its configuration is very simple but the concept can be hard to understand and be implemented correctly without affecting valid traffic; many other features are easy to understand in concept but are hard to configure. Hopefully this article has been able to shed some light on this feature and how it can be used on modern networks.