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-interfaces/download/swconfig55-interfaces.pdf
Cheers,
--
steve
Date:
Tue,
8 Oct 2002 12:29:48
-0400
From:
Jared Mauch
<[email protected]>
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
[email protected]
clue++; | http://puck.nether.net/~jared/ My statements are only mine.