Daniel Zahka wrote: > The PSP architecture spec specifies 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 and decryption key on the > current device key 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 socket to keep a chain of a max of > two psp assocs at any time. If authentication state does not match the > most recent assoc, the previous one 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.
So this defines a rekey event as an instant in time. An alternative choice is to rekey at a specific seqno. The difference matters only for retransmits. Not sure there is a strong reason for either. But probably good to state the choice explicitly. > The only catch, is in the case where hw uses a key handle > in tx descriptor state (as opposed to inlining the key directly). If > this is the 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, the series includes a driver api for > implementing deferred tx key deletion, where the driver can signal > back to the core when it is safe to dispose of old tx keys. > > Lastly, some test cases for rekeying are included that go through key > rotations and rekeying. Still reading the code, first pass only.
