Date: Mon, 30 Dec 2024 09:29:11 -0800 From: paul@redbarn.org To: Julian Elischer <julian@freebsd.org>, freebsd-net@freebsd.org Subject: Re: per-FIB socket binding Message-ID: <54249bca-0fdd-49d6-8dab-8d038927930c@redbarn.org> In-Reply-To: <f5509997-d076-4204-8660-71538283a972@freebsd.org> References: <Z2G_q5s35AremgYc@nuc> <4p5o59s4-5p70-0775-1479-990o1s5po7r2@yvfgf.mnoonqbm.arg> <oqn0rr49-1snq-9o09-88p3-ssn063967509@yvfgf.mnoonqbm.arg> <7772475.EvYhyI6sBW@dhcp-151.access.rits.tisf.net> <202412240506.4BO56W2p075824@donotpassgo.dyslexicfish.net> <f5509997-d076-4204-8660-71538283a972@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
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
>
[-- Attachment #2 --]
<html>
<head></head>
<body>
<div dir="ltr">
Julian <<UDP is another question. You would need to allow the receiving socket
</div>
<div dir="ltr">
to report the FIB (do I already?) of the receiving interface and use
</div>
<div dir="ltr">
it for the response.>>
</div><br>
<div dir="ltr">
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.
</div><br>
<div dir="ltr">
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.
</div><br>
<div dir="ltr">
Julian, if not this, then what use cases were you acting from when giving interfaces a FIB in the first place?
</div><br>
<div dir="ltr">
Vixie
</div><br>
<div dir="ltr">
Sent from Workspace ONE Boxer
</div><br>
<div class="bx-html">
<div class="bx-body">
<div class="quote">
On Dec 30, 2024 08:06, Julian Elischer <julian@freebsd.org> wrote:<br type="attribution">
<blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr">On 12/24/24 1:06 PM, Jamie Landeg-Jones wrote: <br>
> Paul Vixie <paul@redbarn.org> wrote: <br>
> <br>
>> i've been thinking along these lines for a few years now, since my vm server is multi-fib. <br>
>> each interface has a fib, mostly zero. for incoming TCP SYNs, i'd like to carry that fib# into <br>
>> the resulting PCB so that that fib's routing table and especially its default route will be <br>
>> used for that connection. yes, i can do that with ipfw, and am in fact doing so now. <br>
>> however, that's crocky. i think defaulting to the interface FIB for connections created and <br>
>> maintained by the kernel should always happen -- not opt-in, not opt-out, just always. is <br>
>> it worth me sending a patch that does this or would it be considered controversial? <br>
> <br>
> I like that. I isolate 5 seperate networks by assigning a fib to each interface, and was <br>
> initially surprised that I had to jump through ipfw hoops to get it to work properly, in <br>
> fact at the end of my ipfw rules for these interfaces, just to guarantee no leaking, <br>
> I have this, out of kludgy desperation! : <br>
> <br>
> 05111 deny log ip from any to any fib 1 not via em1 <br>
> 05112 deny log ip from any to any fib 2 not via em2 <br>
> 05113 deny log ip from any to any fib 3 not via em3 <br>
> 05114 deny log ip from any to any fib 4 not via em4 <br>
> 05115 deny log ip from any to any fib 5 not via em5 <br>
> <br>
> So, yes, I agree that it's crocky, and your proposal is how I originally expected it to <br>
> work, and indeed, I can so no reason for it not to work that way, but am prepared to <br>
> be enlightened if anyone else has an opinion on this. <br>
> <br><br>
I think I made it not act that way by default when I added fibs was to <br>
keep compatibility with old code. You could add a sysctl that makes <br>
it default behaviour or not. I think the suggested patch is probably <br>
the right way to go.. for TCP anyhow, <br><br>
UDP is another question. You would need to allow the receiving socket <br>
to report the FIB (do I already?) of the receiving interface and use <br>
it for the response. <br><br><br><br><br>
> Jamie <br>
> <br><br><br></p>
</blockquote>
</div>
</div>
</div>
</body>
</html>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54249bca-0fdd-49d6-8dab-8d038927930c>