[Babel-users] [RFC] Replace WireGuard AllowedIPs with IP route attribute

[Daniel Gröber]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20231122/c2c26550/attachment.sig>