uRPF Loose Check Mode vs. ACL

Sun May 5 18:55:21 UTC 2002

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 at merit.edu [mailto:owner-nanog at merit.edu]On Behalf Of
>>Iljitsch van Beijnum
>>Sent: Sunday, May 05, 2002 3:11 AM
>>To: Christopher L. Morrow
>>Cc: nanog at 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
>>
>>