Hi, after reading draft-ietf-ipsecme-labeled-ipsec-04 I have a couple of comments.
First, it's not clear for me why zero length TS_SECLABLE is prohibited. The draft currently says A zero length Security Label MUST NOT be used. If a received TS payload contains a TS_TYPE of TS_SECLABEL with a zero length Security Label, that specific Traffic Selector MUST be ignored. I wonder what's rational behind this restriction. From my point of view zero length TS_SECLABLE can be used to express that using Security Labels is optional. I.e. initiator can include zero length TS_SECLABEL Traffic Selector along with other TS_SECLABEL Traffic Selectors to indicate that responder is free to not use security labels for the SA. Currently draft suggests the initiator to perform several attempts to establish IPsec SA with and without TS_SECLABEL Traffic Selectors in such situation, which is more complicated and less efficient. Am I missing something? Another my concern is that draft allows security labels to differ in TSi and TSr without giving any possible semantic interpretation for this. This looks weird. I think that at least some possible interpretation of such situation must be given, e.g. TS_SECLABEL in TSi is used for traffic from initiator to responder and TS_SECLABEL in TSr is used for the return traffic. In this case it is clear that they can differ in some situations. And the last (but not the least). It seems to me that Section 3 (which aims to update Section 2.9 of RFC 7296) oversimplifies the negotiation process. In particular, the sentence A responder MUST create its TS response by selecting one of each TS_TYPE present in the offered TS by the initiator. is inaccurate in my opinion, since it implies (as I read it) that responder can pick exactly one traffic selector of each TS_TYPE and can only return it unmodified. If fact, with regard to TS_IPV4_ADDR_RANGE and TS_IPV6_ADDR_RANGE, all the proposed traffic selectors are semantically combined and represent the set of traffic the initiator believes is appropriate for the SA. The responder then can select several traffic selectors from the proposed list and even modify some or all of them provided that the resulted set of traffic they represent is a subset of set of traffic proposed by the initiator. This logic is lost in the draft and since the draft intends to update RFC 7296 in this regard, readers may decide that this logic is no more actual. In this Section 3 must be rewritten to describe the changes more accurately. Regards, Valery. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
