North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: uRPF Loose Check Mode vs. ACL

  • From: Livio Ricciulli
  • Date: Sun May 05 20:29:23 2002 
Richard A Steenbergen wrote:


On Sun, May 05, 2002 at 11:55:21AM -0700, Livio Ricciulli wrote:
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

Not quite.

First, lets be specific by what you mean by "remove from the FIB", as
there are a number of different methods you could use. You could simply
block it from the RIB when generating the FIB, you could go back after FIB generation and try to make it unresolved, or you could change the nexthop to "discard". If you're trying to replicate traditional firewall behavior (filter no matter what) you would have to do it post FIB generation, but if
you are trying to replicate normal routing behavior (ex: a null route) you would have to do it during FIB generation, so that you can potentially have more specific routes which escape the "filter".

escaping the "filter" with more specific routes would be absolutely necessary.

Secondly, when you remove something from your FIB, you also block destination routing as well as source.

Good point; so in ACL equivalent language you are saying that taking out a FIB entry in uRPF Loose Check Mode is equivalent to a network-wide insertion of:

deny ip x.y.0.0/24 any (from the uRPF Loose Check Mode)
deny ip any x.y.0.0/24 (from the absence of a route)

(modulo the more specific routes to escape the "filter" which could be expressed as prepended permits in the ACL equivalent world)

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.


It sounds like what you are looking for has nothing to do with the RPF or
the FIB, but rather simply manual source address filtering.
Well, I am investigating if it is possible today to use uRPF Loose Check Mode to achieve network-wide source/destination address filtering functionality (it seems not from what you write). I immagine that it would be useful to use route advertisements to enforce network-wide access control policies. These policies, however, to be generally interesting for DDoS would have to be at least as expressive as "<deny|permit> <proto> <source> <destination>" (hence my questions).

Livio.