Hi, Scott, I want to ask one more thing about Traffic Selector.
In my case, host A and host B are working as follows about Traffic Selector : 1) host A (initiator) sends TS to host B (responder) 2) host B narrows the TS sent by host A and responses the narrowed TS to host A At this point, the narrowed TS includes the TSs that violates the policy of initiator such as different protocol IDs of TSi and TSr, etc. Then, can host A (initiator) also narrow the narrowed TSs, that is to remove the case of which the protocol IDs are different? I'm looking forward to responses. Thanks in advance. My Best Regards, Jaemin Park On Sat, Jun 19, 2010 at 12:07 AM, Scott C Moonen <smoo...@us.ibm.com> wrote: > 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&UDP case is a > strange one, and in particular it doesn't accomplish much for TCP, but it is > allowed by the RFC. If your SPD and/or SAD pragmatically do not allow you to > express this sort of asymmetry for IPsec-protected traffic, then it is > proper for you to respond with TS_UNACCEPTABLE to such a proposal. You will > of course be unable to interoperate with a peer making such a proposal, but > in this case I'm not sure that is a great hardship. > > Also don't forget to take into account complex proposals containing more > than one traffic selector for TSi and/or TSr. > > > Scott Moonen (smoo...@us.ibm.com) > z/OS Communications Server TCP/IP Development > http://www.linkedin.com/in/smoonen > > [image: Inactive hide details for Jaemin Park ---06/18/2010 10:51:53 > AM---Dear All,]Jaemin Park ---06/18/2010 10:51:53 AM---Dear All, > > > From: > Jaemin Park <jmpar...@gmail.com> > To: > ipsec@ietf.org > Date: > 06/18/2010 10:51 AM > Subject: > [IPsec] Complexing of Traffic Selector (TSi & TSr) > ------------------------------ > > > > 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 which have same > protocol IDs are defined and clarified. > However, in the case when TSi is (17 (udp) any any) and TSr is (ip any any) > where protocol IDs are different, should VPN complex TSi and TSr? > According to the implementation of strongswan, we could find the fact that > the strongswan is checking when complexing the TSi and TSr as follows : > 1) remove the policy which has different protocol IDs for TSi and TSr as > long as both of them are not "ANY" > 2) follow the protocol which is not "ANY" if one of TSi and TSr is "ANY" > According to my analysis, following examples can be possible : > - ANY & ANY yields ANY > - ANY & UDP yields UDP > - UDP & UDP yields UDP > - TCP & UDP <-- remove this case > > Does above implementation of strongswan follow the standards? > If so, we're planning to implement the way the strongswan supports. > > I'm looking forward to all of the experts' responses. > > My Best Regards, > Jaemin Park > > -- > Park, Jae Min > Assistant Manager > Device R&D Center , Convergence WIBRO BU, KT > M : +82-10-3010-2658 > T : +82-2-2010-9255 * > * > *jmp...@kt.com* <jmp...@kt.com>, *jmpar...@gmail.com* <jmpar...@gmail.com> > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > -- Park, Jae Min Assistant Manager Device R&D Center , Convergence WIBRO BU, KT M : +82-10-3010-2658 T : +82-2-2010-9255 jmp...@kt.com, jmpar...@gmail.com
<<ecblank.gif>>
<<graycol.gif>>
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
