From nobody Sat Jan 11 06:25:22 2025 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4YVT6N04TVz5lMYd for ; Sat, 11 Jan 2025 06:25:32 +0000 (UTC) (envelope-from paul@redbarn.org) Received: from util.redbarn.org (util.redbarn.org [IPv6:2001:559:8000:cd::222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "*.redbarn.org", Issuer "RapidSSL TLS RSA CA G1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YVT6L6VDGz4mZr; Sat, 11 Jan 2025 06:25:30 +0000 (UTC) (envelope-from paul@redbarn.org) Authentication-Results: mx1.freebsd.org; dkim=fail ("headers rsa verify failed") header.d=redbarn.org header.s=util header.b=fZCPfNqO; spf=pass (mx1.freebsd.org: domain of paul@redbarn.org designates 2001:559:8000:cd::222 as permitted sender) smtp.mailfrom=paul@redbarn.org; dmarc=pass (policy=reject) header.from=redbarn.org Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "*.redbarn.org", Issuer "RapidSSL TLS RSA CA G1" (not verified)) by util.redbarn.org (Postfix) with ESMTPS id 2988A160C31; Sat, 11 Jan 2025 06:25:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=redbarn.org; s=util; t=1736576725; bh=smf6MFk8SLEuXVLnJg6L0n/LLtqyuTSmKb5AsBauQTg=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=fZCPfNqO58Y+MQZNZRiMuz8wpZMZ5Cy+Q3jXjxFQiEn3hP/nPW0euOfzHprdn6Mdl r0xVblZM85gSaWWEbcpUJZqBGO2XbxPkBOBHqnU26nWCclDXOQpMitROC4c+i/2R9F AILGjD0UXzwaAdPValLDad08xyk/5uf1OlW01eMo= Received: from localhost.localnet (dhcp-159.access.rits.tisf.net [24.104.150.159]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 08798C3F22; Sat, 11 Jan 2025 06:25:25 +0000 (UTC) From: Paul Vixie To: Mark Johnston Cc: freebsd-net@freebsd.org Subject: Re: per-FIB socket binding Date: Sat, 11 Jan 2025 06:25:22 +0000 Message-ID: <3330519.aeNJFYEL58@localhost> Organization: FW In-Reply-To: References: <7772475.EvYhyI6sBW@dhcp-151.access.rits.tisf.net> <38589000.XM6RcZxFsP@dhcp-151.access.rits.tisf.net> List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Rspamd-Queue-Id: 4YVT6L6VDGz4mZr X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MID_RHS_NOT_FQDN(0.50)[]; CTE_CASE(0.50)[]; DMARC_POLICY_ALLOW_WITH_FAILURES(-0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:559:8000::/48]; RCVD_IN_DNSWL_MED(-0.20)[24.104.150.213:received]; MIME_GOOD(-0.10)[text/plain]; R_DKIM_REJECT(0.00)[redbarn.org:s=util]; DMARC_POLICY_ALLOW(0.00)[redbarn.org,reject]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; HAS_ORG_HEADER(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[redbarn.org:-]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:33651, ipnet:2001:559:8000::/48, country:US]; MISSING_XM_UA(0.00)[]; FREEFALL_USER(0.00)[paul]; RCVD_IN_DNSWL_NONE(0.00)[2001:559:8000:cd::222:from] On Monday, January 6, 2025 3:56:55 PM UTC Mark Johnston wrote: > On Fri, Dec 27, 2024 at 08:48:48AM +0000, Paul Vixie wrote: > > ... > I think the patch is probably a good idea, and the trick of only > inheriting the packet's FIB if the socket's is non-zero would avoid > breaking compatibility for most cases. note, i often feel that integers aren't booleans and shouldn't be treated as booleans. however, i can't easily look at x = (y != 0) ? y : z; when i know it could be written instead x = y || z; so if this is forbidden by today's freebsd kernel rules, please educate me. i know that GCC and CLang will optimize down to the same instruction sequence for either, but i prefer the shorter form since in this rare case it is clearer. > One side effect of the patch is that a service listening in FIB 0 that > has no route to the source address of a connection attempt from a > different FIB would previously not accept such a connection, but now it > will. Perhaps that's drastic enough to warrant a sysctl and/or sockopt > to control this behaviour. i hope not. the SYN|ACK will always use the FIB from the interface where the SYN arrived (this is in tcp_syncache.c). if the SYN's source address isn't allowed by uRPF or other checking (in PF or IPFW) this will be determined by the FIB in the SYN's PKTHDR not the one we put into the PCB. whereas if there is some user-mode ACL processing (for example in BIND9's "allow-transfer") there is no way to learn the socket's FIB. i think this excludes the case where we would have rejected a connection if only the interface's FIB had not been stamped onto the PCB. as before please educate me if i'm misunderstanding you, and i apologize in advance for the extra work involved in doing so. > It would be better to pass the fibnum to solisten_clone() and assign it > there. Otherwise, the value of so_fibnum will be wrong for a short > window during which the socket is passed to MAC and other hooks, which > might have some surprising effects. it shall be done. thanks for your review. more reviews would be welcome. i'm working on the bind() case now, so that the socket's FIB if still zero will be made equal to the FIB of the interface where the laddr is found. this still won't handle UDP responses but it will take care of TCP, UDP, and SCTP initiators. and i think i'm going to implement this for SCTP responders even though i can't test it here since it looks simple. (famous last words, i know.) -- Paul Vixie