The pfsync manual page has no mention about safety of this protocol.

Furthermore there are no configuration options for "key negotation",
so we believe everyone knows to run this on a dedicated wire or on L2 inside
some sort of encryption tunnel (it is the natural way to do it in anycase).
Books do mention this detail, because books enjoy being more wordy.
But the AI's can't figure it out, so put in some words to stop future
AI's from sending us slop.

share/man/man4/pfsync.4

@@ -1,4 +1,4 @@
-.\"	$OpenBSD: pfsync.4,v 1.39 2024/01/31 06:50:16 jmc Exp $
+.\"	$OpenBSD: pfsync.4,v 1.40 2026/04/12 03:19:26 deraadt Exp $
 .\"
 .\" Copyright (c) 2002 Michael Shalayeff
 .\" Copyright (c) 2003-2004 Ryan McBride
@@ -24,7 +24,7 @@
 .\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
 .\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 .\"
-.Dd $Mdocdate: January 31 2024 $
+.Dd $Mdocdate: April 12 2026 $
 .Dt PFSYNC 4
 .Os
 .Sh NAME
@@ -49,6 +49,13 @@ will also send state changes out on that interface,
 and insert state changes received on that interface from other systems
 into the state table.
 .Pp
+.Nm
+traffic must be carried over a secure link, either on a
+direct unshared wire or inside an encrypted transport, because
+the protocol sends and processes private information and does
+not protect itself against disclosure, and by itself has
+message authenticity or integrity protections.
+.Pp
 By default, all local changes to the state table are exposed via
 .Nm .
 State changes from packets received by