IKEv2 Traffic Selector Narrowing Nuance

Question

For IKEv2, when the responder receives traffic selector payloads from the initiator in the IKE_AUTH message, it must narrow the traffic selectors to be acceptable by policy.

I am curious about how the responder must respond with the narrowed traffic selectors when some can be grouped together.

For example, say the initiator proposes two tsi's: 192.0.2.0-192.0.2.0 [udp/80-80] and 192.0.2.1-192.0.2.1[udp/80-80]

If the responder accepts both of these traffic selectors, must it respond with them as two different traffic selectors (the same way it received them) or is it okay to combine them to reduce the packet size (a single tsi of 192.0.2.0-192.0.2.1 [udp/80-80])?

I am having a hard time determining if the RFC allows such a thing

Answer 1

RFC 7296, section 2.9 states:

 When the responder chooses a subset of the traffic proposed by the   
 initiator, it narrows the Traffic Selectors to some subset of the   
 initiator's proposal (provided the set does not become the null set).

So the result is a subset of the initiator's traffic selectors, which the combination of the two traffic selectors is not.

The RFC also later explicitly addresses your question whether the responder generally returns the traffic selectors as it received them if they are acceptable:

 o  If the responder's policy allows the entire set of traffic covered
    by TSi and TSr, no narrowing is necessary, and the responder can
    return the same TSi and TSr values.

However, the responder can "combine" traffic selectors if one is contained in another, which is what happens if the recommendation in the RFC is followed and the initiator sends very specific first traffic selectors (containing IPs, protocol and ports of a matched packet) but also adds more generic traffic selectors for e.g. a complete IP/subnet with all ports and protocols. If the responder accepts the wider traffic selectors (or a subset of them), it doesn't have to return the specific ones as those are completely contained in the other. From the RFC:

                                       In the example, the initiator
 would include in TSi two Traffic Selectors: the first containing the
 address range (198.51.100.43 - 198.51.100.43) and the source port and
 IP protocol from the packet and the second containing (198.51.100.0 -
 198.51.100.255) with all ports and IP protocols.  The initiator would
 similarly include two Traffic Selectors in TSr.

and then

 o  If the responder's policy allows it to accept the first selector
    of TSi and TSr, then the responder MUST narrow the Traffic
    Selectors to a subset that includes the initiator's first choices.
    In this example above, the responder might respond with TSi being
    (198.51.100.43 - 198.51.100.43) with all ports and IP protocols.