From: Steffen Klassert <steffen.klassert@secunet.com>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: Paul Wouters <paul@nohats.ca>, Jakub Kicinski <kuba@kernel.org>,
<netdev@vger.kernel.org>, <pabeni@redhat.com>,
<borisp@nvidia.com>, <gal@nvidia.com>, <cratiu@nvidia.com>,
<rrameshbabu@nvidia.com>, <tariqt@nvidia.com>
Subject: Re: [RFC net-next 00/15] add basic PSP encryption for TCP connections
Date: Fri, 31 May 2024 08:09:04 +0200 [thread overview]
Message-ID: <ZllpgEvQ4QnfP3m7@gauss3.secunet.de> (raw)
In-Reply-To: <6655e0eecb33a_29176f29427@willemb.c.googlers.com.notmuch>
On Tue, May 28, 2024 at 09:49:34AM -0400, Willem de Bruijn wrote:
> Steffen Klassert wrote:
> > On Wed, May 22, 2024 at 08:56:02AM -0400, Paul Wouters wrote:
> > > Jakub Kicinski wrote:
> > >
> > > > 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.
> > >
> > > Speaking as an IETF contributor, I am little surprised here. I know
> > > the google people reached out at IETF and were told their stuff is
> > > so similar to IPsec, maybe they should talk to the IPsecME Working
> > > Group. There, I believe Steffen Klassert started working on supporting
> > > the PSP features requested using updates to the ESP/WESP IPsec protocol,
> > > such as support for encryption offset to reveal protocol/ports for
> > > routing encrypted traffic.
> >
> > This was somewhat semipublic information, so I did not talk about
> > it on the lists yet. Today we published the draft, it can be found here:
> >
> > https://datatracker.ietf.org/doc/draft-klassert-ipsecme-wespv2/
> >
> > Please note that the packet format specification is portable to other
> > protocol use cases, such as PSP. It uses IKEv2 as a negotiation
> > protocol and does not define any key derivation etc. as PSP does.
> > But it can be also used with other protocols for key negotiation
> > and key derivation.
>
> Very nice. Thanks for posting, Steffen.
>
> One point about why PSP is that the exact protocol and packet format
> is already in use and supported by hardware.
>
> 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.
Sure, PSP is already implemented in hardware and needs to be supported.
I don't want to judge if it was a good idea to start this without
talking to the IETF, but maybe now Google can join the effort at the
IETF do standardize a modern encryption protocol that meets all the
requirements we have these days. This will be likely on the agenda of
the next IETF IPsecME working group meeting, so would be nice to
see somebody from the Google 'PSP team' there.
next prev parent reply other threads:[~2024-05-31 6:09 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-22 12:56 [RFC net-next 00/15] add basic PSP encryption for TCP connections Paul Wouters
2024-05-22 13:03 ` Boris Pismenny
2024-05-28 9:42 ` Steffen Klassert
2024-05-28 13:49 ` Willem de Bruijn
2024-05-28 15:33 ` Paul Wouters
2024-05-28 18:09 ` Jakub Kicinski
2024-05-28 18:11 ` Willem de Bruijn
2024-05-31 6:09 ` Steffen Klassert [this message]
2024-05-31 14:46 ` Willem de Bruijn
-- strict thread matches above, loose matches on Subject: below --
2024-06-18 23:54 Singhai, Anjali
2024-06-19 8:39 ` Willem de Bruijn
2024-06-19 8:47 ` Willem de Bruijn
2024-06-20 21:32 ` Singhai, Anjali
2024-06-21 12:05 ` Willem de Bruijn
2024-06-22 0:30 ` Jakub Kicinski
2024-06-25 22:05 ` Singhai, Anjali
2024-06-25 23:17 ` Jakub Kicinski
2024-05-10 3:04 Jakub Kicinski
2024-05-29 9:16 ` Boris Pismenny
2024-05-29 18:50 ` Jakub Kicinski
2024-05-29 20:01 ` Boris Pismenny
2024-05-29 20:38 ` Jakub Kicinski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZllpgEvQ4QnfP3m7@gauss3.secunet.de \
--to=steffen.klassert@secunet.com \
--cc=borisp@nvidia.com \
--cc=cratiu@nvidia.com \
--cc=gal@nvidia.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=paul@nohats.ca \
--cc=rrameshbabu@nvidia.com \
--cc=tariqt@nvidia.com \
--cc=willemdebruijn.kernel@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).