[IPsec] Comments for draft-ietf-ipsecme-labeled-ipsec-04

[Valery Smyslov <[e-mail]>]

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.