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

[Valery Smyslov <[e-mail]>]

Hi Paul,

> > 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.
> 
> We did discuss this earier in the WG. There is no use case of "optional"
> security labels. You either insist on these, or you don't use these.

Well, it contradicts what draft says (Section 2.2):

   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.

So you do allow security label to be optional, but negotiate its usage this 
with most complex and ineffective way. It's very strange.

> Implementing "optional" ones by using a zero length label is asking for
> implementation problems. Especially when people consider these labels
> as strings and run strlen() on the empty (but NULL terminated string)
> and interpret that as wildcard.

Well, people will consider meaning of the security labels in accordance 
to what is written in the draft. If we try to envision every possible mis-reading
of the documents we'd better not to start writing them...

And BTW zero length means that there are no any content, including NULL terminator :-)

> Since there is no use case, and significant implementation danger, the
> document makes an explicit case to reject these. Our implementation
> will return TS_UNAVAILABLE if it encounters any zero length TS_SECLABEL.

No, the document does allow optional security labels, see above.

> > 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?
> 
> It was what the WG preferred to do. The reasoning was that labels are
> surely very much preconfigured and connections will not be migrated
> from "no security" to "security label" where the operator wants to
> operate insecurely first. That is, opportunistic security labels is
> not a thing.
>
> The case you describe is very unlikely. Either the endpoints wants a
> label or doesn't want one. optional security is not security.

Then why text in 2.2 allows the initiator to choose between using them 
and omitting them? Isn't it exactly what you just described as "not security"?

> > Another my concern is that draft allows security labels to differ
> > in TSi and TSr without giving any possible semantic interpretation for this.
> 
> Correct. But the label is clearly defines as opaque to the IKE layer.
> The IKE layer should not be making any kindds of assumptions or
> interpretations, but just relay this to the underlying label security
> consumer (eg in our case the LSM of SElinux). Note that our
> implementation only supports symmetrical labels so far, because
> that is how SElinux labeling works. But the protocol can accept
> other methods.

I still prefer _some_ words to be added about _possible_
semantics when seclabels are different in TSi and TSr.

> > 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.
> 
> I'm not sure why this is not clear? TSi and TSr entries apply to
> one direction.  TS_SECLABEL does not change that.

It's unclear what this case could mean:

         TSi = ((0,0,198.51.0-198.51.255),
                TS_SECLABEL1)

         TSr = (((0,0,203.0.113.0-203.0.113.255),
                TS_SECLABEL2)

It's true that IKE doesn't interpret seclabels, but it usually
does some sanity checks and as implementer I'm not sure whether
this is allowed (what does it mean?) or not.

> > 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.
> 
> Again, we followed the consensus of the group here.
> 
> > 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.
> 
> How about this clarification:
> 
>  	A responder MUST create its TS response by selecting at least
>  	one of each TS Type.  One exception is that a responder MAY omit
>  	a TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE as long as at least
>  	one TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE is selected.
>  	Furthermore, a narrowed TS_IPV4_ADDR_RANGE and TS_IPV6_ADDR_RANGE content
>  	set MAY be selected.

Much better, thank you. For best clarity I would have added a sentence that this draft
doesn't change a logic described in Section 2.9 of RFC 7296 for 
types TS_IPV4_ADDR_RANGE and TS_IPV6_ADDR_RANGE, it only
defines additional rules for how TS_SECLABEL traffic selectors are negotiated.

Regards,
Valery.

> Note that this is mentioned already in section 1.2:
> 
>     A Traffic Selector payload (TS) is a set of one or more Traffic
>     Selectors of the same or different TS_TYPEs, but MUST include at
>     least one TS_TYPE of TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE.
> 
> If you prefer other text, please provide your suggestion.
> 
> Paul