Valery Smyslov writes: > Hi Tero, > > few comments inline. > > [a lot of text snipped] > > > This document should simply say that TS_SECLABEL MUST NOT be used > > alone. This document must not try to do incompatible change to the > > base RFC7296 which would make conforming implemntations > > non-conforming. > > Unfortunately, this won't work. It is not enough to add new TS type, > with security labels the semantics of TS types should be changed > so, that there are "primary" TS types and "additional" ones.
Yes, but that change should not affect any other TS type than TS_SECLABEL. > This is because in RFC 7296 individual Traffic Selectors in TS payload > are combined with OR. In other words, traffic matching > combination of any Traffic Selector in TSi and > any Traffic Selector in TSr is protected. > > TS_SECLABEL cannot be treated with this semantics, > it must be treated with AND (as additional condition for > the traffic to match), which requires RFC 7296 update. No it does not. Nothing in this RFC will change any behavior of any of the existing implementations, and there is no need for existing implementations to be updated to this AND behavior. Only implementations who implement TS_SECLABEL need to know the special processing of it. If the initiator does not support TS_SECLABEL, it will never send them, and there is no issues. If the responder requires TS_SECLABEL it will return TS_UNACCEPTABLE, and the negotiation fails. If the initiator does support TS_SECLABEL, but responder does not, then it will send TS_IPV*_ADDR_RANGE and TS_SECLABEL, and the responder will only return with TS_IPV*_ADDR_RANGE. The initiator should notice there is no TS_SECLABEL, and if that TS_SECLABEL was mandatory then it should delete the SA, and fail the negotiation. As the responder does not support TS_SECLABELs, there is no security issue for it sending data to IPsec SA, as it does not support security labels that would forbid such operation. As the initiator never installs the SA which does not have proper TS_SECLABEL there is no security issues there as it will never receive or send any traffic to that SA that got deleted immediately as it was never installed. So the text in draft saying: If the Security Label traffic selector is optional from a configuration point of view, the initiator will have to choose which TS payload to attempt first. If it includes the Security Label and receives a TS_UNACCEPTABLE, it can attempt a new Child SA negotiation without that Security Label. does not match with that it needs to be updated to: If the Security Label traffic selector is optional from a configuration point of view, the initiator will try with TS_SECLABEL. If the responder includes TS_SECLABEL, then IPsec SA with that Security Label got created. If the responder did not include TS_SECLABEL in its response, then it does not support (or its policy does not allow) them, thus if the TS_SECLABEL was optional in the initiator then it can accept that SA. If the TS_SECLABEL was mandatory in the initiator policy, then it MUST not install the SA, and MUST send delete the Child SA using Delete notification. I.e., there is no need for it to try with two different CREATE_CHILD_SA exchanges, it can simply try with one, that has both TS_IPV*_ADDR_RANGE and TS_SECLABEL, and responder will return either TS_IPV*_ADDR_RANGE only or both. If the responder does not support TS_SECLABEL, it will never pick that one, and if it does support TS_SECLABEL, it knows it MUST NOT return only that, it also needs to include TS_IPV*_ADDR_RANGE selectors. I rather have the complications of processing TS_SECLABEL in the implementations that support it, and not cause all old implementations to suddenly be non-conforming as they do not follow this MUST added here: A responder MUST create each TS response by creating one of more (narrowed or not) TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE entries, plus one of each further TS_TYPE present in the offered TS by the initiator. If this is not possible, it MUST return a TS_UNACCEPTABLE Error Notify payload. I.e., that it MUST return all other TS_TYPEs or if it does not understand them it MUST return TS_UNACCEPTABLE... This makes adding TS_TYPES really hard in the future, as if we add TS_MY_TEST_TYPE, then every single implemenation will always return TS_UNACCEPTABLE to me if it does not support it, and I must do two exchanges one with it, and another without it if the first one fails. > I agree with you that current document text doesn't take into > considerations the existence of other "primary" TS types, like > TS_FC_ADDR_RANGE. I think all TS types are "primary" except this TS_SECLABEL one as this is how RFC7296 defines them. y > > So I do not think this document should update RFC7296 at all, so most > > of the section 3 is wrong. > > The "proper" way would be to introduce new TS types > TS_IPV4_ADDR_RANGE_WITH_SECLABEL and TS_IPV6_ADDR_RANGE_WITH_SECLABEL. > I recall that it was already tried before, but I don't remember > why this way was abandoned. I think the reason was that it would cause combinatory explosion of things. I.e., if you have 4 IPv4 ranges and few ipv6 ranges, and couple of security labels, you would need lots more ts payloads as security labels do not have narrowing defined for them. I.e., you would need one TS_IPV*_ADDR_RANGE_WITH_SECLABEL for each seclabel repeating all the address information in all of them, and then you would most likely still want to include TS_IPV*_ADDR_RANGE in case the seclabels are optional. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
