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

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

Paul Wouters wrote:
> On Tue, 28 May 2024, Willem de Bruijn wrote:
> 
> > One point about why PSP is that the exact protocol and packet format
> > is already in use and supported by hardware.
> 
> Using mostly the IPsec hw code? :)

Not necessarily.

A goal of PSP was to allow an O(1) state device implementation that
does away with the SADB. Using key derivation on Rx and keys in
descriptor on Tx.
 
> > It makes sense to work to get to an IETF standard protocol that
> > captures the same benefits. But that is independent from enabling what
> > is already implemented.
> 
> How many different packet encryption methods should the linux kernel
> have? There are good reasons to go through standard bodies. Doing your
> own thing and then saying "but we did it already" to me does not feel
> like a strong argument. That's how we got wireguard with all of its
> issues of being written for a single use case, and now being unfit for
> generic use cases.
> 
> Going through standards organizations also gains you interoperability
> with non-linux (hardware) vendors, again reducing the number of
> different mostly similar schemes that need to be supported and
> maintained for years or decades.

I don't disagree on the merits of a standards process, of course. It's
just moot at this point wrt PSP. Hardware support and some users are
here. A new packet format cannot be supported retroactively.

That said, an IETF (ESP) protocol is a potential upgrade path even for
existing users in the longer term. If we can make sure that it covers
all the key PSP features.