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