Hi Jaemin, The problem is at initiator side, when its sending its TSi/TSr, it sending some range which is violating its own policies. This is not allowed by RFC as per section 2.9.1.
Regards, Raj 2010/6/20 Jaemin Park <jmpar...@gmail.com> > Dear All, > > I need to clarify my question. > My question is about the way for initiator to complex the TS narrowed by > responder. > > Suppose that following TSs are returned by the responder. > > 1) TSi = (TS1, TS2) > 2) TSr = (TS3, TS4, TS5) > > While complexing, the case TS1 and TS5 need to be removed by initiator due > to the difference of protocol ID and violation of the intended policy. > > Can initiator remove the above case and follow the RFC? > > I'm looking forward to the experts' responses. > > Thanks in advance. > > From My iPhone > > 2010. 6. 20. 오후 2:36 Raj Singh <rsjen...@gmail.com> 작성: > > 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> > 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> >> 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>smoo...@us.ibm.com) >>> z/OS Communications Server TCP/IP Development >>> <http://www.linkedin.com/in/smoonen>http://www.linkedin.com/in/smoonen >>> >>> <graycol.gif>Jaemin Park ---06/18/2010 10:51:53 AM---Dear All, >>> >>> <ecblank.gif> >>> From: <ecblank.gif> >>> >>> Jaemin Park < <jmpar...@gmail.com>jmpar...@gmail.com> >>> <ecblank.gif> >>> To: <ecblank.gif> >>> <ipsec@ietf.org>ipsec@ietf.org <ecblank.gif> >>> Date: <ecblank.gif> >>> >>> 06/18/2010 10:51 AM >>> <ecblank.gif> >>> Subject: <ecblank.gif> >>> >>> [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>IPsec@ietf.org >>> <https://www.ietf.org/mailman/listinfo/ipsec> >>> 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>jmp...@kt.com, <jmpar...@gmail.com>jmpar...@gmail.com >> >> _______________________________________________ >> IPsec mailing list >> <IPsec@ietf.org>IPsec@ietf.org >> <https://www.ietf.org/mailman/listinfo/ipsec> >> https://www.ietf.org/mailman/listinfo/ipsec >> >> >
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
