> > > It was possible to implement BCP38 before the
router
> vendors came up
> > > with uRPF.
> >
> > Further, uRPF is frequently a very inefficient
means of
> implementing
> > BCP 38. Consider that you're going to either
compare the source
> > address against a table of 200,000 routes or
against a handful of
> > prefixes that you've statically configured in an
ACL.
>
> Isn't that only a problem if you want to run a loose
mode uRPF?
> Given that loose mode uRPF isn't very useful in most
places
> where you'd like to do ingress filtering, this doesn't
seem
> like a big issue..
Loose mode is a RTBH Reaction tool - not BCP 38. Don't use a
screw
driver to hammer a nail.
> BTW, I still keep wondering why Cisco hasn't
implemented
> something like Juniper's feasible-path strict uRPF.
Works
> quite well with multihomed and asymmetric routing as
well --
> no need to fiddle with communities, BGP weights etc. to
> ensure symmetry.
Wow - I'm going to need to dust off the tutorial materials
on how uRPF
and using the FIB as a policy enforcement tool works.
Does uRPF need to scan through the entire FIB? Saying this
is saying
routers look through the entire FIB table to find the next
hop? What
ever happened to TRIE techniques? uRPF's look up is at the
same speed as
the forwarding look up. In fact, in many implementations,
the
"forwarding lookup" gets the source and
destination address values from
the FIB.
Now, are there other ways of doing BCP38 - yes lots:
- ACLs
- Radius loaded ACLs
- uRPF Strict-Feasible-VRF modes
- IP Source Verify
- DHCP Lease Query
- NAT on the home CPE
Why hasn't Cisco done uRPF Feasible path? Cause until
recently, our CEF
structures would not allow for feasible/alternate paths. If
the FIB is
your policy table, then _what_ you are limited to the
capabilities of
that FIB when using it to police the packet. Cisco has that
now, so
"feasible path" is just a matter of time to work
through the coding
queues.
What I'm shaking my head over with this whole dialog is the
1990's
thinking. BCP38 is out of date. Anyone who works, mitigates,
analysis,
and studies attack vectors on network systems know that
checking the IP
source address is one of many "Anti-Spoof" checks
you need to do on the
packet. With Ethernet and Cable, you need to do a MAC check.
With all
mediums you need to check the Prec/DSCP value (porn at Prec
6 does
wonders for the routing protocols when there is congestion
in the path).
Then there is TTL values, Fragments, and other values which
need to be
policed on the edge. This is why uRPF - while helpful - is
not the
primary BCP38 tool people should be considering on the edge.
|