It doesn't really defeat the purpose of the uRPF. There are, generally, speaking three modes of operation for uRPF, of which Cisco implements only two. Quoting from Wikipedia, as I'm lazy to type ;-)
- Strict mode
In strict mode each incoming packet is tested against the FIB and if the incoming interface is not the best reverse path the packet check will fail. By default failed packets are discarded.
- Feasible mode (not implemented in IOS -mm)
In Feasible mode, the FIB maintains alternate routes to a given ip address. If the incoming interface matches with any of the routes associated with the ip address, then the packet is forwarded. Otherwise the packet is dropped.
- Loose mode
In loose mode each incoming packet's source address is tested against the FIB. The packet is dropped only if the source address is not reachable via any interface on that router.
Now, given the Strict mode operation, imagine that packet arrives from the Internet going to one of your hosts. If you have a default route pointing out the Internet-facing interface, this packet would be dropped, even thought it's perfectly valid. If you still wish to implement uRPF on an Internet-facing interface, you need to loosen the restrictions, but not completely as a completely useless Loose mode bt allowing the default route to be an acceptable match for uRPF.
Marko Milivojevic - CCIE #18427 (SP R&S)
Senior CCIE Instructor - IPexpert
- Strict mode
Thanks, but before let me share my conclusions, Marko.
Yes, but allowing the default route on the uRPF checking will basically allow ANY source to go into the router. Having an interface facing the internet allowing the default route will basically open a hole to unknown sources accesing the network, and that's basically a big threat (that is if uRPF is used as the only protection mechanism). Naturally this strict uRPF mode without the default route is more suitable for organizations that doesn't have any default route to the internet, so the addresses that they reach are specific routes inside the routing table, something that in 99.99% of the times is not very realistic, so we would need to use the "allow-default" keyword.
Another way to set this up would be to allowing the default route under the uRPF configuration, create the default route, BUT pointing it to the null0/bit bucket interface. So packets would be discarded anyways. This will basically copy the behavior of uRPF strict wihout the "allow-default" option.
The strict uRPF mode as you clearly said will "normally" operate allowing the default route check option, so if we receive an address that should be received via other best interface it will not be allowed. From that perspective the uRPF strict mode will not be defeated, note that, again, if we receive a packet from an internet facing interface, and the source address is spoofed the packet is still dropped EVEN allowing the default route. So uRPF strict mode with default route is still a valid option to use in some organizations. At the end the strict uRPF mode with the "allow-default" will be less efective, but it will eliminate the bogon-sourced traffic with the interface checking for the traffic that shouldn't be receive on less prefered interfaces. The loose uRPF mode with a default route is not going to act on anything, since the loose mode just match the IP address on the FIB, and the default route IP will match anything.
Thanks for your answer, the last part of it helped me to construct the logic.
Message was edited by: Elvin Arias
I found this post by searching Google for "RPF loose worthless". The "allow-default" option isn't needed if you hold the entire BGP routing table.
I came to the same conclusion. As a BGP multihomed provider, I find RPF to be completely worthless. Strict mode causes drops in legitimate traffic. Loose mode allows all traffic. Almost all DDoS spoofing attacks these days use a valid IP address as the intended target.
I believe there are two ways this can be fixed:
1) A way to exclude RPF checks when packets are received from a specific layer 2 MAC address(es). That way my routers can RPF traffic that needs to be checked, and exclude each other when bouncing traffic around internally, as to avoid dropping legitimate traffic.
2) A way to set RPF to check traffic going both inbound and outbound on one interface. I am under the impression that RPF only works on inbound traffic when applied to an interface, so you have to set it on all your interfaces to be effective. By setting it on one interface and marking it for both inbound and outbound traffic, RPF will only be applied when traffic traverses through the one interface in either direction.
Am I correct in my thinking? If so, is there a way to apply either of these methods in IOS? If not, RPF is a failed attempt to help prevent DDoS attacks.