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 |------------> | 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, jmpar...@gmail.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
