It's still a pair: To enable the responder to choose the appropriate range in this case, if the initiator has requested the SA due to a data packet, the initiator SHOULD include as the first Traffic Selector in each of TSi and TSr a very specific Traffic Selector including the addresses in the packet triggering the request.
and in the above case, the initiator (pluto) sent one pair, the responder (strongswan) sent back: proposing traffic selectors for us: 192.0.2.0/24 proposing traffic selectors for other: 192.0.3.1/32 192.0.3.2/32 On Thu, 1 Nov 2018 at 23:07, Paul Wouters <[email protected]> wrote: > > Oh, yes. The initiator MAY send a TSi that is the trigger packet that lead to > its proposal, which might be 0/0 to 0/0. It allows the responder to narrow to > the trigger packet > > Sent from mobile device > > > On Nov 2, 2018, at 09:18, Andrew Cagney <[email protected]> wrote: > > > >> On Thu, 1 Nov 2018 at 17:36, Andrew Cagney <[email protected]> wrote: > >> > >> Reading https://tools.ietf.org/html/rfc7296#section-2.9 I get the > >> feeling that the traffic selectors in the TSi/TSr payloads are always > >> paired - TSi[n] goes with TSr[n]. The examples, for instance, do > >> this. And without matching pairs things struggle to make sense. > >> However, I couldn't find text clearly spelling this out. Perhaps I'm > >> missing something. > >> > >> This would mean code should check elemsof(TSi) == elemsof(TSr). > > > > I still think this is true, strongswan disagrees. In > > interop-ikev2-strongswan-39-mobike-responder pluto sends a single pair > > of traffic selectors: > > > > | ****emit IKEv2 Traffic Selector - Initiator - Payload: > > | number of TS: 1 (0x1) > > | *****emit IKEv2 Traffic Selector: > > | TS type: IKEv2_TS_IPV4_ADDR_RANGE (0x7) > > | IP Protocol ID: 0 (0x0) > > | start port: 0 (0x0) > > | end port: 65535 (0xffff) > > | ipv4 start 00 00 00 00 > > | ipv4 end ff ff ff ff > > > > | ****emit IKEv2 Traffic Selector - Responder - Payload: > > | number of TS: 1 (0x1) > > | *****emit IKEv2 Traffic Selector: > > | TS type: IKEv2_TS_IPV4_ADDR_RANGE (0x7) > > | IP Protocol ID: 0 (0x0) > > | start port: 0 (0x0) > > | end port: 65535 (0xffff) > > | ipv4 start c0 00 02 00 > > | ipv4 end c0 00 02 ff > > > > but strongswan comes back with: > > > > proposing traffic selectors for us: > > 192.0.2.0/24 > > proposing traffic selectors for other: > > 192.0.3.1/32 > > 192.0.3.2/32 > > > > as in: > > > > | **parse IKEv2 Traffic Selector - Initiator - Payload: > > | number of TS: 2 (0x2) > > | TS: parse initiator traffic selectors > > | ***parse IKEv2 Traffic Selector: > > | TS type: IKEv2_TS_IPV4_ADDR_RANGE (0x7) > > | IP Protocol ID: 0 (0x0) > > | length: 16 (0x10) > > | start port: 0 (0x0) > > | end port: 65535 (0xffff) > > | ipv4 ts low c0 00 03 01 > > | ipv4 ts high c0 00 03 01 > > | ***parse IKEv2 Traffic Selector: > > | TS type: IKEv2_TS_IPV4_ADDR_RANGE (0x7) > > | IP Protocol ID: 0 (0x0) > > | length: 16 (0x10) > > | start port: 0 (0x0) > > | end port: 65535 (0xffff) > > | ipv4 ts low c0 00 03 02 > > | ipv4 ts high c0 00 03 02 > > | TS: parsed 2 TS payloads > > > > | **parse IKEv2 Traffic Selector - Responder - Payload: > > | number of TS: 1 (0x1) > > | TS: parse responder traffic selectors > > | ***parse IKEv2 Traffic Selector: > > | TS type: IKEv2_TS_IPV4_ADDR_RANGE (0x7) > > | IP Protocol ID: 0 (0x0) > > | length: 16 (0x10) > > | start port: 0 (0x0) > > | end port: 65535 (0xffff) > > | ipv4 ts low c0 00 02 00 > > | ipv4 ts high c0 00 02 ff > > | TS: parsed 1 TS payloads > > > > which with "ikev2 ts: group paired traffic selectors in a single > > structure" gets rejected. > > > > (and this cascades eventually cause a core dump because the initiator > > has an authenticated parent with no child). > > _______________________________________________ > > Swan-dev mailing list > > [email protected] > > https://lists.libreswan.org/mailman/listinfo/swan-dev > _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
