Google announced the opening of specifications and a reference implementation of the PSP (PSP Security Protocol), which is used for encrypting traffic between data centers. The protocol employs an architecture similar to IPsec ESP (Encapsulating Security Payloads) for traffic encapsulation over IP, providing encryption, cryptographic integrity checking, and source authentication. The PSP implementation code is written in C and is distributed under the Apache 2.0 license.
A key feature of PSP is the optimization of the protocol to accelerate computations and reduce the load on the central processor by offloading encryption and decryption operations to network cards. Hardware acceleration requires compatible network cards that support PSP. For systems with network cards that do not support PSP, a software implementation called SoftPSP is available.
UDP is used as the transport protocol for data transmission. A PSP packet starts with an IP header, followed by a UDP header, and then the PSP header containing encryption and authentication information. The contents of the original TCP/UDP packet are then attached, concluding with a final PSP block that includes a checksum to confirm integrity. Both the PSP header and the header and data of the encapsulated packet are always authenticated to verify the authenticity of the packet. The data within the encapsulated packet can be encrypted, allowing for selective encryption where part of the TCP header remains unencrypted (while maintaining authenticity control), for example, to enable packet inspection on transit network equipment.
PSP is not tied to any specific key exchange protocol, offering several options for packet formats and supporting the use of different cryptographic algorithms. For instance, support for the AES-GCM algorithm is provided for encryption and authentication, and AES-GMAC for authenticity verification without encrypting the actual data, such as when the data is not valuable but there is a need to ensure that it has not been tampered with during transmission and is indeed the original data sent.
Unlike typical VPN-In PSP protocols, encryption is applied at the level of individual network connections rather than the entire communication channel, meaning that PSP uses separate encryption keys for different tunneled UDP and TCP connections. This approach enables stricter traffic isolation from various applications and handlers, which is relevant when running on a single server application and services for different users.
In Google, the PSP protocol is used both to protect its own internal communications and to secure the traffic of Google Cloud customers. The protocol was initially designed for efficient operation within Google-level infrastructures and should provide hardware acceleration for encryption in the presence of millions of active network connections and the establishment of hundreds of thousands of new connections per second.
Two operational modes are supported — 'stateful' and 'stateless.' In 'stateless' mode, the keys for encryption are transmitted to the network card in the packet descriptor, and for decryption, they are extracted from the fields present in the packet's SPI (Security Parameter Index) using a master key (256-bit AES, stored in the memory of the network card and replaced every 24 hours), which helps save memory on the network card and minimize the information about the state of encrypted connections stored on the equipment side. In 'stateful' mode, keys for each connection are stored on the network card in a special table, similar to how hardware acceleration is implemented in IPsec.
PSP provides a unique combination of the capabilities of TLS and IPsec/VPN protocols. TLS was suitable for Google in terms of protection at the level of individual connections but was lacking due to insufficient flexibility for hardware acceleration and lack of UDP support. IPsec ensured independence from protocols and well-supported hardware acceleration but did not allow key binding to individual connections, was designed for only a small number of created tunnels, and faced hardware acceleration scaling issues due to storing the full state of encryption in tables located in the memory of the network card (for instance, processing 10 million connections requires 5 GB of memory).
In the case of PSP, information about the encryption status (keys, initialization vectors, sequence numbers, etc.) may be transmitted in the TX descriptor of the packet or as a pointer to the host system's memory, without occupying the network card's memory. According to Google, previously, encryption of RPC traffic in the company’s infrastructure consumed about 0.7% of computational power and a large amount of memory. The implementation of PSP, through the use of hardware acceleration, has reduced this figure to 0.2%.
Source: opennet.ru
