Hi Erin, Juliusz, On Sat, Nov 18, 2023 at 11:21:57AM +0100, Erin Shepherd wrote: > On Sat, 18 Nov 2023, at 03:19, Daniel Gröber wrote: > > That would be a problem as I specifically want to tie the source address > > filtering to this too. I'll have a look at the internals (if and) when I > > get around to starting work on this. > > 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
IMO not providing a way to do source address filtering at the routing level was the original sin :) There is certianly the multihoming challange to be overcome as traditional BCP38 style filtering doesn't cut it in the general case. I have some ideas on how to deal with this. I've done some experiments and found that in Linux multi-nexthop routes actually match reverse path lookups (using nftables "rt") for _any_ of the source interfaces involved. I think this can be used to build RFC 3704 style Feasible Path Reverse Path Forwarding when the routing daemon involved supports ECMP. This experiment is what got me interested in having via-wgpeer in the routing table in the first place, once we have that we can apply the above idea not just at the interface level but at the wg peer level. Neat. Can you think of a use-case where fpRPF isn't enough? It's also noteworthy that once we have this support for via-wgpeer it'd be possible to apply ip-rule policy to the filtering decision. Perhaps that gives some additional power for more fun use-cases :) On Sat, Nov 18, 2023 at 01:22:03PM +0100, Juliusz Chroboczek wrote: > 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. Right on the money as always. This idea has been on my mind too. > 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). Sounds interesting do you have a funding source in mind? > 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. I don't think I mentioned this to you yet, but I have another one of my crazy ideas of doing something vaguely similar to BGP flowspec with babel. Restricted to IP source/destination address, so no L4 stuff. I just want to represent firewall policy using ipv6 subtrees and distribute it in realtime using babel :) Unfortunately this is currently stalled due to an apparent nft rt match kernel bug preventing me from representing multiple possible outcomes since I want to support dropping, accepting but also stateful firewalling of matching flows. --Daniel
