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.” 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 <ATT00001..txt>
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
