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:ipsec-boun...@ietf.org] On Behalf Of Paul Wouters
> Sent: Friday, February 16, 2018 11:50 AM
> To: Tero Kivinen <kivi...@iki.fi>
> Cc: ipsec@ietf.org
> Subject: Re: [IPsec] Additional charter items 3/4: Labeled IPsec
> On Fri, 16 Feb 2018, Tero Kivinen wrote:
> > 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?
> 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
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
IPsec mailing list

Reply via email to