Responder might select incorrect child config when using transport mode

[tobiasbrunner]

Discussed in #1129

^{Originally posted by yizhao1 July 8, 2022}
I have a question about the traffic selector. In my environment, I found the IPsec does not work for remote communication of the second traffic selector on the responder. But it works when the traffic selector is set to the first.
...
There are 2 hosts: Host A (192.168.0.105) and Host B (192.168.0.109)

If Host B is in the second traffic selector (child_2) in swanctl.conf on Host A. I can not ping Host A from Host B. But I can ping Host B from Host A. After this, I can ping Host A from Host B. There is no such issue if Host B is in the first traffic selector (child_1).

...

looking for a child config for 192.168.0.105/32[udp/1025] 192.168.0.105/32 === 192.168.0.109/32[udp/56269] 192.168.0.109/32
proposing traffic selectors for us:
192.168.0.105/32
proposing traffic selectors for other:
192.168.0.109/32
candidate "child_1" with prio 7+7
proposing traffic selectors for us:
192.168.0.105/32
proposing traffic selectors for other:
192.168.0.109/32
candidate "child_2" with prio 7+7
found matching child config "child_1" with prio 14
...
selecting traffic selectors for us:
config: 192.168.0.105/32, received: 192.168.0.105/32[udp/1025] => match: 192.168.0.105/32[udp/1025]
config: 192.168.0.105/32, received: 192.168.0.105/32 => match: 192.168.0.105/32
selecting traffic selectors for other:
config: 192.168.0.100/32, received: 192.168.0.109/32[udp/56269] => no match
config: 192.168.0.100/32, received: 192.168.0.109/32 => no match
no acceptable traffic selectors found

Seems this is introduced by commit:
da82786

[tobiasbrunner]

The mentioned commit replaces non-dynamic traffic selectors for transport mode configs. In particular for wildcard trap policies (we don't want to propose subnets for these transport mode SAs but TS narrowed to the actual IP that triggered the acquire). The problem is that the get_traffic_selectors() method is also called with the same parameters (no supplied TS but hosts) when selecting child configs as responder. Replacing IPs for all configs there isn't a good idea as we might select one for which narrowing will later fail (when narrowing, we don't replace non-dynamic TS).

The proposed fix in the 1143-transport-ts branch avoids the above issue by ignoring TS that don't include the given IP. So in the above scenario, child_1 would only get 7 as prio as there won't be a remote TS, so child_2 would get selected.