> -----Original Message-----
> From: Paul Wouters [mailto:p...@nohats.ca]
> Sent: Tuesday, March 06, 2018 5:53 PM
> To: Hu, Jun (Nokia - US/Mountain View) <jun...@nokia.com>
> Cc: ipsec@ietf.org WG <ipsec@ietf.org>; Sahana Prasad
> <sahana.prasa...@gmail.com>
> 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 
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
IPsec mailing list

Reply via email to