Protecting Your Network Edge with Reverse Path Forwarding

Protecting Your Network Edge with Reverse Path Forwarding NetworkWorld.com Community
In the previous post I discussed implementing source filters to secure your network edge boundaries against source spoofing, a common component in Denial of Service attacks. But such filtering requires you to specify the prefixes you expect to see enter your network at a given filtering point; what do you do if there are thousands of prefixes, or a dynamically changing set of prefixes, or both (one usually implies the other)?
Unicast Reverse Path Forwarding (uRPF) can help you out in many of these cases.
Originally created to prevent forwarding loops in IP multicast topologies, uRPF does a forwarding information base (FIB) lookup on the source address of incoming packets. If the lookup indicates that the interface on which the packet was received is a correct outgoing interface toward the source address, the packet is accepted. If the lookup indicates that the route to the source address is in some other direction, the packet is dropped (or accepted but logged, if you configure accordingly). So by looking up the reverse path, the router verifies that the packet is coming from a legitimate source.
By looking in the FIB rather than the RIB, uRPF only sees routes that the routing process has already vetted as a best path. If the router is doing equal-cost (or in the case of EIGRP, unequal-cost) load balancing, the packet can come in on any interface judged to be a best path back to the source.
So if you are accepting dynamic routes from an external neighbor – and remember, despite the comment about EIGRP in the preceding paragraph, EBGP is the only protocol you should allow to learn routes from a router outside of your control – that preclude easy prefix specifications in source filters, uRPF can be a useful substitute.
Keep in mind, source filters are still preferable whenever practical, because you can be specific about what you are filtering. As with dynamic routing or anything else that has an “automatic” aspect to its operation, you are giving up a certain amount of control when you implement uRPF. You have to think carefully about things that uRPF could unintentionally disrupt, such as asymmetric traffic patterns in multihomed networks. And if you do use uRPF, be sure to implement it only on externally connected interfaces; it should be doing its job right at the edge.