Hi Alexander, On Wed, Nov 22, 2023 at 12:17:49AM +0100, Alexander Zubkov wrote:
Can you think of a use-case where fpRPF isn't enough?
Yes. IMHO, the problem with RPF is that routing table doesn't reflect the network topology, but only a subset of it.
Right that is the fundamental problem, so my solution to that is: routing should "just represent the full network topology" :) As the routing protocol sees it anyway, since the whole point of RFP is to only allow paths that the routing system chooses. Do note that while I implement the topology information using ECMP routes there's no reason you actually have to use ECMP. You could still have regular routes in your (main) routing table and use a separate table with ECMP routes for RPF and this is very much something I want us to support.
I mean in topologies where multiple pathes are possible, you can choose to use or even learn only a subset of those pathes.
If I undestand correctly you're talking about (local) routing daemon policy here. Yes this is something you can do and my current approach of (abusing) ECMP only works when your routing policy satisfies some symmetry criteria. However as Juliusz pointed out integrating this idea into the routing protocol proper could allow using arbitrary policy without ever breaking RPF, but figuring out the details is (exciting) future work.
In that sense might be yes, the original sin is that the routing table doesn't reflect all the topology, not only the pathes we choose for egress. Not sure though if it is a sin, in that case routing table would be too overcomplicated.
Right routing table (modification) performance and clutter is certainly a reason to forgoe this approach but I find that for the kind of (small) networks I want to run and that many people might run using wireguard this is perfectly fine.
If I understand correctly, such fpRPF approach works only if you both learn all possible pathes and use all of them in a multi-nexthop route. But for example in the Internet with its advanced BGP announcement policies it is not true at all.
Right to deply fpRPF on a large scale you really need some kind of support from the routing protocol. AFAIK there's nothing like that for BGP yet? I don't think it's completely inapplicable either though, might still work for iBGP with appropriately designed routing policy. My interest lies mostly with doing this using babel though.
So from my point of view it is good to split the topology definition (ingress decapsulation) and the chosen pathes (egress routing). Because it is related, but still different processes. So the system can be more flexible. Although we need to repeat common things and keep ingress and egress consistent/synced.
To me flexibility is only desirable insofar as it doesn't conflict with system security. Source address authenticity is an important property I wouldn't want to give up here. If it's easier to ignore source address filtering than it is to implement it nobody is going to do it (cf. the internet) and I think that's the crux of the problem with "encap". Wireguard gifted us this amazing state of source filtering being the easy default and I want to keep it that way.
my point is that RPF (with its variations too) has its bounds and cannot be a universal solution, there is no silver bullet here.
No, ofc. nothing we do can possibly "fix everything for everyone" but that's no reason not to try a new approach for a particular problem in a particular use-case :) --Daniel