Unicast Reverse Path Forwarding (uRPF)

(Shantel - Networklessons.com) split this topic #24

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

(Mohammad Hasanuz Zaman) #25

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

(Rene Molenaar) #26

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

(Mohammad Hasanuz Zaman) #27

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

(clement d) #28

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 ?

(Lazaros Agapides) #29

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!

(Lazaros Agapides) #30

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

(Paul H) #31

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

(Lazaros Agapides) #32

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

(Paul H) #33

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

(Lazaros Agapides) #34

Hello Paul

Yes I stand corrected. So first the uRPF is checked regardless of the access list, and if and only if uRPF cannot find a reverse path for the packet, then it is either dropped or forwarded based on the ACL that has been specified using the ip verify unicast source reachable via command.

Thanks for the clarification!

Laz

(Ajay R) #35

Hi Rene,

I have couple of questions.

  1. Can i enable uRPF on both ingress & egress interface?
  2. I read somewhere that uRPF rely on CEF table. So we should enable CEF as well to work with uRPF?
  3. How uRPF work with equal & unequal cost load balancing? Like OSPF & EIGRP?

Ajay

(Lazaros Agapides) #36

Hello Ajay

uRPF is a feature that checks the source address on a packet and compares it to the routing table. This means that by definition, uRPF will ONLY function on incoming packets. It can be enabled on any interface, but it will only operate on incoming packets on that interface. Packets that are exiting an interface have already gone through the routing table lookup and thus any uRPF operation cannot be applied to them.

Yes this is correct. According to Cisco:

An important consideration for deployment is that Cisco Express Forwarding switching must be enabled for Unicast RPF to function. This command has been enabled by default as of IOS version 12.2. If it is not enabled, administrators can enable it with the following global configuration command: ip cef

CEF is enabled by default on most routers so it is not so much of a concern. However, you must confirm that CEF is enabled for uRPF to operate.

uRPF is not actually a routing operation. It essentially checks certain conditions and if those conditions are met, the packet can then be routed normally. It doesn’t come into play at all in load balancing or routing protocol path manipulation. In this sense, it functions more like an access list than a routing protocol. Once the conditions are met (either in loose or strict mode) the packet can then be routed normally using whatever routing protocol and whatever load balancing functionality has been configured. If they are not met, the packet is dropped before it even gets to the routing table lookup.

I hope this has been helpful!

Laz

(Nyi Nyi Z) #37

May I know more Detail about Self-pinging.
I confuse about that

(Lazaros Agapides) #38

Hello NyiNyi

When you enable uRPF, it checks to see that the source of the packet is in the routing table. However, whenever a router (or any network device) pings itself, the packet flow is emulated, because the packets are actually sourced from the CPU and enter the interface buffer from inside the router itself. The return path to the router’s own CPU doesn’t go via an interface, therefore it will not be routed, therefore, the source address will not be checked against the routing table and will be dropped.

By configuring allow-self-ping, you are telling the router to modify that default behaviour of uRPF, and process a self ping as a special case, so that such pings will be successful.

I hope this has been helpful!

Laz

(Trust_the P) #39

Hello,
Can you explain more the difference between verification drops and suppressed verification drops?

(Lazaros Agapides) #40

Hello sales2161

According to Cisco:

The Unicast RPF drop count tracks the number of drops at the interface. The Unicast RPF suppressed drop count tracks the number of packets that failed the Unicast RPF check but were forwarded because of the permit permission set up in the ACL.

So the suppressed drop count iterates by one whenever the uRPF condition is not met, but the packet is forwarded anyway because of a permit entry in the ACL.

This has been taken from the following Cisco documentation:

I hope this has been helpful!

Laz

1 Like
(Trust_the P) #41

Hello @lagapides

In the lesson example, we didn’t create any ACL but we got some suppressed drops;

R1#show ip interface fastEthernet 0/1 | include drops
  0 verification drops
  7 suppressed verification drops
(Lazaros Agapides) #42

Hello sales2161

Hmm, that’s interesting, not sure why that is happening. As Rene states in his lesson, it is possible to have an access-list added that will specify exemptions to the uRPF rule. It is these exceptions that the suppressed verification drops should count. Cisco’s documentation states that as well. I’ll ask Rene to take a look and see if he has any more insight.

Thanks!

Laz

(Rene Molenaar) #43

Just to be sure, I just did this lab again.

The Cisco documentation states:

The Unicast RPF suppressed drop count tracks the number of packets that failed the Unicast RPF check but were forwarded because of the permit permission set up in the ACL. Using the drop count and suppressed drop count statistics, a network administrator can takes steps to isolate the attack at a specific interface.

Which leads to belief an ACL is required to see suppressed drops. However in loose mode, when there is no matching route, the packets are counted towards the suppressed drops. I can’t find anything in the documentation about this but that’s what happens :slight_smile:

Rene