On Tue, 20 Feb 2024 at 21:16, Paul Wouters via Swan-dev <swan-dev@lists.libreswan.org> wrote: > > > I see this commit: > > commit f198add4b08640d1b67aef19168998070b65b725 > Author: Andrew Cagney <cag...@gnu.org> > Date: Tue Feb 20 20:25:33 2024 -0500 > > ikev2: when responding to labeled TS don't search for a connection > > only possible match is the IKE SAs (note that at this point > the Child SA is sharing the IKE SAs connection). > > > I am confused by this? There could me multiple connections with different > labels that end up sharing an IKE SA ? eg:
No. With labeled IPsec the IKE SA has a CK_LABELED_PARENT connection and each Child SA has a unique CK_LABELED_CHILD connection instantiated from the IKE SA's CK_LABELED_PARENT). The IKE SA's CK_LABELED_PARENT owns the on-demand policy while the Child SA's CK_LABELED_CHILD owns a state/policy pair. The problem is that at this point in the code that split hasn't happened - the IKE and Child SA share a single connection - which means Child code trying to set the route owner can end up scribbling on the wrong connection. > conn labeled-1 > also=west-east > type=transport > policy-label=system_u:object_r:ipsec_spd_t:s0 > > conn labeled-2 > also=west-east > type=transport > policy-label=system_u:object_r:TOP_SECRET:s0 > > Paul > _______________________________________________ > Swan-dev mailing list > Swan-dev@lists.libreswan.org > https://lists.libreswan.org/mailman/listinfo/swan-dev _______________________________________________ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev