[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3da2a55d-bb82-47ff-b798-ca28bafd7a7d@nvidia.com>
Date: Wed, 29 May 2024 11:16:12 +0200
From: Boris Pismenny <borisp@...dia.com>
To: Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org
Cc: pabeni@...hat.com, willemdebruijn.kernel@...il.com, gal@...dia.com,
cratiu@...dia.com, rrameshbabu@...dia.com, steffen.klassert@...unet.com,
tariqt@...dia.com, jgg@...dia.com
Subject: Re: [RFC net-next 00/15] add basic PSP encryption for TCP connections
On 10.05.2024 05:04, Jakub Kicinski wrote:
> External email: Use caution opening links or attachments
>
>
> Hi!
>
> Add support for PSP encryption of TCP connections.
>
> PSP is a protocol out of Google:
> https://github.com/google/psp/blob/main/doc/PSP_Arch_Spec.pdf
> which shares some similarities with IPsec. I added some more info
> in the first patch so I'll keep it short here.
>
> The protocol can work in multiple modes including tunneling.
> But I'm mostly interested in using it as TLS replacement because
> of its superior offload characteristics.
Hi!
Thank you for doing this. I agree that TLS-like socket support
is a main use-case. I'd like to hear what you think on a few
other use-cases that I think should be considered as well
since it may be difficult to add them as an afterthought:
- Tunnel mode. What are your plans for tunnel mode? Clearly it
is different from the current approach in some aspects, for
example, no sockets will be involved.
- RDMA. The ultra ethernet group has mentioned RDMA encryption
using PSP. Do you think that RDMA verbs will support PSP in
a similar manner to sockets? i.e., using netlink to pass
parameters to the device and linking QPs to PSP SAs?
- Virtualization. How does PSP work from a VM? is the key
shared with the hypervisor or is it private per-VM?
and what about containers?
Powered by blists - more mailing lists