<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 13 Sep 2019 at 18:35, Paul Wouters <<a href="mailto:paul@nohats.ca" target="_blank">paul@nohats.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, 13 Sep 2019, Andrew Cagney wrote:<br>
<br>
> See <a href="https://dpaste.de/EyUR" rel="noreferrer" target="_blank">https://dpaste.de/EyUR</a> from IRC<br>
><br>
> - libreswan sends a rekey request and gets back no proposal chosen<br>
><br>
> I suspect this is because libreswan's proposal strictly requires DH<br>
> and the other end strictly refuse it (further down in the log is the<br>
> remote proposing to CREATE_CHILD_SA with no DH)<br>
<br>
a rekey MUST be for identical parameters, so was libreswan too nice to<br>
continue with a DH mismatch ?<br>
<br></blockquote><div><br></div><div>Except the rekey adds DH.</div><div><br></div><div>The CREATE_CHILD_SA from the other end seems to be for a new CHILD on an established IKE SA.  Since it didn't include DH that makes me suspect that is why our proposal is failing.  But we need to see the other end.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> But what's more interesting is the other things that go on:<br>
><br>
> dropping unexpected CREATE_CHILD_SA message containing<br>
> NO_PROPOSAL_CHOSEN notification; message payloads: SK; encrypted<br>
> payloads: N; missing payloads: SA,Ni,TSi,TSr<br>
> -> we're missing a state transition to detect this and initiate a delete<br>
<br>
Should we delete? If we just respond and keep the state, the existing<br>
tunnel will still work until expiry time. So the current way of sending<br>
an error and not deleting seems correct?<br></blockquote><div><br></div><div><br></div><div>(More context)</div><div><br></div><div>Pluto initiated the rekey.  It got back the no proposal chosen response but ignored it.</div><div>Consequently it re-transmits the original re-key, and that request clogs up the outgoing message queue (we can't send anything else until it clears).</div><div><br></div><div>I see two problems:</div><div><br></div><div>1. It should have paired the response with the request, and stopped re-transmitting; even though the response contents weren't as expected</div><div>Like you point out it could then wait for the replace timeout; or immediately initiate a replace.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> message id deadlock? wait sending, add to send next list using parent<br>
> #1628 unacknowledged 1 next message id=1 ike exchange window 1<br>
> -> there's an outstanding re-transmit in front of the delete request;<br>
> the code should just kill the SA family - given the re-transmit went<br>
> no where what makes us think a delete will do better<br>
<br></blockquote><div><br></div><div>Now lets pretend that there never was a response (rather than the above bug, someone yanked the cable); and lets ignore mobike</div><div><br></div><div>2. Pluto's used up all its re-transmits so the entire SA family is SNAFUed - the IKE SA should simply be declared down</div><div>Since the (rekey) request is clogging up the request queue there's no space to send the delete; and besides, if that request isn't getting though, why would the next (delete)</div><div>So the only option left is to throw away the entire SA family and, depending on policy, start again.</div><div>This isn't specific to rekeying - any request timing out should cause the IKE SA to be declared dead.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I don't think we should send a new IKE request, so this situation is<br>
avoided :)<br>
<br>
Are we sure the rekey did not fail due to it matching the wrong conn and<br>
this wrong subnet? Eg what happens if:<br>
<br>
conn foo establishes<br>
conn bar uses CREATE_CHILD_SA to be setup as well.<br>
<br>
The IKE SA of foo is now shared with foo and bar.<br>
<br>
If the remote sends a REKEY request for bar, do we know that we need to<br>
switch connection?<br>
<br>
Guess we need ipsec whack --child-rekey name :)</blockquote><div><br></div><div>so we can trigger any event :-)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Paul<br>
</blockquote></div>
</div>