[j-nsp] uRPF config

[harry]

Butting in...

The below is snarfed from the Juniper Networks Security Solutions class:

With a Default Route
If you configure a default route that uses an interface configured with
uRPF, uRPF behaves as follows:
Strict mode: If the router finds no corresponding route in the routing
table, it accepts the packet. The router does not accept the packet
when: 
The packet has a source address that matches a prefix in the routing
table; or 
The interface does not expect to receive a packet with this source
address prefix. 
Loose mode: The router automatically accepts all packets. For this
reason, we recommend that you not configure uRPF loose mode on
interfaces that the default route uses. 


With No Default Route
Unicast RPF without a default route behaves as follows: 
Loose mode: The router does not accept the packet when the packet has a
source address that does not match a prefix in the routing table. 
Strict mode: The router does not accept the packet when either of the
following is true: 
The packet has a source address that does not match a prefix in the
routing table; or 
The interface does not expect to receive a packet with this source
address prefix. 

The key is that loose accepts the packet, regardless of the incoming
interface, as long as there is a route in the routing table to that
prefix. The issue with loose in combination with a default route is that
all packets will be accepted. Core routers should not rely on a default
route, IMO, but this is the reason for the caveat.

HTHs.





> -----Original Message-----
> From: juniper-nsp-bounces at puck.nether.net 
> [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Pekka Savola
> Sent: Thursday, September 18, 2003 4:42 AM
> To: Sonny Franslay
> Cc: juniper-nsp at puck.nether.net
> Subject: Re: [j-nsp] uRPF config
> 
> 
> On Thu, 18 Sep 2003, Sonny Franslay wrote:
> > > In other words, feasible path strict uRPF works in most 
> cases also 
> > > with asymmetrical routing and multihomed scenarios.  This is only 
> > > implemented by Juniper AFAIK.
> > 
> > so what is the significant of "rpf-check mode loose" on the 
> interface 
> > when I use feasible path?
> 
> No different when you're using active paths.  Remember that 
> with loose mode, you allow any route anyway.  If you only 
> mean to use loose mode though, I'd recommend use active paths 
> -- fewer things to keep track of.  
> The difference between feasible and active paths in this 
> context is just a race condition, it seems.  
> 
> By the definition, feasible paths just gives you "more"  than 
> just one active path.  The list of all paths is still the same.
>  
> > Also what would the be the effect when I have a default route 
> > configured?
> 
> For (strict) routes, it depends on where the default route 
> points to.  If it's a real default route, I think the loose 
> mode is useless -- but this should be confirmed or tested -- 
> there are some implementations which ignore default routes 
> when doing a loose RPF lookup.
> 
> What we've been unable to get a clear answer from is whether 
> a _static 
> null default route_ will yield the same behaviour as a default route 
> pointing to some real interface.
> 
> I think our non-tested analysis was that null default routes 
> and loose RPF 
> were compatible, but I wouldn't depend on that.
> 
> > As far as I can gather from the juniper.net/techpubs is 
> this: "Loose 
> > mode-All packets are automatically accepted. For this reason, we 
> > recommend that you not configure unicast RPF loose mode on 
> interfaces 
> > that the default route uses."
> 
> Right, but this doesn't really answer the question of these 
> typically necessary "null default routes"..
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net 
> http://puck.nether.net/mailman/listinfo/junipe> r-nsp
>