[strongSwan-dev] How to best conduct a cipher key update?

[Thomas Egerer]

On 11/15/2013 12:11 AM, Marksteiner, Stefan wrote:
> Hi Folks,
> 
> I'm sorry to post a little off-topic, but I need help from real experts as I can't seem to find any information about this issue on the web.
> 
> I am working on a C++ project where it is necessary to establish IPsec SAs with ESP and rapidly change the encryption key. To accomplish this I'm using Netlink/XFRM messages to alter the SAD
> Right now I'm deleting the corresponding SA and creating a new one (XFRM_MSG_DELSA and subsequent XFRM_XFRM_MSG_NEWSA) to update the key. This seems a little bit clumsy to me.
> 
> Is there a better way to do this?
> 
>  I've tried to use NLM_F_REPLACE in the Netlink message flags and XFRM_MSG_UPDSA as message type but these messages had simply no effect (Not  even a Netlink error message). I've seen XFRM_MSG_UPDSA being used to complete SAs initiated by XFRM_MSG_ALLOCSPI messages from state larval to mature.
> 
> Is this the only purpose for XFRM_MSG_UPDSA-type messages or may I use them somehow to alter encryption keys?
> 
> As the keys have to change rapidly (as stated above), performance is a factor. Therefore I want to strain my system with the smallest amount of administrative IPsec (=Netlink/XFRM) operations as possible.
> 
> Any help from the IPsec dev sages is highly appreciated :)
> 
> Thanks and cheers,
> 
> Stefan
Hi Stefan,

you are been doing it right.
If you dig in the kernel code, you will end up in
net/xfrm/xfrm_state.c:xfrm_state_update and see that among the
things updated, there's no keying material (unless the updated
state is in state ACQUIRE, as you alreayd know).
src/libhydra/plugins/kernel_netlink/kernel_netlink_ipsec.c:update_sa
does exactly the 'clumsy' thing you desribe. Except before deleting
the initial state, it copies over a couple of things, and then
installs the new state.
I'm not sure if it is a good idea to update the same CHILD_SA on
the fly, keeping the SPIs the same. They usually change during
rekeying, so this does not seem to be a use-case for the udpate
message.

Cheers,

Thomas