<div dir="auto"><div>Hi Daniel,<br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 20, 2023, 03:05 Daniel Gröber <<a href="mailto:dxld@darkboxed.org">dxld@darkboxed.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Erin, Juliusz,<br>
<br>
On Sat, Nov 18, 2023 at 11:21:57AM +0100, Erin Shepherd wrote:<br>
> On Sat, 18 Nov 2023, at 03:19, Daniel Gröber wrote:<br>
> > That would be a problem as I specifically want to tie the source address<br>
> > filtering to this too. I'll have a look at the internals (if and) when I<br>
> > get around to starting work on this.<br>
> <br>
> Is tying source address filtering to the routing table the right thing to<br>
> do here? It seems to me that it would cause issues similar to those we<br>
> see more generally with Unicast Reverse Path Filtering<br>
<br>
IMO not providing a way to do source address filtering at the routing level<br>
was the original sin :)<br>
<br>
There is certianly the multihoming challange to be overcome as traditional<br>
BCP38 style filtering doesn't cut it in the general case. I have some ideas<br>
on how to deal with this.<br>
<br>
I've done some experiments and found that in Linux multi-nexthop routes<br>
actually match reverse path lookups (using nftables "rt") for _any_ of the<br>
source interfaces involved. I think this can be used to build RFC 3704<br>
style Feasible Path Reverse Path Forwarding when the routing daemon<br>
involved supports ECMP.<br>
<br>
This experiment is what got me interested in having via-wgpeer in the<br>
routing table in the first place, once we have that we can apply the above<br>
idea not just at the interface level but at the wg peer level. Neat.<br>
<br>
Can you think of a use-case where fpRPF isn't enough?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Yes. IMHO, the problem with RPF is that routing table doesn't reflect the network topology, but only a subset of it. I mean in topologies where multiple pathes are possible, you can choose to use or even learn only a subset of those pathes. And that does not mean that there are no other legitimate pathes exist, that other actors may choose to reach you.</div><div dir="auto">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.</div><div dir="auto">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.</div><div dir="auto">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.</div><div dir="auto">At the same time we can use single protocol/configuration as a source of information to setup both of those processes in cases when it is ok to sacrifice flexibility for simplicity. Or for example the ingress part can be configured to use routing table as a source of topology information. Actually, when we turn on the RPF, we do something like that. But my point is that RPF (with its variations too) has its bounds and cannot be a universal solution, there is no silver bullet here.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
It's also noteworthy that once we have this support for via-wgpeer it'd be<br>
possible to apply ip-rule policy to the filtering decision. Perhaps that<br>
gives some additional power for more fun use-cases :)<br>
<br>
On Sat, Nov 18, 2023 at 01:22:03PM +0100, Juliusz Chroboczek wrote:<br>
> Issues are caused by the kernel performing filtering that the routing<br>
> protocol is not aware of: it causes the routing daemon's routing table to<br>
> no longer match the effective forwarding table (the kernel's routing<br>
> table).  That's the reason why uRPF breaks most routing protocols, that's<br>
> the reason why we have trouble making Wireguard work with Babel, and also<br>
> the reason behind <a href="https://github.com/jech/babeld/issues/111" rel="noreferrer noreferrer" target="_blank">https://github.com/jech/babeld/issues/111</a>.<br>
<br>
Right on the money as always. This idea has been on my mind too.<br>
<br>
> Contrariwise, we can teach Babel to explicitly take into account the<br>
> kernel features that we're interested in using.  Thus, Babel could be<br>
> aware of the restrictions placed on a wireguard interface, and collaborate<br>
> with Wireguard so that the routing table and the forwarding table remain<br>
> congruent.  I haven't looked at the issue in detail, but I believe that<br>
> would be an interesting (short-term) research project, one that I would be<br>
> glad to collaborate with (but not necessarily lead, at least not right now).<br>
<br>
Sounds interesting do you have a funding source in mind?<br>
<br>
> For the specific case of source address filtering, Babel already has an<br>
> (implemented) extension to deal with source addresses, and I encourage you<br>
> to consider whether it can be used to deal with the issue at hand.  Please<br>
> see <a href="https://arxiv.org/pdf/1403.0445.pdf" rel="noreferrer noreferrer" target="_blank">https://arxiv.org/pdf/1403.0445.pdf</a> and RFC 9079.<br>
<br>
I don't think I mentioned this to you yet, but I have another one of my<br>
crazy ideas of doing something vaguely similar to BGP flowspec with<br>
babel. Restricted to IP source/destination address, so no L4 stuff. I just<br>
want to represent firewall policy using ipv6 subtrees and distribute it in<br>
realtime using babel :)<br>
<br>
Unfortunately this is currently stalled due to an apparent nft rt match<br>
kernel bug preventing me from representing multiple possible outcomes since<br>
I want to support dropping, accepting but also stateful firewalling of<br>
matching flows.<br>
<br>
--Daniel<br>
</blockquote></div></div></div>