<div dir="ltr">I understand that it indeed simplifies implementation.<div><br></div><div>However, now it is not possible to peer strongswan with palo-alto devices.</div><div>Do you have a suggested workaround?</div><div><br></div><div>Noam</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 10, 2015 at 5:26 PM, Tobias Brunner <span dir="ltr"><<a href="mailto:tobias@strongswan.org" target="_blank">tobias@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>
> What is the correct behavior in IKEv1? Deleting the child-SAs when the<br>
> IKE SA gets deleted, or keeping them around until they expire?<br>
<br>
</span>Having Phase 2 SAs without Phase 1 SAs is fine with IKEv1 (see [1]).<br>
However, charon is mainly an IKEv2 daemon, where this is not the case.<br>
To simplify the implementation charon follows the "the continuous<br>
channel model" also for IKEv1 (and does not support the other model).<br>
That is, its current data model has CHILD_SAs logically attached to<br>
IKE_SAs and if an IKE_SA is terminated so are its CHILD_SAs.<br>
<br>
Regards,<br>
Tobias<br>
<br>
[1] <a href="https://tools.ietf.org/html/draft-jenkins-ipsec-rekeying-06#section-3.3" target="_blank">https://tools.ietf.org/html/draft-jenkins-ipsec-rekeying-06#section-3.3</a><br>
<br>
</blockquote></div><br></div>