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

[Willem de Bruijn <willemdebruijn.kernel@gmail.com>]

> > 3. About the PSP and UDP header addition, why is the driver doing it? I guess it's because the SW equivalent for PSP support in the kernel does not exist and just an offload for the device. Again in this case the assumption is either the driver does it or the device will do it.
> > Hope that is irrelevant for the stack. In our case most likely it will be the device doing it.
> > 
> > 4. Why is the driver adding the PSP trailer? Hoping this is between the driver and the device, in our case it's the device that will add the trailer.
> 
> This does not adhere to the spec:
> 
> "An option must be provided that enables upper-level software to send packets that are
> pre-formatted to include the headers required for PSP encapsulation. In this case, the
> NIC will modify the contents of the headers appropriately, apply
> encryption/authentication, and add the PSP trailer to the packet."
> 
> https://raw.githubusercontent.com/google/psp/main/doc/PSP_Arch_Spec.pdf

I responded to the wrong statement. This is in response to point 3.

In general, PSP can work in tunnel and transport mode. In transport
mode, it is here assumed to be not transparent, but under control of
the operating system. That inserts the outer encapsulation headers and
prepares all fields as it sees fit. E.g., using the inner 4-tuple as
entropy for the outer UDP source port, and selecting the right SPI.