Michael Christian writes: > Hello, > > I’m investigating a possible RFC 7296 compliance issue and I was hoping you > may be able to shed some light on the RFC for me. > > In section 2.9 Page 43 regarding multiple traffic selectors: > > Can two TSi proposals be sent by the initiator every time IKEv2 is negotiated > due to a data packet?
I do not really understand what you are trying to ask. Any TSi payload can have multiple traffic selectors. Those traffic selectors are from the policy rule, and the first of them can be from the data packet, if SA was created because of the data packet, i.e. the text says: 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. So yes, when you ask for SA to be created based on the traffic, you SHOULD always include two TSi traffic selectors, one which matches the data from the packet, and another which is taken from the policy. > Or Is the proposal of an unknown traffic selector type required > before the initiator can respond with more specific and range TSi’s? Initiator will never respond with TSi. Initiator sends the TSi ranges, and it of course should never send unknown traffic selector types, as it should only send those traffic selectors it knows. The responder might receive unknown traffic selector types, because initiator might support more things than responder do, and in that case the responder will simply ignore those and process TS payload just like those unknown traffic selector types were not there at all, i.e. narrow the request using the known traffic selector types. As responder will only reply with traffic selectors sent by the initiator the initiator can never get back an TS reply containing unknown traffic selector types. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
