First of all, this list is great! I feel this is one of the best lists I have ever seen... I thank you all for the great technical depth and openness. We have a product that offers DDoS mitigation with ACLs but I am interested in learning more about uRPF Loose Check Mode to see if we can integrate this idea into our product. In particular, I am interested in the ability of eliminating specific routes from the FIB under uRPF Loose Check Mode to effectively filter specific source addresses that are flooding. As I understand the concept, eliminating an address from the FIB such as x.y.0.0/24 would have the equivalent effect of installing a network-wide ACL rule: deny ip x.y.0.0/24 any Is this right? If this is right, is there any way to use uRPF Loose Check Mode to have an equivalent network-wide ACL rule of the form: deny <proto> x.y.0.0/24 <destination> where: <proto> is NOT ip and <destination> is NOT any? The reason why I ask is that we would like to keep control of these two important aspects of the traffic to avoid filtering out too much and therefore possibly affecting legitimate traffic. Think of the case where a flood targets one of multiple downstream customers and the spoofed addresses correspond to a popular address range (such as Yahoo). Doing a "deny ip x.y.0.0/24 any" would effectively shut down Yahoo's traffic for all downstream customers thus amplifying the attacker's effect. Livio.
As one of the key people pushing uRPF .... uRPF 'Strict Mode' was never ever designed to put on the ISP peering links. It was created to help ISPs scale BCP 38 filtering on the ISP-Customer edge. Knock out the easy 80% of the customers who are simple single homed customers - leaving the other 20% for special BCP38 uRPF/BGP or ACL configs.
uRPF 'Loose Check' was designed for any part of the edge - ISP to ISP (could be customer or peer); the ISP to Customer edge; or the ISP to Multihomed edge. The objective was to provide a quick way to trigger a network wide source address based black hole. It also provides an effective way to filter source addresses with martian and bogons (i.e. addresses not in the FIB). So consider uRPF Loose Check as a source address based "noise reduction" filter and a network wide DDOS counter measure.
So people need to get the two straight. The are completely different:
uRPF Strict Mode for BCP 38 (not for ISP-ISP Peering links)
Cisco: ip verify unicast source reachable-via rx
Juniper (as of 5.3): unicast-reverse-path active-paths
uRPF Loose Check Mode (suitable for ISP-ISP Peering Links)
Cisco: ip verify unicast source reachable-via any
Juniper (as of 5.3): unicast-reverse-path feasible-paths
So you need to frame you response as to the appropriate uRPF mode.
One key reminder - uRPF is just another security tool for an ISP's security tool kit. There is no such thing as a perfect security tool. A craftsman is known not for his/her tools, but how well they use the tools they got to perform their art.
Barry
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Iljitsch van Beijnum Sent: Sunday, May 05, 2002 3:11 AM To: Christopher L. Morrow Cc: nanog@merit.edu Subject: unicast RPF for peers viable?
On Sun, 5 May 2002, Christopher L. Morrow wrote:
I was hoping someone else might mention this, BUT what about the case of customers providing transit for outbound but not inbound
traffic for their
customers? We have many, many cases of customers that are 'default routing' for their customers that get inbound traffic down alternate customers or peers or wherever... uRPF seems like a not so good solution for these instances :( especially since some of these are our worst abusers :(
This dilemma has far reaching repercussions:
If _you_ allow this and forego the unicast RPF check for these customers, this means your peers can't do uRPF towards you without breaking connectivity for these customers.
In a perfect world, there would be no need to do uRPF on peering interfaces, because peers make sure they don't send packets with spoofed source addresses. Unfortunately, in the real world many networks STILL don't bother and thereby allow hard to trace and filter DDoS attacks to be launched from inside their networks.
So what is the collective wisdom on the NANOG list? Is uRPF on peering interfaces a viable option and if it breaks esoteric customer configurations, too bad; or is it something that should be discouraged because it breaks legitimate customer needs?
If you feel strongly one way or the other, but don't want to join the discussion, please reply with a "yes to peering uRPF" or "no to peering uRPF" in private email, and I'll summerize to the list.
Iljitsch van Beijnum