[Swan-dev] no proposal chosen response when a rekey

[Paul Wouters]

On Fri, 13 Sep 2019, Andrew Cagney wrote:

> See https://dpaste.de/EyUR from IRC
>
> - libreswan sends a rekey request and gets back no proposal chosen
>
> I suspect this is because libreswan's proposal strictly requires DH
> and the other end strictly refuse it (further down in the log is the
> remote proposing to CREATE_CHILD_SA with no DH)

a rekey MUST be for identical parameters, so was libreswan too nice to
continue with a DH mismatch ?

> But what's more interesting is the other things that go on:
>
> dropping unexpected CREATE_CHILD_SA message containing
> NO_PROPOSAL_CHOSEN notification; message payloads: SK; encrypted
> payloads: N; missing payloads: SA,Ni,TSi,TSr
> -> we're missing a state transition to detect this and initiate a delete

Should we delete? If we just respond and keep the state, the existing
tunnel will still work until expiry time. So the current way of sending
an error and not deleting seems correct?

> message id deadlock? wait sending, add to send next list using parent
> #1628 unacknowledged 1 next message id=1 ike exchange window 1
> -> there's an outstanding re-transmit in front of the delete request;
> the code should just kill the SA family - given the re-transmit went
> no where what makes us think a delete will do better

I don't think we should send a new IKE request, so this situation is
avoided :)

Are we sure the rekey did not fail due to it matching the wrong conn and
this wrong subnet? Eg what happens if:

conn foo establishes
conn bar uses CREATE_CHILD_SA to be setup as well.

The IKE SA of foo is now shared with foo and bar.

If the remote sends a REKEY request for bar, do we know that we need to
switch connection?

Guess we need ipsec whack --child-rekey name :)

Paul