[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6655e0eecb33a_29176f29427@willemb.c.googlers.com.notmuch>
Date: Tue, 28 May 2024 09:49:34 -0400
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Steffen Klassert <steffen.klassert@...unet.com>,
Paul Wouters <paul@...ats.ca>
Cc: Jakub Kicinski <kuba@...nel.org>,
netdev@...r.kernel.org,
pabeni@...hat.com,
willemdebruijn.kernel@...il.com,
borisp@...dia.com,
gal@...dia.com,
cratiu@...dia.com,
rrameshbabu@...dia.com,
tariqt@...dia.com
Subject: Re: [RFC net-next 00/15] add basic PSP encryption for TCP connections
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.
Powered by blists - more mailing lists