> -----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 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 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
