Re: [IPsec] WGLC of draft-ietf-ipsecme-labeled-ipsec

[Valery Smyslov <[e-mail]>]

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:[e-mail]] On Behalf Of Tero Kivinen
> Sent: Tuesday, July 27, 2021 1:45 AM
> To: [e-mail]
> 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.
> --
> [e-mail]
> 
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec