uRPF Loose Check Mode vs. ACL

Richard A Steenbergen ras at e-gerbil.net
Mon May 6 02:11:12 UTC 2002


On Sun, May 05, 2002 at 04:20:43PM -0700, Livio Ricciulli wrote:
>
> 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).

Network wide? Ok that was my first guess actually, that you were trying to 
create an "acl protocol".

Well, like I said, there isn't really such a thing as "removing" something 
from a FIB. A FIB is generated from a RIB, so something special would 
have to happen to make it "unresolved" (as if there was no route at all). 
You can make a route not installed in a RIB, but not remove others of the 
same or longer length from the FIB. :)

Now on the other hand, it's interesting to consider what would (or could)  
happen if you had a special route for example to null0. Obviously with
strict mode, you're not going to match because the nexthop is different.  
In loose mode on the other hand, there is some room to consider a route to
null0 as not a valid route at all, and make it not match. I have no idea
if that is the current behavior of anyone's implementation, but it
potentially could be. Of course then you'd need protocol extensions to
carry around actual null0 routes instead of a nexthop just reserved for
null routes... So this entire conversation is pretty pointless. :)

What we all really need is a protocol which can distribute filtering 
information network-wide. Go make one. :)

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
PGP Key ID: 0x138EA177  (67 29 D7 BC E8 18 3E DA  B2 46 B3 D8 14 36 FE B6)



More information about the NANOG mailing list