Re: [IPsec] Fwd: New Version Notification for draft-sprasad-ipsecme-labeled-ipsec-00.txt (fwd)

["Hu, Jun (Nokia - US/Mountain View)" <[e-mail]>]

> -----Original Message-----
> From: Paul Wouters [mailto:[e-mail]]
> Sent: Tuesday, March 06, 2018 5:53 PM
> To: Hu, Jun (Nokia - US/Mountain View) <[e-mail]>
> Cc: [e-mail] WG <[e-mail]>; Sahana Prasad
> <[e-mail]>
> Subject: RE: [IPsec] Fwd: New Version Notification for draft-sprasad-ipsecme-
> labeled-ipsec-00.txt (fwd)
> 
> On Tue, 6 Mar 2018, Hu, Jun (Nokia - US/Mountain View) wrote:
> 
> > Some initial questions/comments:
> > 1. security label is defined as opaque data in the draft, but then how
> > would narrowing work in an inter-op way with opaque data? Or should we
> > define the format for some common use cases (like security
> > enforcement, QoS ...) , and adding a sub-type in TS_SECLABEL
> 
> The idea was that people should be able to define this outside of IKE as they
> wish. And IKE just transports the label as-is. Of course, if IKE can interpret it to
> do something, then it can possibly do more, like narrowing.
> 
> I think usually the two endpoints will only have one type of SECLABEL, so the
> type is implicit to the IKE protocol. If you have different subtypes, then
> presumably if the subtype is wrong, you can't accept it, so the type is already
> known on both ends and doesn't need to have its own registry?
> 
[HJ] sound like you want to treat this as vendor specific, I am fine if for certain use case you don't want to include interpretation of SECLABLE in the draft;
But for certain common use case, like Qos (or service class), if we want implementation from different vendor to inter-op, we should define a clear format for it; either in this draft, or we could have separate draft to define use case ,format and narrowing rule;
That's why I think we could have a sub-type here, leave one value for vendor specific, but define some other sub-types for common use cases


> > 2. currently there are TSi (44) and TSr (45) payload, does it make sense to
> include TS_SECLABEL in either TSi or TSr? Is there semantic to have separate
> "initiator SECLABEL" and "responder SECLABEL"? Or does it make more sense
> to only allow single TS_SECLABEL per message/CHILD_SA, and create a new
> TS payload type , put TS_SECLABEL in it ?
> 
> That would be giving it another Payload Type. I think it is really a traffic
> selector type payload, and not a non-traffic-selector payload.
> 
> Even if it is true that the label on both ends have to always match.
> But that's kind of similar to address family always needing to match.
> 
> Although there might be a case where one end is allowed to send traffic with
> SECLABEL Foo, but not allowed to receive traffic with that label, where TSi
> could contain a TS_SECLABEL entry, and TSr would not.
> 
> Another case that probably needs some attention is when there is more then
> one TS_SECLABEL. Does it mean two different types of security labels are
> meant, and both have to match? Or is it okay to pick any one of the labels?
> 
[HJ] again, I think this depends on the use case of SECLABEL, in case of service class, single SECLABEL make sense, but for other cases, maybe two different label make sense 
> Paul