From nobody Tue Dec 17 18:15:07 2024 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 4YCQ2m1fp0z5hXN4 for ; Tue, 17 Dec 2024 18:15:12 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YCQ2l3s7tz4LWR for ; Tue, 17 Dec 2024 18:15:11 +0000 (UTC) (envelope-from markjdb@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=NRTFjmN8; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::d2e as permitted sender) smtp.mailfrom=markjdb@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=freebsd.org (policy=none) Received: by mail-io1-xd2e.google.com with SMTP id ca18e2360f4ac-844e7409f8aso180006139f.1 for ; Tue, 17 Dec 2024 10:15:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734459310; x=1735064110; darn=freebsd.org; h=content-disposition:mime-version:message-id:subject:to:from:date :sender:from:to:cc:subject:date:message-id:reply-to; bh=plsQj8/no2QgMmjHbYMoPsX4V8KfwyovnMwS0taJccs=; b=NRTFjmN8D7G6jMzRK8vR+oBG3RCA3rv+5bqtgqJurh9lqlTCmF8IzZBVjM0nMYZbaE rxbWhiImFGt14FTaSsTnqPy/6G2+ZbLLlS0aW27R2pOzQJUQhvOvzX19FapJG0OqyLE6 cyE8dmfoLPocuP5d4ZeRrkejSSQatZxT+Eov+vWqrlL1JEtBcN83MLtL81gbkxJ23q5c GqFgmHICGX+/rXfxToAY9pAxUDAAknkZvd/Q8YoPB2kuM/GipBJ+8Fc3ZYa+l5tNZOFa Q/FL7c5GtktR54OGch9slGEaAFFWo1i5OlvTG61yDfy7Wu3jkXPrfLcepUMPLxF5iwtF 1UnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734459310; x=1735064110; h=content-disposition:mime-version:message-id:subject:to:from:date :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=plsQj8/no2QgMmjHbYMoPsX4V8KfwyovnMwS0taJccs=; b=ojUgkAL0BFfNWwwDtLa09PhBdRTr4kE5UlO99wY6Qiyh3VUuATRvm0d54ufHjDpKRb EmntrktYAygcdEZbsu4/7XWIwPyk6XeFYMwq+jNWzv4M8hZDB1PqYrU4WdKHQ4CqTOZR 0svMDZkOX82C/Gt2cQGsElQQLCY7EQ3jFNc9OXWVCAwPx81Zlhgf4v0tZZiJbaF/YRPo q+suKjX7LUpHmsMerWlX7wBq5hFa7E6k0lCfGwnK5D6DGVFDN6RrdrbNVwwdU9gqP8iH TSuLU8Vsze+m7KDGpVpO3NpKpQ2RwXT9knEsMxi/mGSbhOoOg5X8QTMtkmB0wn7fon0+ 8c8w== X-Gm-Message-State: AOJu0Yy7IrZdnj3VCFgeey6r+2AQg5bU2R5AIzVC/WeSPRGvkFFRaqiZ 8SAP/ABzOLvyhDQGUnoS8asAGYcEfe+vBaYsFVTeX2pVAvueZNaQzj0AKw== X-Gm-Gg: ASbGnctSY4gGxPr8sSWI87BBdRL7Y/ZKA5ewmmngyTp8ngiMtZJ8L9dzXWpOqLsz09q 71vAxD5kTiD+gnWZXA51cNdWbuLIJyydHAxRcJiMqcNfqdqcr1fj6+PiTW1ZDy4R2FfxDSFnobx fH5eEhnZPPWEeXzMeQJMTrM+GHqPFvRT2rg1weLzml/xNsBmjT0tC0/fX47rfXBOg8nKNqMiYHG oaxw6/RV3q0GHG+Nb9AZ9ZdnZVGC7DAiuhSe9R3gpHIw8Hl5U9NlxMPPDwHHCB5lwhOj8o= X-Google-Smtp-Source: AGHT+IE7T9wf2/FG8rgjNUodMeceZE9H2EoBs1vs14AbclsZ9m3CVgSnFDCJkCI8GTAIFwm+BXydlA== X-Received: by 2002:a05:6602:3429:b0:843:ea9a:acc4 with SMTP id ca18e2360f4ac-844e8b35d80mr1712500939f.8.1734459310025; Tue, 17 Dec 2024 10:15:10 -0800 (PST) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id 8926c6da1cb9f-4e5e32a341esm1829941173.103.2024.12.17.10.15.09 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Dec 2024 10:15:09 -0800 (PST) Date: Tue, 17 Dec 2024 13:15:07 -0500 From: Mark Johnston To: freebsd-net@freebsd.org Subject: per-FIB socket binding Message-ID: 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-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spamd-Result: default: False [-2.60 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MID_RHS_NOT_FQDN(0.50)[]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), DKIM not aligned (relaxed),none]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MISSING_XM_UA(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; TO_DOM_EQ_FROM_DOM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d2e:from] X-Rspamd-Queue-Id: 4YCQ2l3s7tz4LWR X-Spamd-Bar: -- Lately I've been working on adding FIB awareness to bind(2) and inpcb lookup. Below I'll describe the project a bit. Any feedback/comments/suggestions would be appreciated. Today, a TCP or UDP socket can receive connections or datagrams from any FIB. Suppose a SYN arrives on an interface in FIB 1. A TCP listening socket attached to FIB 0 may receive the SYN and create a new connection; the FIB of the new socket is inherited from the listening socket, so the new connection will also belong to FIB 0 even though the SYN was associated with FIB 1. As long as FIB 0 has a route to the SYN's source address, the connection will work. For some applications, one may prefer to ensure that the connection is associated with the FIB of the incoming SYN; if no socket is listening in that FIB, the connection would be dropped. We could have a mode where accept() puts the new socket in the FIB of the incoming SYN, rather than that of the listening socket, but that doesn't help for connectionless sockets. This is useful if one has a service with per-FIB configurations and wants to run multiple instances without having to specify non-overlapping addresses for them to listen on. Or, if one wants to run a service only in a specific FIB for whatever reason. To implement this, I propose having per-VNET tunables for TCP, UDP and raw sockets, with the following effects: - Multiple sockets can bind to the same addr/port (INADDR_ANY in particular), so long as they belong to different FIBs and all are owned by the same user. - SO_REUSEPORT and SO_REUSEPORT_LB can still be used to share a port among sockets in the same FIB. - When in_pcblookup() goes off to find an inpcb to handle a received packet, only inpcbs belonging to the same FIB as the packet will be returned. If no such inpcb exists, the packet is dropped, even if an inpcb in a different FIB could handle the packet. This would be opt-in behaviour since it can easily break existing applications. In particular, it'd be easy to lock oneself out of a system if, say, one relies on being able to ssh in from a non-default FIB. That said, I do think these semantics are a bit more intuitive than the default ones. I've implemented most of this locally; I'm still working on documentation and test cases, so haven't posted patches for review yet, aside from some preparatory cleanup and bind(2) test cases. I aim to have things in review sometime in January. Any thoughts/comments?