Partial vs Full tables

Thu Jun 11 13:25:14 UTC 2020

> On Jun 10, 2020, at 3:05 PM, William Herrin <bill at herrin.us> wrote:
> 
> On Wed, Jun 10, 2020 at 11:20 AM Brian Johnson <brian.johnson at netgeek.us> wrote:
>> 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.
> 
> 
> Hi Brian,
> 
> Do you know and understand what you broke? It's one thing to make a
> judgement call. Quite another to wave your hands and say, "Oh well,
> nobody complained so it must be OK."
> 

Hi Bill,

I fully understand that I have not “broken” anything. If I run uRPF in loose mode on my internal links, I will not forward packets from a source that doesn’t exist in my routing tables to the rest of the internet. Just say thank you and we can stop this silliness.

> 
>> 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.
> 
> Not sure what you're saying here. Corner cases aren't a bad thing.
> They're just the point where a technology or technique is most likely
> to break. If you want reliability, you're supposed to identify the
> corner cases and then you're supposed to game out what happens in
> those corner cases. A result will be acceptable or unacceptable and if
> it's unacceptable you don't do that. If you haven't identified and
> gamed the corner cases then (A) you can't prove your stuff is reliable
> and (B) it probably isn't.

Actually corner cases are the exception to any rule. You will never solve for all of the corner cases unless you have dictatorial control of the entire system. I can only control what I send. I can say that sending packets from unknown sources from a network I do control is a no-no, ICMP response or not.

> With RPF, the corner cases you're looking for are: what situations
> would cause a packet to come from the wrong interface? For example, if
> you had some sort of routing loop where router A thought it could get
> to a destination via router B but router B thinks that destination
> unreachable so it returns the packet to its default route at router A.
> RPF then drops the packet because router B isn't an acceptable source.
> That's a corner case for RPF but it's an acceptable case because the
> packet would be dropped regardless.

So a non-problem corner-case. Interesting... I never thought of a non-problem as a problem.

> Another corner case with strict RPF is that your best route to a
> destination is transit C but a packet with that source arrives from
> transit D. That's broken, it causes significant problems for the
> network and as a result it constrains you to not use strict RPF in
> network scenarios where that's possible.

See my original response where I say not to use it in that scenario.

> Loose mode RPF tries to overcome the limitation by saying: as long as
> there's a route announced from D we'll accept packets from D even if C
> is the best route.

Saying that a route to the source has to be in the routing table on an internal network, something I can control, is a valid way to stop spoofing. uRPF cannot, and should never be used to, make routing decisions and does not do that anyway.

The rest of your comments are not reasonable since I already said to not use uRPF on TRANSIT LINKS. Happy to expand that to PEERING LINKS. For internal networking, you CAN use uRPF to great effect, corner case arguments notwithstanding.

Not everyone runs a large multi-national tier-1/2 network. Some of us run the thousands of eye-ball networks and just say thank you when we don’t allow spoofing.

BTW... RPF and uRPF are significantly different things. :)

<SNIP>

> 
> Regards,
> Bill Herrin
> 
> -- 
> William Herrin
> bill at herrin.us
> https://bill.herrin.us/