[strongSwan-dev] How to best conduct a cipher key update?
stefan.marksteiner at joanneum.at
Mon Nov 18 13:23:26 CET 2013
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,
> -----Ursprüngliche Nachricht-----
> Von: Thomas Egerer [mailto:hakke_007 at gmx.de]
> 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
> 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
> > 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
> 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).
> does exactly the 'clumsy' thing you desribe. Except before deleting the
> 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
> not seem to be a use-case for the udpate message.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6613 bytes
Desc: not available
More information about the Dev