On Tue, 5 Jun 2018, Antony Antony wrote:
I noticed a regression in test ikev2-ike-rekey-03. I was hunting an issue Tuomo found. While trouble shooting it I noticed this regression.
http://testing.libreswan.org/results/testing/v3.22-1500-g2efd341-master/ikev2-ike-rekey-03/
I will look into this.
for now the workaround seems to be "uniqueids=no" which is good idea with IPsec SAs sharing IKE SA.
I don't agree that is a good idea :)
there is a long history of uniqueids and initial-contact in libreswan. my 00.2c comment "uniqueids=no" on peer-to-peer makes sense to me.
I'm not sure what you mean with peer-to-peer? I suspect that IPsec SA's are still not properly migrated from an old IKE SA to a new IKE SA on rekey and that only the single IPsec SA that is on the same conn as the IKE SA is migrated. As a side effect, now that we clean up the old IKE SA, it tears down those IPsec SA's that were mistakenly not migrated to the new IKE SA state. This bug is the same one that can use multiple IKE SA's from becoming active and causing confusion with peers that don't expect multiple IKE SA's with the same peer. So I think that commit 9bd57bb only causes the actual bug to be visible, but that it is itself not a bug :) Paul _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
