<div dir="ltr"><div class="gmail_extra">Hi Tobias, Andreas,</div><div class="gmail_extra"><br></div><div class="gmail_extra">Thank you for your reply. I have a few more questions inline.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_quote">On Tue, Apr 14, 2015 at 5:32 AM, 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">> I notice the problem when the cisco attempts reauthentication of phase1.<br>
> It seems that the existing phase1 is first down-ed before the new one is<br>
> created. In most other firewalls, i see that a new phase1 is created<br>
> before the old one is killed.<br>
<br>
</span>Yes, charon does that too when reauthenticating IKEv1 SAs.  For IKEv2 we<br>
do what the Cisco box does and first terminate the existing IKE SA<br>
before recreating it with all CHILD_SAs.  That's where 5.3.0 with its<br>
optional make-before-break reauthentication comes in (as mentioned by<br>
Andreas).  But that's irrelevant for IKEv1 as we did this all along.<br>
However, it's also how we expect other IKEv1 implementations to<br>
reauthenticate SAs.<br></blockquote><div><br></div><div><br></div><div>Just to make sure I understand what is expected of IKEv1 connections, (sorry I had to ask again)</div><div>Are IKEv1s are expected to break all connections before making a new one?</div><div>Or </div><div>Are they expected to make a new one before breaking the old one. </div><div>I have seen Juniper firewalls and Cisco ASA make a new one before terminating an old one.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
> The problem with how the cisco891 does this is that when phase1 that is<br>
> being reauthenticated is deleted, the phase2s are also killed on<br>
> strongswan.<br>
<br>
</span>Yes, CHILD_SAs in charon are strictly associated with an IKE_SA, that<br>
is, they can't exist without one (possible that pluto handled this<br>
differently).  So when the IKE_SA with a peer is closed its CHILD_SAs<br>
are destroyed too (there are no DELETES sent for them because we act on<br>
the request of the other peer).<br>
<span class=""><br>
> Is there anyway to workaround this in strongswan?<br>
<br>
</span>I suppose you could change the process_r() method of the isakmp_delete_t<br>
task so that DELETES for ISAKMP SAs are ignored (i.e. simply return<br>
SUCCESS without doing anything else there).  That way the original SA<br>
and its CHILD_SAs are not closed but a reauthentication should still be<br>
detected when the Cisco box creates the new SA (the old CHILD_SAs are<br>
then adopted and the original IKE_SA gets closed).  The only<br>
disadvantage is that IKE_SAs can't be closed by peers anymore.</blockquote></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div>I was thinking of two ways to workaround this, the first being similar to what you suggest. Please let me know your opinion. </div><div class="gmail_extra">1. Ignore an Phase 1 delete if it still has phase2s. This is for IKEv1 only since we are testing with ikev1 firewalls only.</div><div class="gmail_extra">2. Instead of silently deleting Phase2s, do a proper delete that sends out a DELETE to the other side. Would this be difficult to implement?</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">regards,</div><div class="gmail_extra">SK</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><br></div></div>