[IPsec] Complexing of Traffic Selector (TSi & TSr)

2010-06-18 Thread Jaemin Park
Dear All, I'm in charge of developing VPN Clients based on IKEv2 and IPSec. We referred to the implementation of strongswan and RFC documents such as 4306 and 4718. While developing, we faced one question about complexing of Traffic Selectors. According to the RFC 4718, complexing of TSi and TSr

Re: [IPsec] Complexing of Traffic Selector (TSi & TSr)

2010-06-18 Thread Scott C Moonen
Hi Jaemin, The RFC allows you to narrow the proposed traffic selectors to something smaller than what the peer proposes. From your description, it sounds like StrongSwan has made a pragmatic choice to narrow the proposed selectors to something symmetrical. This is allowed by the RFC. The TCP&U

[IPsec] Clarification about an implementation's response to out of order payloads

2010-06-18 Thread Joy Latten
The last paragraph of section 2.5 in RFC 4306 states: Although new payload types may be added in the future and may appear interleaved with the fields defined in this specification, implementations MUST send the payloads defined in this specification in the order shown in the figures i

Re: [IPsec] Clarification about an implementation's response to out of order payloads

2010-06-18 Thread Paul Hoffman
At 4:14 PM -0500 6/18/10, Joy Latten wrote: >The last paragraph of section 2.5 in RFC 4306 states: > > Although new payload types may be added in the future and may appear > interleaved with the fields defined in this specification, > implementations MUST send the payloads defined in this spe