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 _______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
