uRPF behavior

• October 25, 2009
• Technology  

I want to show the behavior of the uRPF feature. Unicast Reverse Path Forwarding.

Basically this is a security feature, to prevent spoofed source IP address (very basic). Its function is to prevent a router from processing a packet comming from an unknown source/wrong interface.

So there are two modes of uRPF: Loose and Strict.

Loose Mode: This mode says, that as long as we have a route to the source IP address, its okay to route/process this packet. It doesnt matter what interface the packet comes in on. Please note, that default, it does not accept a default route as a valid return path. We will change this behavior later on.

Strict Mode: This mode will further enforce the uRPF check, so that the incomming interface of the packet, must be the correct one, as dictated by the routing table.

This is the topology I will use to demonstrate the functionality:

uRPF Topology

This topology is set up, so that R1 will have the IP address of .1 in the end on each subnet, R2 will have .2 and finally R3 will have .3. A loopback on each of the spoke routes have been set up with the ip address of 10.0.0.100/32. This is the IP address we will use to “spoof”. No routing protocols will be in effect at all. Output will be from “debug ip packet”.

First, lets ping the R1 IP address of 192.168.12.1 from R2’s loopback interface, without any configuration on s0/0 on R1:

As can be seen, R1 actually receives the packet and tries to route it accordingly. Since there’s no route to return the traffic its unroutable. The important thing to remember here, is that the router will try to route the traffic. Something we dont want in the case of a spoofing attack.

Now we enable the uRPF loose mode feature on s0/0:

We try to ping from R2 again:

Nothing at all. R1 does not have any route to reach the source IP address of 10.0.0.100 address, so it wont even try to route it! great!

Lets try to make a route back to R2 from R1 and do a ping from R2 to R1 again:

Everything  works out! We have a route match, and uRPF allows the traffic to pass through.

If we now enable uRPF on s0/1 on R1, and ping from R3:

Watch R2:

What happens here, is actually the spoof attack itself, even though we have loose mode on. R3 pings to R1 with the source of 10.0.0.100. R1’s uRPF checks if it has a route. It does! so everything is fine as far as uRPF is concerned. Now we route it accordingly, which means sending it to R2! By doing this manipulation we are actually sending traffic to R2, from R3. This is certainly not what we want.

Now, instead of using the loose mode, lets use the strict mode and try pinging from R3 again:

Nothing! since the traffic from R3, with the IP address of 10.0.0.100 does not match the interface where R1 expects it, it drops it immediately, and does not try to route it at all! We have, by using the strict mode, prevented the spoofing attack.

Allow-Default:

Lets delete the route we created on R1, and install a default route instead:

Pinging from R2 to R1 now doesnt succeed! Remember that by default, default routes are not considered valid for uRPF check. We can disable this by using the “allow-default” parameter:

And we have reachability again 🙂

I hope this little post has shed some light on the uRPF command. A little overseen, but pretty cool feature.