Unicast Reverse Path Forwarding (uRPF)

Really nice Rene !!!

Simple… Easy …And straightforward explanation !!!

Rene, it was so simple and easy approach thank you very much for helping me to understand this, Great Work!!

cool lesson, one thing i have in mind is the uRPF loose mode, what i dont get is the purpose on this one.

“Since it has an entry for this source in its routing table it will accept both packets. It doesn’t care where it came from, as long as there is an entry in the routing table.”

i think this is also the normal behavior of router when no uRPF Loose mode is configured right?
if theres a route in 2.2.2.2, R1 will accept the packets that has a source of 2.2.2.2.
i see no difference in uRPF loose mode vs no uRPF config.

on your example, it only have a route going to R2, so the R3’s ping source loopback0 will not a reply. i simulate this one, yes it did suppressed the R3’s ping but i also have a “debug ip packet” enabled on R2 and it seems like when R1 receives the ping from R3 source loopback 0, it forwards the packet to R2. is this the behavior of uRPF loose mode?

here’s R2 debug:

*Aug  9 14:02:16.311: IP: s=20.0.0.1 (FastEthernet0/0), d=2.2.2.2, len 100, input feature, MCI Check(92), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Aug  9 14:02:16.311: IP: s=20.0.0.1 (FastEthernet0/0), d=2.2.2.2, len 100, rcvd 2
*Aug  9 14:02:16.311: IP: s=20.0.0.1 (FastEthernet0/0), d=2.2.2.2, len 100, stop process pak for forus packet
R2#
*Aug  9 14:02:18.311: IP: s=20.0.0.1 (FastEthernet0/0), d=2.2.2.2, len 100, input feature, MCI Check(92), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Aug  9 14:02:18.311: IP: s=20.0.0.1 (FastEthernet0/0), d=2.2.2.2, len 100, rcvd 2
*Aug  9 14:02:18.311: IP: s=20.0.0.1 (FastEthernet0/0), d=2.2.2.2, len 100, stop process pak for forus packet

the 20.0.0.1 is the interface of R1 going to R3

Hi John,

The difference is that normally a router will accept any packet from any source, it doesn’t matter what it has in its routing table…it’s only used for forwarding decisions.

With uRPF loose mode, the router will not accept any packets unless it has an entry for the source in its routing table.

Rene

Hi Rene,

In loose mode pings from R3 didn’t work because on R1 we have static route pointing to R2 , Correct ? This got me thinking whats the use of loose mode when pings didn’t work from R3 ? So basically in loose mode packets do get forwarded as long as we have a routing entry ( minus routing entry facing a Null0).

How does default route come in picture here ? Normally I have seen we only gets defaults from ISPs unless we have some webservers@site.

BTW - Nice tutorial!!

Cheers,

HSV

Hi HSV,

That’s right, the pings won’t work since R1 will forward traffic for 2.2.2.2 to R2. In this example I just used this to demonstrate that RPF wasn’t dropping the packets. When you use loose mode, RPF will accepts packets as long as there is an entry in the routing table, it doesn’t matter where it points to.

Let me give you an example where you could use loose mode:

Let’s say that R1, R2 and R3 are running BGP. R1 is a customer router, R2 belongs to ISP1 and R3 belongs to ISP2.

On R1 we have installed a route for 2.2.2.0/24 towards ISP1, our primary connection. When R1 sends a packet to a destination (let’s say 2.2.2.2). then we will forward it to ISP1. It’s possible however that the return traffic will come through ISP2. In this case, strict mode would drop the packet while loose mode will accept it.

Normally you only use default routes for links connecting to ISPs or on “stub” networks where you only have one exit point.

Rene

Hi Rene,

Thanks for your email. I didn’t phase my question properly. My question around default was will this criterion (below) be met in loose mode, if I have a default route ?

  • Do I have a matching entry for the source in the routing table?
But after looking at syntax, I guess we will still have to explicitly mention that?
ip verify unicast source reachable-via {rx | any} [allow-default]
[allow-self-ping] [list]
Thanks.

Hi Harmit,

It will meet your criteria if you have a default route but yes, you need to add that “allow-default” parameter. Otherwise it will drop the packet even if you have a default route.

Rene

Dear Rene,

Great :slight_smile:

uRPF only mitigate spoof of IP address , right ?? Also , please do clarify which pattern of source IP address that will not exist in routing table.I think, we can also filter Invalid source IP using InfastructurE ACL,right ?

Below is the example of Infrastructure ACL…

