Hi Jaemin, If initiator narrows down the TSr, then 1. the responder is not aware of initiator has narrowed down TSr and if it initiates a traffic which is from a broader section of range which Initiator has not accepted, there will data black-hole. 2. I think, better solution will be, If initiator has to narrow down the TSr, it can delete old Child SA and negotiate a new Child SA based on knowledge of TSr that are acceptable to initiator as well as responder.
Regards, Raj On Sat, Jun 19, 2010 at 11:15 PM, Jaemin Park <jmpar...@gmail.com> wrote: > 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 > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > >
<<ecblank.gif>>
<<graycol.gif>>
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
