[Swan-dev] labeled TS don't search for a connection ?

Andrew Cagney andrew.cagney at gmail.com
Wed Feb 21 05:49:51 EET 2024


On Tue, 20 Feb 2024 at 21:16, Paul Wouters via Swan-dev
<swan-dev at lists.libreswan.org> wrote:
>
>
> I see this commit:
>
> commit f198add4b08640d1b67aef19168998070b65b725
> Author: Andrew Cagney <cagney at 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 at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan-dev


More information about the Swan-dev mailing list