All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: netdev@vger.kernel.org, pabeni@redhat.com, borisp@nvidia.com,
	gal@nvidia.com, cratiu@nvidia.com, rrameshbabu@nvidia.com,
	steffen.klassert@secunet.com, tariqt@nvidia.com
Subject: Re: [RFC net-next 01/15] psp: add documentation
Date: Thu, 30 May 2024 13:15:10 -0700	[thread overview]
Message-ID: <20240530131510.21243c94@kernel.org> (raw)
In-Reply-To: <20240530125120.24dd7f98@kernel.org>

On Thu, 30 May 2024 12:51:20 -0700 Jakub Kicinski wrote:
> > I've mostly been concerned about the below edge cases.
> > 
> > If both peers are in TCP_ESTABLISHED for the during of the upgrade,
> > and data is aligned on message boundary, things are straightforward.
> > 
> > The retransmit logic is clear, as this is controlled by skb->decrypted
> > on the individual skbs on the retransmit queue.
> > 
> > That also solves another edge case: skb geometry changes on retransmit
> > (due to different MSS or segs, using tcp_fragment, tso_fragment,
> > tcp_retrans_try_collapse, ..) maintain skb->decrypted. It's not
> > possible that skb is accidentally created that combines plaintext and
> > ciphertext content.
> > 
> > Although.. does this require adding that skb->decrypted check to
> > tcp_skb_can_collapse?  
> 
> Good catch. The TLS checks predate tcp_skb_can_collapse() (and MPTCP).
> We've grown the check in tcp_shift_skb_data() and the logic
> in tcp_grow_skb(), both missing the decrypted check.
> 
> I'll send some fixes, these are existing bugs :(

I take that back, we can depend on EOR like TLS does.

  reply	other threads:[~2024-05-30 20:15 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-10  3:04 [RFC net-next 00/15] add basic PSP encryption for TCP connections Jakub Kicinski
2024-05-10  3:04 ` [RFC net-next 01/15] psp: add documentation Jakub Kicinski
2024-05-10 22:19   ` Saeed Mahameed
2024-05-11  0:11     ` Jakub Kicinski
2024-05-11  9:41       ` Vadim Fedorenko
2024-05-11 16:25         ` David Ahern
2024-06-26 13:57       ` Sasha Levin
2024-05-13  1:24   ` Willem de Bruijn
2024-05-29 17:35     ` Jakub Kicinski
2024-05-30  0:47       ` Willem de Bruijn
2024-05-30 19:51         ` Jakub Kicinski
2024-05-30 20:15           ` Jakub Kicinski [this message]
2024-05-30 21:03             ` Willem de Bruijn
2024-05-31 13:56           ` Willem de Bruijn
2024-06-05  0:08             ` Jakub Kicinski
2024-06-05 20:11               ` Willem de Bruijn
2024-06-05 22:24                 ` Jakub Kicinski
2024-06-06  2:40                   ` Willem de Bruijn
2024-06-27 15:14       ` Lance Richardson
2024-06-27 22:33         ` Jakub Kicinski
2024-06-28 19:33           ` Lance Richardson
2024-06-28 23:41             ` Jakub Kicinski
2024-05-10  3:04 ` [RFC net-next 02/15] psp: base PSP device support Jakub Kicinski
2024-05-10  3:04 ` [RFC net-next 03/15] net: modify core data structures for PSP datapath support Jakub Kicinski
2024-05-10  3:04 ` [RFC net-next 04/15] tcp: add datapath logic for PSP with inline key exchange Jakub Kicinski
2024-05-10  3:04 ` [RFC net-next 05/15] psp: add op for rotation of secret state Jakub Kicinski
2024-05-16 19:59   ` Lance Richardson
2024-05-29 17:43     ` Jakub Kicinski
2024-05-10  3:04 ` [RFC net-next 06/15] net: psp: add socket security association code Jakub Kicinski
2024-05-10  3:04 ` [RFC net-next 07/15] net: psp: update the TCP MSS to reflect PSP packet overhead Jakub Kicinski
2024-05-13  1:47   ` Willem de Bruijn
2024-05-29 17:48     ` Jakub Kicinski
2024-05-30  0:52       ` Willem de Bruijn
2024-05-10  3:04 ` [RFC net-next 08/15] psp: track generations of secret state Jakub Kicinski
2024-05-10  3:04 ` [RFC net-next 09/15] net/mlx5e: Support PSP offload functionality Jakub Kicinski
2024-05-10  3:04 ` [RFC net-next 10/15] net/mlx5e: Implement PSP operations .assoc_add and .assoc_del Jakub Kicinski
2024-05-10  3:04 ` [RFC net-next 11/15] net/mlx5e: Implement PSP Tx data path Jakub Kicinski
2024-05-10  3:04 ` [RFC net-next 12/15] net/mlx5e: Add PSP steering in local NIC RX Jakub Kicinski
2024-05-13  1:52   ` Willem de Bruijn
2024-05-10  3:04 ` [RFC net-next 13/15] net/mlx5e: Configure PSP Rx flow steering rules Jakub Kicinski
2024-05-10  3:04 ` [RFC net-next 14/15] net/mlx5e: Add Rx data path offload Jakub Kicinski
2024-05-13  1:54   ` Willem de Bruijn
2024-05-29 18:38     ` Jakub Kicinski
2024-05-30  9:04       ` Cosmin Ratiu
2024-05-10  3:04 ` [RFC net-next 15/15] net/mlx5e: Implement PSP key_rotate operation Jakub Kicinski
2024-05-29  9:16 ` [RFC net-next 00/15] add basic PSP encryption for TCP connections 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=20240530131510.21243c94@kernel.org \
    --to=kuba@kernel.org \
    --cc=borisp@nvidia.com \
    --cc=cratiu@nvidia.com \
    --cc=gal@nvidia.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=rrameshbabu@nvidia.com \
    --cc=steffen.klassert@secunet.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.