[strongSwan-dev] Understanding IKEv1 rekey

[Noam Lampert]

Thanks, I am optimistic about this working.


On Mon, Aug 22, 2016 at 1:43 PM, Tobias Brunner <tobias at strongswan.org>
wrote:

> Hi Noam,
>
> > Strongswan does not send a DELETE.
>
> Yeah, according to the message of the commit that added that break
> statement (3a0b67bce5) the idea was to just wait for the SA to expire
> (it doesn't really explain why the break was added and the peer is not
> notified about the deletion).  The duplicate check that was added later
> kills the SA after 10 seconds now.  Perhaps the break was added to avoid
> the alert if the SA expired, or the ike_updown() event (which has since
> been added) - with strongSwan a notification wasn't required anyway as
> it automatically deletes the old IKE_SA as responder of a rekeying.
> But I think notifying the peer that the SA was deleted makes definitely
> sense.  If deleting it after 10 seconds is a problem (e.g. because the
> DELETE is regularly dropped) we could probably also change that so SAs
> are not killed until they actually expire (as responder or initiator of
> the rekeying).  But since strongSwan does not negotiate SA lifetimes and
> always uses its own configuration that deletion will not be synced with
> the peer, which could cause problems later if a peer did not receive the
> delete and has a longer lifetime and still uses the SA.
>
> I pushed a change that removes the break statement to the
> ikev1-rekey-deletion branch.
>
> Regards,
> Tobias
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/dev/attachments/20160822/554614c7/attachment.html>