[strongSwan] [RFC][PATCH] set negotiated traffic selectors in SAs for transport mode

Jiri Bohac jbohac at suse.cz
Wed Aug 4 15:01:48 CEST 2010

Currently, negotiated traffic selectors are only applied on SPs.
Certain situations require them in SAs as well.

Example (taken from a previously failig ipv6ready IKEv2.EN.I. test case):


	"left" uses strongSwan/charon as the IKEv2 daemon.
	A SA for 2001:0db8:0001:0001::1234 <-> 2001:0db8:000f:0001::1 is
	created. When the first packet is sent from 2001:0db8:0001:0001::1234 to 
	2001:0db8:000f:0001::1 the IKE negotiation starts.

	The IKE daemon on "right" is configured to only use IPsec
	for TCP connections, and thus tries to narrow the traffic selector from the proposal
	to 2001:0db8:0001:0001::1234[tcp] <-> 2001:0db8:000f:0001::1[tcp].

	"left" correctly narrows down the traffic selectors and creates a new SP with these
	narrowed (tcp-only) selectors. However, the SA has no traffic selectors and thus "left"
	still applies the IPsec transforms to non-TCP traffic.

This patch makes strongSwan set the negotiated TSs the SAs it creates.

Index: strongswan-4.4.0/src/libcharon/plugins/kernel_netlink/kernel_netlink_ipsec.c
@@ -965,6 +965,7 @@ METHOD(kernel_ipsec_t, add_sa, status_t,
 			sa->flags |= XFRM_STATE_AF_UNSPEC;
 		case MODE_BEET:
 			if(src_ts && dst_ts)
 				sa->sel = ts2selector(src_ts, dst_ts);
Index: strongswan-4.4.0/src/libcharon/sa/child_sa.c
--- strongswan-4.4.0.orig/src/libcharon/sa/child_sa.c	2010-03-19 16:56:54.000000000 +0100
+++ strongswan-4.4.0/src/libcharon/sa/child_sa.c	2010-07-29 19:53:12.000000000 +0200
@@ -605,7 +605,7 @@ static status_t install(private_child_sa
 		lifetime->time.rekey = 0;
-	if (this->mode == MODE_BEET)
+	if (this->mode == MODE_BEET || this->mode == MODE_TRANSPORT)
 		/* BEET requires the bound address from the traffic selectors.
 		 * TODO: We add just the first traffic selector for now, as the

Does this look like the right thing to do? Why was this ever
limited to the BEET mode? Shouldn't the same thing be done for
TUNNEL mode as well?

This only fixes the problem for the netlink kernel interface as I
was testing this on Linux. Similar thing could probably be done
for other kernel interfaces.


Jiri Bohac <jbohac at suse.cz>

More information about the Users mailing list