Re: [RFC net-next 00/15] add basic PSP encryption for TCP connections

[Jakub Kicinski <kuba@kernel.org>]

On Wed, 29 May 2024 22:01:52 +0200 Boris Pismenny wrote:
> > The drivers should only decap for known L4 protos, I think that's
> > the only catch when we add tunnel support. Otherwise it should be
> > fairly straightforward. Open a UDP socket in the kernel. Get a key
> > + SPI using existing ops. Demux within the UDP socket using SPI.
> 
> IIUC, you refer to tunnel mode as if it offloads
> encryption alone while keeping headers intact. But,
> what I had in mind is a fully offloaded tunnel.
> This is called packet offload mode in IPsec,
> and with encryption such offloads rely on TC.

Do you see any challenge?

> > Depends on the deployment and security model, really, but I'd
> > expect the device key is shared, hypervisor is responsible for
> > rotations, and mediates all key ops from the guests.
> 
> I can imagine how this will work, but there are a few issues:
> - Guests may run out of Tx keys, but they can't initiate key
> rotation without affecting others. This fate sharing between
> VMs seems undesirable.
> - Unclear what sort of mediation is the hypervisor expected
> to provide: on the one hand, block a key rotation request and
> the requesting guest is denied service, on the other hand,
> allow key rotation and a guest may spam these requests to
> the hypervisor, which will also spam other VMs with
> notifications of key rotation.

I don't have much experience working with VMs, or a good understanding
of what mlx5 does internally. Without access to the details of even a
single device which does PSP - any comment I'd make would be too much
of a speculation for my taste :(

On the NFP I'm pretty sure we could have given every VM a separate
device key, no problem.