On Thu, 27 Jun 2024 11:14:39 -0400 Lance Richardson wrote:

quoted

quoted

Connection key rotation is not supported? I did notice that tx key
insertion fails if a key is already present, so this does appear to be
the behavior.  

Correct, for now connections need to be re-established once a day.
Rx should be easy, Tx we can make easy by only supporting rotation
when there's no data queued.

Could you elaborate on why updating the Tx key should only be allowed when
no data is queued? At the point rekeying is being done, the receiver should
accept both the new and previous key:spi.

I didn't say it shouldn't be allowed, just that disallowing it
initially would make the implementation easier ;)

The lack of support for rekeying existing connections is a significant gap. At
a minimum the API for notifying the application that a rotation has occurred
should be defined, 

Notifications are in place, that's one of the reasons I chose netlink.

and the implementation should allow the configuration of a new Tx
key:spi for rekeying.

I was under the possibly mistaken impression that Google have used PSP
for years without rekeying... Did I misunderstand?

A tiny bit logic would also be needed on the Rx
side to track the current and previous SPI, if the hardware supports
keys indescriptors then nothing more should be needed on the Tx side.
If the NIC maintains an SA database and doesn't allow existing
entries to be updated, a small amount of additional logic would be
needed, but perhaps that could be (waving hands a bit) the
responsibility of the driver.

Interesting. Hm. But SADB drivers would then have to implement some
complex logic to make sure all rings have cycled, or take references.
I'd rather have an opt-in for core to delay reaping old keys until
all sockets which used them went empty at least once (in wmem sense).