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 [off-list ref]