On Thu, May 03, 2018 at 04:19:07PM +0300, Valery Smyslov wrote: > > It has to be a traffic selector. > > I agree that it must be a traffic selector. However, in my opinion the > way it is currently defined in the draft is wrong. > > According to RFC7296 the individual TSs in TS payload are combined > using logical OR for the purpose of deciding whether given packet > matches the selector. In particular, Section 3.13 of RFC7296 says: > > ... a packet matches a given TSi/TSr if it matches at least one of the > individual selectors in TSi, and at least one of the individual > selectors in TSr. > > The draft currently defines a new TS, that contains only security > label and no IP address, protocol and port information. Thus, it is > impossible with the current definition to express policy, that if > packet is going from IP1 to IP2 AND has a security label S, it must be > protected using the negotiated SA. If you put IP1 and S in TSi and IP2 > and S in TSr it will mean that packet EITHER going from IP1 to IP2 > (regardless of its security label) or ANY packet having security label > S (regardless of its IP addresses) is protected using the negotiated > SA.
I wish RFC4306 carried multiple TS payloads, one for each type, and that there were multiple types of them. Of course, that is one possible approach here: extend IKEv2 to allow multiple TS payloads (which would have to be treated as a conjunction). But if that route is not chosen, then you're correct that we'd need new TS payload types: > To fix this issue the draft should instead define two new traffic selectors - > TS_IPV4_ADDR_RANGE_SECLABEL and TS_IPV6_ADDR_RANGE_SECLABEL, > that would contain IP range, protocol and ports range (as RFC7296 > selectors), as well as the security label. This way the presence of > the security label will be an additional criteria for packet matching. Cheers, Nico -- _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
