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

[Marksteiner, Stefan]

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: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
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6613 bytes
Desc: not available
URL: <http://lists.strongswan.org/pipermail/dev/attachments/20131118/0f6f6fbc/attachment.bin>