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 _______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
