ip verify unicast reverse-path not working

Answered Question

I've configured ip ip verify unicast reverse-path on a Cisco 2611 running 12.3(26) code. ip cef is enabled globally but turned off using the no ip route-cache cef command on all interfaces except the WAN facing interface (serial 0/0).

!

interface Serial0/0

description connected to internet

bandwidth 768

ip address 100.100.20.10 255.255.255.252

ip verify unicast reverse-path

no ip redirects

no ip unreachables

no ip proxy-arp

ip accounting access-violations

ip nat outside

ip route-cache flow

no ip mroute-cache

no fair-queue

no cdp enable

!

Whenever I reload the router, it works for a while, then quits working. The show ip traffic counter for unicast rpf drops quits climbing after a few minutes and stays where it stopped.

IP statistics:

Rcvd: 35015 total, 346 local destination

0 format errors, 0 checksum errors, 0 bad hop count

0 unknown protocol, 17 not a gateway

0 security failures, 0 bad options, 0 with options

Opts: 0 end, 0 nop, 0 basic security, 0 loose source route

0 timestamp, 0 extended security, 0 record route

0 stream ID, 0 strict source route, 0 alert, 0 cipso, 0 ump

0 other

Frags: 0 reassembled, 0 timeouts, 0 couldn't reassemble

0 fragmented, 0 fragments, 0 couldn't fragment

Bcast: 6 received, 0 sent

Mcast: 0 received, 0 sent

Sent: 265 generated, 23074 forwarded

Drop: 1 encapsulation failed, 0 unresolved, 0 no adjacency

120 no route, 467 unicast RPF, 0 forced drop

0 options denied

Drop: 0 packets with source IP address zero

Drop: 0 packets with internal loop back IP address

Can anyone think of a reason it works for a few seconds after bootup then stops?

[edit]

I took out the ip route-cache flow statement thinking that was the problem, but still no change in the counter so far.

I have this problem too.
0 votes
Correct Answer by Farrukh Haroon about 8 years 6 months ago

There are multiple ways you can use to achieve the same goal, some examples are:

> ACLs

> Policy Based Routing + ACLs (Two interfaces, marking on one, dropping via ACL)

> MPF 'drop' keyword

> Black Hole Routing (Routes to Null 0)

> uRPF

Each method has its pros and cons, ACLs and Static routes are difficult to maintain and operate. ACLs with the 'log' keyword are process switched, making them slow.

Black hole routing works by sending spoofed traffic (hitting the bogons) to Null0, since Null0 is a direct adjacency (Sort-of interface) of all CEF-enabled routers, this is relatively faster.

uRPF is commonly used with Remotely Triggered Blackhole routing (RTBH). For example one manages a large organization with multiple entry points into the network. Now you know your network is under a DoS attack from Source 1.2.3.0/24, with RTBH, all edge routers have uRPF enabled, and there is an internal router known as a 'Trigger Router'. You could inject a route into your IGP domain, something like:

ip route 1.2.3.0 255.255.255.0 null0 tag 255

And then all your edge routers would receive this route and with the help of uRPF drop all packets 'sourced' from the attacker network. The process is a little more complicated than this, but I hope you get the idea.

Regards

Farrukh

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.

I think I've found my answer here:

http://www.cisco.com/en/US/docs/ios/11_1/feature/guide/uni_rpf.html

"Routing Tables Requirements

To work correctly, Unicast RPF needs proper information in the CEF tables. This requirement does not mean that the router must have the entire Internet routing table. The amount of routing information needed in the CEF tables depends on where Unicast RPF is configured and what functions the router performs in the network. For example, in an ISP environment, a router that is a leased-line aggregation router for customers needs only the information based on the static routes redistributed into the IGP or IBGP (depending on which technique is used in the network). Unicast RPF would be configured on the customer interfaces-hence the requirement for minimal routing information. In another scenario, a single-homed ISP could place Unicast RPF on the gateway link to the Internet. The full Internet routing table would be required. Requiring the full routing table would help protect the ISP from external DoS attacks that use addresses that are not in the Internet routing table."

Being that this is a pass-through border router between my ISP and my firewall, it has almost nothing in the routing tables. Just a default route to my ISP and its own directly connected networks from the assigned IP's.

I think I have to use a simple bogon and martian ACL to stop invalid packets.

Farrukh Haroon Fri, 05/30/2008 - 05:48

It depends on which mode of uRPF you are using, loose or strict, both behave differently.

ISPs usually go for the loose mode implementation. Also there is an 'allow-default' keyword to use the default route in uRPF check (which is enabled by default).

Have a look at these links:

Strict mode (with old syntax):

http://www.cisco.com/en/US/docs/ios/12_2/security/configuration/guide/scfrpf.html

Loose mode:

http://www.cisco.com/en/US/docs/ios/12_2t/12_2t13/feature/guide/ft_urpf.html

Regards

Farrukh

Thanks Farukh,

I'm looking over those articles. I have no routing protocol like BGP running between my ISP and my router, only a default route for all unknown traffic to go to the ISP's router. How would uRPF know to drop any packets if the default route is allowed?

When using the new command, ip verify unicast source reachable-via rx [edit](strict mode), without allow-default, all packets are dropped. If I allow default, aren't all packets permitted?

The router would only drop packets from subnets on other interfaces. It knows of no other routes [edit] regardless of whether I'm using strict or loose mode.

[edit] I gues I'm wondering if verify unicast reverse-path requires a routing protocol to be in use, or if it will work if there is no routing protocol in use and only a default route to the ISP is configured.

Farrukh Haroon Fri, 05/30/2008 - 07:08

Your understanding is correct. If you don't have any bogons, RFC 2827 filters etc and just have a default route, uRPF won't be able to do much. The use of a routing protocol is not a must.

Hi Farukh,

I'm using that, the NSA SNAC Router Security Configuration Guide, and the Cisco Guide to Harden Cisco IOS Devices, Doc. ID 13608.

I'm also using Thomas Akin's book "Securing Cisco Routers".

I'm working on a Master's Project in Information Technology and it involves router security. Thanks for your help with this!

Ted

Correct Answer
Farrukh Haroon Fri, 05/30/2008 - 10:45

There are multiple ways you can use to achieve the same goal, some examples are:

> ACLs

> Policy Based Routing + ACLs (Two interfaces, marking on one, dropping via ACL)

> MPF 'drop' keyword

> Black Hole Routing (Routes to Null 0)

> uRPF

Each method has its pros and cons, ACLs and Static routes are difficult to maintain and operate. ACLs with the 'log' keyword are process switched, making them slow.

Black hole routing works by sending spoofed traffic (hitting the bogons) to Null0, since Null0 is a direct adjacency (Sort-of interface) of all CEF-enabled routers, this is relatively faster.

uRPF is commonly used with Remotely Triggered Blackhole routing (RTBH). For example one manages a large organization with multiple entry points into the network. Now you know your network is under a DoS attack from Source 1.2.3.0/24, with RTBH, all edge routers have uRPF enabled, and there is an internal router known as a 'Trigger Router'. You could inject a route into your IGP domain, something like:

ip route 1.2.3.0 255.255.255.0 null0 tag 255

And then all your edge routers would receive this route and with the help of uRPF drop all packets 'sourced' from the attacker network. The process is a little more complicated than this, but I hope you get the idea.

Regards

Farrukh

Actions

This Discussion