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

From: Paul Wouters <[email-masked]>
Date: Mon, 5 Mar 2018 10:35:43 -0500 (EST)

Sahana and I wrote the initial draft for Labeled IPsec. I'm not sure
why it didn't auto-email the list, so links follow below. Please
discuss :)

Paul

A new version of I-D, draft-sprasad-ipsecme-labeled-ipsec-00.txt
has been successfully submitted by Sahana Prasad and posted to the
IETF repository.

Name:		draft-sprasad-ipsecme-labeled-ipsec
Revision:	00
Title:		Labeled IPsec Traffic Selector support for IKEv2
Document date:	2018-03-04
Group:		Individual Submission
Pages:		6
URL:            https://www.ietf.org/internet-drafts/draft-sprasad-ipsecme-labeled-ipsec-00.txt
Status:         https://datatracker.ietf.org/doc/draft-sprasad-ipsecme-labeled-ipsec/
Htmlized:       https://tools.ietf.org/html/draft-sprasad-ipsecme-labeled-ipsec-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-sprasad-ipsecme-labeled-ipsec-00

Abstract:
    Some IPsec implementations support Security Labels otherwise known as
    Security Contexts, to be configured as a selector within the Security
    Policy Database (SPD) for IPsec SAs.  This document adds support to
    IKEv2 to negotiate these Security Labels or Contexts using a new
    Traffic Selector (TS) Type TS_SECLABEL.  The approach is named
    "Labeled IPsec".  It assumes that the SPD processing of RFC 4303 is
    already extended to support Security Labels.  This document only adds
    the ability for IKE to negotiate the Security Labels used with the
    SPD.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: "Hu, Jun (Nokia - US/Mountain View)" <[email-masked]>
Date: Tue, 6 Mar 2018 23:52:08 +0000

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
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 ?

> -----Original Message-----
> From: IPsec [mailto:[email-masked]] On Behalf Of Paul Wouters
> Sent: Monday, March 05, 2018 7:36 AM
> To: [email-masked] WG <[email-masked]>
> Cc: Sahana Prasad <[email-masked]>
> Subject: [IPsec] Fwd: New Version Notification for draft-sprasad-ipsecme-
> labeled-ipsec-00.txt (fwd)
> 
> 
> 
> Sahana and I wrote the initial draft for Labeled IPsec. I'm not sure why it didn't
> auto-email the list, so links follow below. Please discuss :)
> 
> Paul
> 
> has been successfully submitted by Sahana Prasad and posted to the IETF
> repository.
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Paul Wouters <[email-masked]>
Date: Tue, 6 Mar 2018 20:52:55 -0500 (EST)

> 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 secur…

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?

> 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…

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?

Paul

---

From: "Hu, Jun (Nokia - US/Mountain View)" <[email-masked]>
Date: Wed, 7 Mar 2018 04:19:00 +0000

> From: Paul Wouters [mailto:[email-masked]]
> Sent: Tuesday, March 06, 2018 5:53 PM
> To: Hu, Jun (Nokia - US/Mountain View) <[email-masked]>
> Cc: [email-masked] WG <[email-masked]>; Sahana Prasad
> <[email-masked]>
> Subject: RE: [IPsec] Fwd: New Version Notification for draft-sprasad-ipsecme-
> > 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.
> 
> 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