Hi, > > So in a way, a NOTIFY might make sense. But then we do run the risk of > > an IPsec SA being installed with the notify ignored using a default > > security context instead of the security context required. Having it > > as part of the TSi/TSr payloads makes that a lot more clear. > > > Thoughts? > > 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. 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. Regards, Valery. _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
