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 <[email protected]>
SUSE Labs, SUSE CZ
_______________________________________________
Users mailing list
[email protected]
https://lists.strongswan.org/mailman/listinfo/users
