> Is tying source address filtering to the routing table the right thing to do
> here? It seems to me that it would cause issues similar to those we see more
> generally with Unicast Reverse Path Filtering
Issues are caused by the kernel performing filtering that the routing
protocol is not aware of: it causes the routing daemon's routing table to
no longer match the effective forwarding table (the kernel's routing
table). That's the reason why uRPF breaks most routing protocols, that's
the reason why we have trouble making Wireguard work with Babel, and also
the reason behind https://github.com/jech/babeld/issues/111.
Contrariwise, we can teach Babel to explicitly take into account the
kernel features that we're interested in using. Thus, Babel could be
aware of the restrictions placed on a wireguard interface, and collaborate
with Wireguard so that the routing table and the forwarding table remain
congruent. I haven't looked at the issue in detail, but I believe that
would be an interesting (short-term) research project, one that I would be
glad to collaborate with (but not necessarily lead, at least not right now).
For the specific case of source address filtering, Babel already has an
(implemented) extension to deal with source addresses, and I encourage you
to consider whether it can be used to deal with the issue at hand. Please
see https://arxiv.org/pdf/1403.0445.pdf and RFC 9079.
-- Juliusz
