From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=none (p=none dis=none) header.from=gibson.dropbear.id.au Authentication-Results: passt.top; dkim=pass (2048-bit key; secure) header.d=gibson.dropbear.id.au header.i=@gibson.dropbear.id.au header.a=rsa-sha256 header.s=202602 header.b=nbrU9QjG; dkim-atps=neutral Received: from mail.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id 594715A0262 for ; Fri, 06 Mar 2026 02:08:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202602; t=1772759290; bh=e5GP6Y/27eltb97ypUp1tHR3aB2ysW99y3SCtlFqncA=; h=Date:From:To:Subject:From; b=nbrU9QjGfenwNBSGoa379d7u11UJAMNxrNLMa8aJhgV3D8u/9pc6Q5KufK9N1JFP0 k2+XS7cBY2OCZSkTlnJG8wSzVquqq/sjQ/8PSwC58oKMMaaDaAcZyrnXhLJPQsiEa8 cw4iFQYgSqbrIrS26nmqFT7UFTQvtCR/8xz4XXUYpn/ksH+ovPkVDtI1Tb80OCAm5n qykhTFv/AF7w1VIuWJly/w7bWs93HRIZPjXLFZbg3Hsw1idUhXqVNhE5bmmn+8PNTX VXZKE3uDMmpyOlOIljhtL+oE1eFBPhkseNutgEwqlU+udmjdWDfwL6oI+bPglnAOkV zEdahuMJ1JfHA== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4fRpDp61Lvz4wDP; Fri, 06 Mar 2026 12:08:10 +1100 (AEDT) Date: Fri, 6 Mar 2026 12:08:07 +1100 From: David Gibson To: passt-dev@passt.top Subject: Pesto Protocol Proposals, imProved Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5JY69ZWF3tMlel6e" Content-Disposition: inline Message-ID-Hash: QHZWSWI4YHLX5S3P4J5QPOYQQEY4LXXQ X-Message-ID-Hash: QHZWSWI4YHLX5S3P4J5QPOYQQEY4LXXQ X-MailFrom: dgibson@gandalf.ozlabs.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --5JY69ZWF3tMlel6e Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Stefano convinced me that my earlier proposal for the dynamic update protocol was unnecessarily complex. Plus, I saw a much better way of handling socket continuity in the context of a "whole table" replacement. So here's an entirely revised protocol suggestion. # Outline I suggest that each connection to the control socket handles a single transaction. 1. Server hello - Server sends magic number, version - Possibly feature flags / limits (e.g. max number of rules allowed) 2. Client hello - Client sends magic number - Do we need anything else? 3. Server lists pifs - Server sends the number of pifs, their indices and names 4. Server lists rules - Server sends the list of rules, one pif at a time 5. Client gives new rules - Client sends the new list of rules, one pif at a time - Server loads them into the shadow table, and validates (no socket operations) 6. Server acknowledges - Either reports an error and disconnects, or acks waiting for client 7. Client signals apply - Server swaps shadow and active tables, and syncs sockets with new active table 8. Server gives error summary - Server reports bind/listen/whatever errors 9a. Client signals commit - Shadow table (now the old table) discarded or 9b. Client signals rollback - Shadow and active tables swapped back, syncs sockets - Discard shadow table (now the "new" table again) - New bind error report? 10. Server closes control connection # Client disconnects A client disconnect before step (7) is straightforward: discard the shadow table, nothing has changed. A client disconnect between (7) and (9) triggers a rollback, same as (9b). = =20 # Error reporting Error reporting at step (6) is fairly straightforward: we can send an error code and/or an error message. Error reporting at (8) is trickier. As a first cut, we could just report "yes" or "no" - taking into account the FWD_WEAK flag. But the client might be able to make better decisions or at least better messages to the user if we report more detailed information. Exactly how detailed is an open question: number of bind failures? number of failures per rule? specific ports which failed? # Interim steps I propose these steps toward implementing this: i. Merge TCP and UDP rule tables. The protocol above assumes a single rule table per-pif, which I think is an easier model to understand and more extensible for future protocol support. ii. Read-only client. Implement steps (1) to (4). Client can query and list the current rules, but not change them. iii. Rule updates. Implement remaining protocol steps, but with a "close and re-open" approach on the server, so unaltered listening sockets might briefly disappear iv. Socket continuity. Have the socket sync "steal" sockets from the old table in preference to re-opening them. If you have any time to work on (ii) while I work on (i), those should be parallelizable. # Concurrent updates Server guarantees that a single transaction as above is atomic in the sense that nothing else is allowed to change the rules between (4) and (9). The easiest way to do that initially is probably to only allow a single client connection at a time. If there's a reason to, we could alter that so that concurrent connections are allowed, but if another client changed anything after step (4), then we give an error on the next op (or maybe just close the control socket from the server side). # Tweaks / variants - I'm not sure that step (2) is necessary - I'm not certain that step (7) is necessary, although I do kind of prefer the client getting a chance to see a "so far, so good" before any socket operations happen. --=20 David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson --5JY69ZWF3tMlel6e Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmmqKPYACgkQzQJF27ox 2Gck6Q//S08RpotM6PN0jlYJxdccQwum2QSxp+kQn7OMBYVzZHsqc4q6JCoKCHtF OYcvOVgx9wHVdZqal1dSqif1wL3X4r23XC27e+n6XXMaullXM04MTsL35ENP0RtD Q2pUZ9xhrFLpqTwGoc4vFLAL0VIkH5ZajN7WD913MSa5xLrpalVmstlUkzwTR6Ug XrruucCh/0reeibAYKfh986QjmdPG5eLN4aykC6mel7XDnm6jIQi+Nu99FdzAqAg 6nms149wGx7+Iib6j44LtkPp7BXOe+l+WSoad8hwghxbez2hvPjlZEF+Uxvo02u3 0Z0PdTodC4++SYNX+xo8IU8HGj8qJHBe5ceYOlRDVbw+GtaI7WA19vq7KIcy7L0U xE3YGbaL5kIfsf5nFzeyJkZdErLSqE9V66HZYDJEd2zHneVteWd5+sHIgiDRXzrH lAzUQPwlhNKgscVzqcRP8dL/j5a1zNY30Krejyr1czG9QZLiWb4kbzwCVVyJur8v 8t/QqKu2KS+3bAd2VO7AgmZK8+wHsmkdjNZUnGhl4YDv3Hd7Vk9rbo6m+eWLG9d9 bpjXX9SMWAeyeseYjJW3774/+3OOu75xPnw9Wrn5a/x3PO50ReZeeTAWm98vlX1r E+Y1uS6w/uQqFc57olIcYtird2ipFbvTs1jq2Fpvi0NGqWHoR84= =c9XU -----END PGP SIGNATURE----- --5JY69ZWF3tMlel6e--