Though the docs aren't indexed in the web search tool yet, JUNOS 5.5 adds the ability to perform loose uRPF now. [edit int <name> unit 0 family inet] set rpf-check mode loose Watch for wrapping. http://www.juniper.net/techpubs/software/junos/junos55/swconfig55-interf aces/download/swconfig55-interfaces.pdf Cheers, -- steve Date: Tue, 8 Oct 2002 12:29:48 -0400 From: Jared Mauch <jared@puck.Nether.net> Subject: Re: Who does source address validation? (was Re: what's that smell?) On Tue, Oct 08, 2002 at 10:15:28AM -0600, Danny McPherson wrote:

...

"reachable-via any" means you're only going to drop the packet if

you

...

don't have *ANY* route back to them.

What's a route? An IP RIB instance? A BGP Loc-RIB instance? An IGP LSDB IP prefix entry? A BGP Adj-RIB-In instance?

I think you mean "if you don't have *ANY* **FIB** entry for the source address".

If I peer with two large providers on the same router and both have prefix D.1 behind them and advertise the prefix to me, it's likely that only one of those two paths is going to make it into the BGP Loc-RIB (and subsequently, the IP RIB then FIB).

If I use ANY FIB entry as proof that it's a valid source then that only addresses RFC1918ish space and only suggest that I first need to generate an invalid BGP route for the prefix, then spoof the packets. This doesn't fix spoofing with global IP addresses.

If I use only entries that occur in the RIB and associate them with the receiving interface and receive a packet with an SA of D.1 from the peer whose path wasn't installed in the BGP Loc-RIB then I'll drop it. (And there's nothing broken with this configuration -- it's why we have routers with 1 million BGP paths but only 150K routes/fib entries, as I'm sure you know).

If you're going to do source address validation then you need to associated all potential valid paths for a given prefix with the associated ingress interface, else it's mostly useless.

Yes, but if i continue in my ideal situation of people (mostly) filter their bgp customers, so they won't announce the 1918 space, or similar. even the large peers filter out each other so they don't pick up 1918 announcements. Plus people use Robs "Secure IOS Template" to drop extraneous bgp announcements for unregistered/unassigned space (from IANA). I'm not purporting this as a solution to all problems on the internet, but if one walks before one runs this is a reasonable step in the correct direction. Or at least a nice bandaid (duct tape?) to help keep the network in a bit more sensible shape. And if everyone did it, it would help with the orignal problem/statistics posted about how much 1918 space was hitting one specific root server. I am interested in hearing other solutions to the problem including extra validations such as the above, but those aren't avalable today and what i'm suggesting is in the 12.0S and 12.1E IOS images and probally others. - Jared - -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.