Re: [PATCH net-next v3 0/5] psp: support rekeying psp protected tcp connections

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

Daniel Zahka wrote:
> A note on v3:
> To keep this series short, I have split off some of the content that
> appeared in v2, and also have planned future work that will make this
> feature more robust, but not necessary to start. Here is the current
> queue of follow up series:
>  1. core tracked tx-key-count stat and SADB drain test case (from v2). I
>     see this as able to stand alone as a series, and I also would like
>     to report key deletion errors, but will have to touch mlx5 for that.
>  2. core to end grace period if BQL is stalled. I think this deserves
>     its own series for human discussion.
>  3. Rate limiting rekey uAPIs. This has been suggusted by the bot, but

Hey, I'm not a bot! :P

>     whether or not it is needed depends on a bit on the deployment
>     model.
> 
> Original cover letter:
> 
> The PSP architecture spec states the need for rekeying connections in
> the event of a device key rotation. After a device key rotation has
> occurred, a new rx derived key needs to be generated and sent out to the
> other end of the connection sometime before the next device key rotation
> occurs.
> 
> Because PSP connections involve two different keys at each endpoint,
> one for decrypting ingress traffic, and one for encrypting egress
> traffic, there are two types of rekeying events that need to be
> supported. From the perspective of one endpoint of the connection:
> 
> 1. rx rekey: we need to allocate a new spi + decryption key pair to
>    provide to our peer.
> 
> 2. tx rekey: our peer has provided us with a new spi + encryption key
>    pair which we should use for encrypting traffic immediately.
> 
> In the case of rx rekeying, there is a period where it makes sense to
> accept packets authenticated from either the previous or current spi. To
> deal with that, we allow a psp_assoc to remember the last spi that was
> valid on a socket due to a rekey. If authentication state does not match
> the most recent assoc, the stored state from the previous assoc will be
> tried.
> 
> In the case of tx rekeying, as soon as we install the new tx key, we
> have no use for the previous one, and it can be disposed of immediately.
> The only catch is in the case where hw uses a key handle in tx
> descriptor state, as opposed to inlining the key directly. In this
> case, psp core needs to be sure that any of these unaccounted for
> references to key state are gone by the time it tries to sync a deleted
> key to hw.
> 
> To deal with this race condition, we introduce a different path to key
> deletion for psp_assocs removed from the socket during a tx rekey. psp
> core will use bql byte counters filled out by the driver to determine a
> conservative grace period where key handles can be disposed of.
> 
> Lastly, some test cases for rekeying are included that go through key
> rotations and rekeying.
> 
> There are some packetdrill tests that are queued for upstreaming [1].
> 
> Future work can include a time based rate limit on the rx-assoc/tx-assoc
> uAPIs to prevent an untrusted user from creating lots of wasted PSP
> assocs and consuming SPIs, SADB space, etc. For now, users should use
> network namespaces, or otherwise not present PSP devices to users that
> could abuse this.
> 
> [1]: https://github.com/danieldzahka/packetdrill/commits/psp-rekey/
> 
> Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com>

For the series: Reviewed-by: Willem de Bruijn <willemb@google.com>