Hi Thomas, thanks a lot for your reply, no I know that I don't have to look any further in this direction.
In my particular case, I don't really care about the SPI, I just want to change the keys as quickly as possible. Therefore, I was thinking that sending one update message performs better than a delete and a new message. Unfortunately it obviously doesn't work this way :( Cheers and thanks again, Stefan > -----Ursprüngliche Nachricht----- > Von: Thomas Egerer [mailto:[email protected]] > Gesendet: Freitag, 15. November 2013 01:28 > An: Marksteiner, Stefan > Betreff: Re: [strongSwan-dev] How to best conduct a cipher key update? > > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
