<div dir="ltr">Hey,<div><br></div><div>Thanks for the detailed answer.</div><div>I agree that an organized shutdown is easier to recover from.</div><div>I missed the uniqueids=replace. Thanks for the clear pointer.</div><div><br></div><div>Noam</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 19, 2014 at 11:34 AM, Martin Willi <span dir="ltr"><<a href="mailto:martin@strongswan.org" target="_blank">martin@strongswan.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Noam,<br>
<span class=""><br>
> If our gateway reboots, and a new IKE SA is established, is it possible<br>
> that we will still receive packets from the peer using a child-SA that was<br>
> established prior to the reboot?<br>
<br>
</span>If the peer thinks this IKE_SA is active, yes. strongSwan sends IKE_SA<br>
delete messages for all active IKE_SAs during shutdown. However, it does<br>
not wait for acknowledges, hence such message might get lost. It also<br>
depends on your init script etc. if networking actually still works in<br>
that phase.<br>
<span class=""><br>
> If so, what is the process in which the peer understands that this child SA<br>
> is no longer valid?<br>
<br>
</span>If it did not receive the delete message, it won't detect that failure<br>
until it either tries to rekey the SA, does something else over the same<br>
IKE_SA, or does a liveness/DPD check if that is enabled.<br>
<span class=""><br>
> For instance, it looks like our gateway won't be sending del-sa for the<br>
> child SA (when I look at ikev2/tasks/child_delete.c, it seems that this<br>
> will silently fail because the child-sa for the 'old' SPI won't be found).<br>
<br>
</span>During shutdown, charon sends IKE_SA delete messages using the<br>
ike_delete task. This implies closing all associated CHILD_SAs.<br>
<br>
When a DPD condition occurs (i.e. the peer does not answer on that SA),<br>
it silently deletes the IKE_SA and all associated CHILD_SAs, as an<br>
explicit delete most likely won't get answered, either. It then performs<br>
DPD actions, as configured.<br>
<span class=""><br>
> Does strongswan send an information unencrypted response according to<br>
> section 1.5 of RFC 4306?<br>
<br>
</span>No.<br>
<span class=""><br>
> I also saw some references to INITIAL_CONTACT, but they seem to be<br>
> centered only around IKEv1.<br>
<br>
</span>INITIAL_CONTACT works fine for IKEv2, and you probably should consider<br>
using it. If you have a unique policy configured (uniqueids=replace),<br>
strongSwan will send such a notify if it tries to establish an IKE_SA<br>
after a reboot. The peer (having uniqueids != never) will notice that,<br>
and deletes all existing IKE_SAs it has with the same peer identity.<br>
This should make sure the old IKE_SA gets deleted.<br>
<br>
Regards<br>
<span class="HOEnZb"><font color="#888888">Martin<br>
<br>
</font></span></blockquote></div><br></div>