Subject: [IPsec] Question about TS construction on IKEv2 initiator

From: Gaurav Poothia <[email-masked]>
Date: Mon, 10 Jan 2011 22:21:30 +0000

Excerpt from RFC 5996 Sec 2.9
"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."

I am not sure if there is a RFC dictated upper bound on the number of Traffic Selectors in each of TSi and TSr.
Looking at the examples in the RFC you can surely have 1 or 2 selectors.  But are any more allowed?

The answer obviously effects the complexity of the responder's TS narrowing algo where a union of the incoming Traffic Selectors is an input.

Thanks

---

From: Yoav Nir <[email-masked]>
Date: Tue, 11 Jan 2011 01:27:59 +0200

Hi Gaurav

There's a 1-octet field called "Number of TSs", so there can be at most 255 traffic selectors for each of initiator and responder.

And yes, as many selectors are allowed as you need to describe your policy.  In practice, some implementations can't handle complex policies, and require SAs to cover entire subnets or single ranges. If your algorithms only handles the first two selectors of each kind, I think it will work fine, but will produce more SAs than policy dictates.

On Jan 11, 2011, at 12:21 AM, Gaurav Poothia wrote:

Excerpt from RFC 5996 Sec 2.9
“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.”

The answer obviously effects the complexity of the responder’s TS narrowing algo where a union of the incoming Traffic Selectors is an input.

Thanks

<ATT00001..txt>