[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.1.1.7.1 test case):
left=2001:0db8:0001:0001::1234
right=2001:0db8:000f:0001::1
auto=route
"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;
break;
case MODE_BEET:
+ case MODE_TRANSPORT:
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.
Thanks,
--
Jiri Bohac <jbohac at suse.cz>
SUSE Labs, SUSE CZ
More information about the Users
mailing list