Google today announced that the PSP (short for PSP Security Protocol) protocol is open source. The protocol, designed to handle datacenter-scale offloading of cryptographic hardware, is currently deployed in production at Google.
To better protect user privacy, Google encrypted traffic between data centers more than a decade ago. In subsequent developments, nearly all data transmitted by Google is encrypted. While this work provides valuable privacy and security benefits, software encryption comes at a huge price: encrypting and decrypting RPCs requires about 0.7% of Google’s processing power and a corresponding amount of memory.
These costs prompted Google to use PSP (short for PSP Security Protocol) to offload encryption onto network interface cards (NICs). The so-called Offload is to put some data packet processing (such as TCP segmentation, IP segmentation, reassembly, checksum, TCP protocol processing, etc.) originally performed by the operating system into the network card hardware to reduce the system CPU consumption and improve the performance. processing performance.
In view of the fact that TLS is not friendly enough, lacks support for UDP, and also has some defects in IPsec, Google independently developed its own Offload friendly protocol. PSP is described as their solution as a TLS-like, transport-independent protocol for per-connection security and Offload friendliness.
For the PSP, explains Amin Vahdat from the Google Cloud team
The PSP is designed to meet the requirements of large-scale data center traffic. It does not mandate a specific key exchange protocol and provides few options for packet formats and encryption algorithms. It provides per-connection security by allowing each layer 4 connection (eg, a TCP connection) to use an encryption key.
It supports stateless operation because the encryption state can be passed to the device through the packet descriptor when transmitting the packet, and the packet can be received using the Security Parameter Index (SPI) and the master key on the device. This allows us to maintain a minimal state in hardware, avoiding hardware state explosion compared to typical state encryption techniques that maintain large device tables.
The PSP uses User Datagram Protocol (UDP) encapsulation with custom headers and trailers. A PSP packet begins with a raw IP header, followed by a UDP header on the pre-specified destination port, followed by a PSP header containing PSP information, then a raw TCP/UDP packet (including header and payload), and ends with a PSP trailer for Integrity Checksum Value (ICV).
Layer 4 packets (header and payload) can be encrypted or authenticated based on a user-supplied offset called Crypt Offset. For example, this field can be used to keep parts of the TCP header authenticated but not encrypted in transit while keeping the rest of the packet encrypted to support packet sampling and inspection (if necessary) in the network.
Google patched the PSP into their production Linux kernel, their Andromeda network virtualization stack, and their Snap networking system. PSP encryption offloading reportedly saves about 0.5% of Google’s overall processing power. Today, they open source the PSP security protocol to encourage further adoption. They have published their architectural specification, reference software implementation and a set of test cases.