Partial vs Full tables

Wed Jun 10 18:20:15 UTC 2020

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 at herrin.us> wrote:
> 
> On Wed, Jun 10, 2020 at 9:43 AM William Herrin <bill at 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 at herrin.us
> https://bill.herrin.us/