Subject: [IPsec] Additional charter items 3/4: Labeled IPsec

From: Tero Kivinen <[email-masked]>
Date: Fri, 16 Feb 2018 20:06:37 +0200

This charter text was not ready during the IETF 100, we just had very
short description about the item, and I think most of the people did
not really understand it.

The proposed charter text for this item is:

----------------------------------------------------------------------
Some systems support security labels (aka security context) as one of
the selectors of the SPD. This label needs to be part of the IKE
negotiation for the IPsec SA. non-standard implementations exist for
IKEv1 (formerly abusing IPSEC Security Association Attribute 10, now
using private space IPSEC Security Association Attribute 32001). The
work is to standarize this for IKEv2.
----------------------------------------------------------------------

Is that charter text clear enough? Is there enough people interested
in this?

Send your comments and whether you support adding this to the charter
to the ipsec list in next two weeks.
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Fri, 16 Feb 2018 20:15:53 +0200

> On 16 Feb 2018, at 20:06, Tero Kivinen <[email-masked]> wrote:
> 
> Is that charter text clear enough?

Yeah, I think anyone who’s heard of multilevel security understands what is proposed here.

> Is there enough people interested
> in this?

I guess, since MLS keeps coming up…

I’m not, but I’m not opposed to doing this as long as there’s no burden on non-supporting implementations.

> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Paul Wouters <[email-masked]>
Date: Fri, 16 Feb 2018 14:49:33 -0500 (EST)

> The proposed charter text for this item is:

I brought it in, so I do agree it is clear enough. And after talking to
some people in the working group, it seems this is ideally done using a
new traffic selector. That would also satisfy Yoav's concern that there
is no burden on implementations that dont want to support this.

I will co-author a draft on this in time for IETF 101 :)

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 19 Feb 2018 14:05:20 +0300

Hi,

> I’m not, but I’m not opposed to doing this as long as there’s no burden on non-supporting implementations.

+1

Regards,
Valery.

---

From: "Hu, Jun (Nokia - US/Mountain View)" <[email-masked]>
Date: Mon, 19 Feb 2018 17:52:24 +0000

I am also interested in this, since currently there is no good way to identify a CHILD_SA, current traffic selector is too cumbersome to be used as identifier, and in some cases can't be used as a consistent id; for example there are two types of traffic (same protocol/port, but different responder address) need to be put into two different CHILD_SA, however initiator doesn't know the responder address range in advance, currently there is no way for responder to differentiate; 

> -----Original Message-----
> From: IPsec [mailto:[email-masked]] On Behalf Of Paul Wouters
> Sent: Friday, February 16, 2018 11:50 AM
> To: Tero Kivinen <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [IPsec] Additional charter items 3/4: Labeled IPsec
> 
> I brought it in, so I do agree it is clear enough. And after talking to some
> people in the working group, it seems this is ideally done using a new traffic
> selector. That would also satisfy Yoav's concern that there is no burden on
> implementations that dont want to support this.
>