[strongSwan-dev] Question about old child-SAs

[Noam Lampert]

Hey,

Thanks for the detailed answer.
I agree that an organized shutdown is easier to recover from.
I missed the uniqueids=replace. Thanks for the clear pointer.

Noam

On Wed, Nov 19, 2014 at 11:34 AM, Martin Willi <martin at strongswan.org>
wrote:

> Hi Noam,
>
> > If our gateway reboots, and a new IKE SA is established, is it possible
> > that we will still receive packets from the peer using a child-SA that
> was
> > established prior to the reboot?
>
> If the peer thinks this IKE_SA is active, yes. strongSwan sends IKE_SA
> delete messages for all active IKE_SAs during shutdown. However, it does
> not wait for acknowledges, hence such message might get lost. It also
> depends on your init script etc. if networking actually still works in
> that phase.
>
> > If so, what is the process in which the peer understands that this child
> SA
> > is no longer valid?
>
> If it did not receive the delete message, it won't detect that failure
> until it either tries to rekey the SA, does something else over the same
> IKE_SA, or does a liveness/DPD check if that is enabled.
>
> > For instance, it looks like our gateway won't be sending del-sa for the
> > child SA (when I look at ikev2/tasks/child_delete.c, it seems that this
> > will silently fail because the child-sa for the 'old' SPI won't be
> found).
>
> During shutdown, charon sends IKE_SA delete messages using the
> ike_delete task. This implies closing all associated CHILD_SAs.
>
> When a DPD condition occurs (i.e. the peer does not answer on that SA),
> it silently deletes the IKE_SA and all associated CHILD_SAs, as an
> explicit delete most likely won't get answered, either. It then performs
> DPD actions, as configured.
>
> > Does strongswan send an information unencrypted response according to
> > section 1.5 of RFC 4306?
>
> No.
>
> > I also saw some references to INITIAL_CONTACT, but they seem to be
> > centered only around IKEv1.
>
> INITIAL_CONTACT works fine for IKEv2, and you probably should consider
> using it. If you have a unique policy configured (uniqueids=replace),
> strongSwan will send such a notify if it tries to establish an IKE_SA
> after a reboot. The peer (having uniqueids != never) will notice that,
> and deletes all existing IKE_SAs it has with the same peer identity.
> This should make sure the old IKE_SA gets deleted.
>
> Regards
> Martin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/dev/attachments/20141119/37ced4a9/attachment.html>