What's next for the PSP Security Protocol (workshop)#

Chair: Willem de Bruijn

Why: PSP is now in mainline (v6.18), has silicon from Broadcom, Intel and NVIDIA, and became an Open Compute Project v1 spec in June 2026. That combination makes it the most credible datacenter alternative to IPsec for intra- and inter-DC and AI-fabric encryption — and this session is where v2 scope gets set.

What: A panel on where PSP goes next, with the OCP standardization move as the backdrop: v1 is essentially Google's existing spec plus clarifications, v2+ is where feature gaps and new capabilities land.

How: PSP's design points, per the deck: scalable (10M+ flows, 100K+ flow changes/sec; all Rx keys derived from one device key, so O(1) key storage), deliberately minimal (no AH, only AES-GCM/AES-GMAC, no replay protection because L4 already has it), and datacenter-shaped (UDP encapsulation so existing load balancers hash it, plaintext headers so telemetry still works under AEAD, HW-timestamp-derived IV for latency measurement). Candidate v2 work named on the panel slide: multi-user security, cluster-mode key derivation, key exchange, confidential compute, SR-IOV, FIPS 140-3, ChaCha20-Poly1305, optional wire-format fields. Kernel-side work in flight includes netkit and packetdrill support, with packetdrill gaining PSP encap and netlink ops in the .pkt language and a wireserver that does a real key exchange against the stack under test.

Where applicable: Datacenter and cloud-tunnel scenarios with PSP-capable NICs; deployed at scale at Google today. The OCP move is the signal to watch — it's what would make PSP a multi-vendor baseline rather than one operator's protocol.