GW#show access-lists 
Extended IP access list InfastructurE ACL
    10 deny ip 0.0.0.0 0.255.255.255 any 
    20 deny ip 10.0.0.0 0.255.255.255 any
    30 deny ip 127.0.0.0 0.255.255.255 any 
    40 deny ip 172.16.0.0 0.15.255.255 any 
    50 deny ip 192.168.0.0 0.0.255.255 any
    60 deny ip 224.0.0.0 15.255.255.255 any
    70 deny ip host 255.255.255.255 any
    80 deny ip 103.9.181.0 0.0.0.255 any 
    90 deny ip 103.12.83.0 0.0.0.255 any 
    100 permit ip any any 

br//
zaman

Hi Zaman,

It checks for spoofed IP addresses or when in loose mode, it checks if the source address is in the routing table. If not, it is dropped.

Rene

19 posts were merged into an existing topic: Unicast Reverse Path Forwarding (uRPF)

Hi Rene,

Thanks a lot.you are amazing…

I have got that if received packet source ip not in routing table then packet will be drop but can’t understand that which pattern of source IP address(which ip will not exist in RT ) that will not exist in routing table.

br//zaman

Hi @Zaman.rubd

Let’s say our router has two entries in its routing table:

192.168.1.0/24
192.168.2.0/24

When it receives an IP packet from 192.168.1.1 or 192.168.2.2, RPF will accept it since these we have a route for these sources in our routing table. When we receive an IP packet sourced from 192.168.3.3, it will be dropped since we don’t have an entry that matches 192.168.3.3 in the routing table.

Rene

Hi Rene,

I got the uRPF function clearly but want to know how uRPF prevents these spoofing attacks. Actually want want to know “spoofing attacks” Scenario.Sorry for bothering you again n Again .Thanks

br//
zaman

HI rene, great explanation as usual !

Assuming the attacker’s goal is to access the “target devices” behind R1 ( that is to establish a TCP connection with return path). The attacker that has the spoofed Source Address can indeed reach the target hosts, however when the “target host” replies , R1 will forward the reply to the legitimate device holding the “true” source network ( 2.2.2.2 in your example). So in any case the attacker cannot "access " its victim, but rather send them packet with no response right ?

Hello Clement

The example in the lesson tries to ping the actual interface of R1. Adding a host behind R1 and having the attacker try to reach that device is an even more realistic scenario, and yes, you are correct that that is what an attacker would attempt.

In such a case, when an attacker tries to reach a host on the internal network, the uRPF will still function at the router. That is, if the spoofed SOURCE address is in the routing table and corresponds to a DIFFERENT interface than that which it came in on, the packet will be blocked at R1 and will not be further transferred to the “target device” behind R1.

uRPF essentially functions within the routing procedure of the router. It prevents the actual routing of a packet when the aforementioned conditions are met.

I hope this has been helpful!

Hello Mohammad

If you have a routing table that states that the subnet 2.2.2.0/24 for example can be reached via the Fa0/0 interface, then it is only logical that any packets with a source address of 2.2.2.X will come in to the router on that interface.

If a packet comes in to the router with a source address of 2.2.2.X from any other interface, then this behaviour is fishy :slight_smile:. It’s an almost unmistakable sign of an IP spoofing attack. Such an attack involves an attacker trying to hide his identity or trying to impersonate a “trusted” source.

I hope this has been helpful

Laz

Thank you for the informative article. It is much clearer than in the official certification guide! I have a couple of questions:

  1. Does the uRPF check happen in hardware using the FIB? Or does it happen in software?

  2. If you specify an access list at the end of the ip verify unicast. command, how does that function? If a packet matches a permit statement does that allow it to bypass the uRPF check?

Cheers

Paul

Hello Paul

It really depends on the platform you are using. Higher end platforms (6500/6800 with the appropriate supervisor as well as Nexus platforms for example) will support uRFP occurring in hardware thus providing for fast checking and no taxing of other resources.

If you specify an access list, you are essentially telling the router which range of addresses you want checked. So if a source is in the access list specified, the uRPF takes place. If it is not specified in the access list, then the uRPF check is bypassed.

I hope this has been helpful!

Laz

1 Like

Hi Laz

Thanks for the info, but I think your second statement is incorrect. According to this page:

When you configure an access control list (ACL) and a packet fails the Unicast RPF check, the Unicast RPF checks the ACL to see if the packet should be dropped (by using a deny statement in the ACL) or forwarded (by using a permit statement in the ACL). Regardless of whether the packet is dropped or forwarded, the packet is counted in the global IP traffic statistics for Unicast RPF drops and in the interface statistics for Unicast RPF.

So it seems that permitting traffic through an ACL doesn’t bypass the URPF check, but does in effect override it.

Paul