nanog mailing list archives

Re: Partial vs Full tables


From: Brian Johnson <brian.johnson () netgeek us>
Date: Wed, 10 Jun 2020 13:20:15 -0500

Disagree with Bill here. It will depend on the complexity of the network as to use of uRPF in any mode (loose or 
strict). In general, I never use uRPF on transit links and use pure filters to ensure accurate filters are in place. 
uRPF may be used internally in either mode to great advantage and I’ve done it both ways.

If you are looking for corner cases, avoid networking. I do not know of a protocol or a technique that I cannot find a 
corner case for.

- Brian

On Jun 10, 2020, at 12:31 PM, William Herrin <bill () herrin us> wrote:

On Wed, Jun 10, 2020 at 9:43 AM William Herrin <bill () herrin us> wrote:
The answer is "no," you're not running reverse-path filtering on a BGP
speaker, not even in loose mode, because that's STUPID.

Sorry, it'd be pre-coffee if I drank coffee and I was overly harsh
here. Let me back up:

The most basic spoofing protection is: don't accept remote packets
pretending to be from my IP address.

Strict mode URPF extends this to networks: don't accept packets on
interfaces where I know for sure the source host isn't in that
direction. It works fine in network segments whose structure requires
routes to be perfectly symmetrical: on every interface, the packet for
every source can only have been from one particular next hop, the same
one that advertises acceptance of packets with that destination. The
use of BGP breaks the symmetry requirement so close to always that you
may as well think of it as always. Even with a single transit or a
partial table. Don't use strict mode URPF on BGP speakers.

Loose mode URPF is... broken. It was a valiant attempt to extend
reverse path filtering into networks with asymmetry but I've yet to
discover a use where there wasn't some faulty corner case. If you
think you want to use loose mode RPF, trust me: you've already passed
the point where any RPF was going to be helpful to you. Time to set it
aside and solve the problem a different way.

Regards,
Bill Herrin

-- 
William Herrin
bill () herrin us
https://bill.herrin.us/


Current thread: