> 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
