Hi, sorry for being late, the GGLC is already over, but I was really busy to review the draft before.
I have few comments. 1. Section 1.2. The last para is erroneous here, since the immediately following the first para of Section 1.3 states exactly the same with more details. Either remove it or rephrase and move to 1.3 (e.g. to keep provided example). 2. Section 2.2. If the TS_SECLABEL is present in a TSi/TSr, at least one Traffic Selector of type TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE MUST also be present in that TSi/TSr. I think this requirement was already spelled out in more generic form in 1.3. Why it is repeated here? 3. Section 2.2 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. If no other Traffic Selector of TS_TYPE TS_SECLABEL can be selected, a TS_UNACCEPTABLE Error Notify message MUST be returned. A zero length Security Label MUST NOT be interpreted as a wildcard security label. I wonder why zero-length TS_SECLABEL cannot be used to represent "no security label"? This would significantly simplify negotiation when using security labels are optional for initiator. Currently it is proposed that initiator performs two attempts to establish Child SA in this case - with and without TS_SECLABEL. If zero-length TS_SECLABEL meant "no security label", then a single CREATE_CHILD_SA would be sufficient. It would also simplify the IKE state machine for this case. Are there any reasons I'm not aware of? 4. Section 2.2 If multiple Security Labels are allowed for a given IP protocol, start and end address/port match, multiple TS_SECLABEL can be included in a TS payload. This sentence is unclear for me. If the initiator includes multiple TS_SECLABEL, does it mean that the responder must select exactly one of them or not? If yes, then can you please clarify, that the presence of multiple TS_SECLABEL means that selection any of them is acceptable for the initiator. 5. Section 2.2: What is "TS_set", which is mentioned twice in the last para? This acronym was never used before in the dicument. 6. Section 3. Each TS payload (TSi and TSr) MUST contain at least one TS_TYPE of TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE. This is repeated for the third time in the document. Can you please keep the only instance of this requirement? 7. Section 3. A responder MUST create its TS response by selecting one of each TS_TYPE present in the offered TS by the initiator. If it cannot select one of each TS_TYPE, it MUST return a TS_UNACCEPTABLE Error Notify payload. and later Some TS_TYPE's support narrowing, where the responder is allowed to select a subset of the original TS. Narrowing MUST NOT result in an empty selector for that TS_TYPE. This is wrong with regard to TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE. The responder may return any subset of TSs with TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE. E.g, if the initiator included 5 TSs with TS_IPV4_ADDR_RANGE and 3 with TS_IPV6_ADDR_RANGE, then the responder is free to return (just as example) only 2 TS_IPV4_ADDR_RANGE and no TS_IPV6_ADDR_RANGE, and all of them may have different content (due to narrowing). I think this paras must be rephrased more accurately. 8. Section 3.2: It would be unlikely that the traffic for TSi and TSr would have a different Security Label, but this specification does allow this to be specified. Can you please provide some examples of possible semantics of different TS_SECLABELs in TSi and TSr? Sending different security labels in different directions? Just for curiosity. 9. Section 3.2: Rekey of an IPsec SA MUST only use identical Traffic Selectors, which means the same TS Type and selectors MUST be used. This guarantees that a Security Label once negotiated, remains part of the IPsec SA after a rekey. I think it is a too strong requirement. Traditionally in IKEv2 the rekey operation is equivalent to creating a new Child SA with full negotiation of algorithms and TSs. I know that there is an effort to make thing simpler in most cases, but I don't think status quo should be changed for generic case. I prefer to remove this para. Regards, Valery. > -----Original Message----- > From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Tero Kivinen > Sent: Tuesday, July 27, 2021 1:45 AM > To: ipsec@ietf.org > Subject: [IPsec] WGLC of draft-ietf-ipsecme-labeled-ipsec > > This is the start of 2 week WGLC on the > draft-ietf-ipsecme-labeled-ipsec document, ending 2021-08-10. > > Please submit your comments to the list, also send a note if you have > reviewed the document, so we can see how many people are interested in > getting this out. > -- > kivi...@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec