Re: per-FIB socket binding

From: <paul_at_redbarn.org>
Date: Mon, 30 Dec 2024 17:29:11 UTC
Julian <<UDP is another question. You would need to allow the receiving socket 

to report the FIB (do I already?) of the receiving interface and use 

it for the response.>> 


For UDP one must already scan the interface list both initially and periodically to find possible source addresses and bind a socket to each. This is what makes it possible to answer a DNS request from the source address if the request's destination address. 


While it would be simple to retrieve the FIB of each interface during the scan and apply that to all sockets bind to addresses on that interface, I think it would be even better to make bind() set the socket's FIB to the FIB of the interface that socket is binding to. For both TCP, UDP, and even sctp. 


Julian, if not this, then what use cases were you acting from when giving interfaces a FIB in the first place? 


Vixie 


Sent from Workspace ONE Boxer 


On Dec 30, 2024 08:06, Julian Elischer <julian@freebsd.org> wrote:

On 12/24/24 1:06 PM, Jamie Landeg-Jones wrote: 
> Paul Vixie <paul@redbarn.org> wrote: 
> 
>> i've been thinking along these lines for a few years now, since my vm server is multi-fib. 
>> each interface has a fib, mostly zero. for incoming TCP SYNs, i'd like to carry that fib# into 
>> the resulting PCB so that that fib's routing table and especially its default route will be 
>> used for that connection. yes, i can do that with ipfw, and am in fact doing so now. 
>> however, that's crocky. i think defaulting to the interface FIB for connections created and 
>> maintained by the kernel should always happen -- not opt-in, not opt-out, just always. is 
>> it worth me sending a patch that does this or would it be considered controversial? 
> 
> I like that. I isolate 5 seperate networks by assigning a fib to each interface, and was 
> initially surprised that I had to jump through ipfw hoops to get it to work properly, in 
> fact at the end of my ipfw rules for these interfaces, just to guarantee no leaking, 
> I have this, out of kludgy desperation! : 
> 
> 05111 deny log ip from any to any fib 1 not via em1 
> 05112 deny log ip from any to any fib 2 not via em2 
> 05113 deny log ip from any to any fib 3 not via em3 
> 05114 deny log ip from any to any fib 4 not via em4 
> 05115 deny log ip from any to any fib 5 not via em5 
> 
> So, yes, I agree that it's crocky, and your proposal is how I originally expected it to 
> work, and indeed, I can so no reason for it not to work that way, but am prepared to 
> be enlightened if anyone else has an opinion on this. 
> 

I think I made it not act that way by default when I added fibs was to 
keep compatibility with old code.  You could add a sysctl that makes 
it default behaviour or not.  I think the suggested patch is probably 
the right way to go.. for TCP  anyhow, 

UDP is another question. You would need to allow the receiving socket 
to report the FIB (do I already?) of the receiving interface and use 
it for the response. 




> Jamie 
>