-----Original Message----- From: Paul Wouters <p...@nohats.ca> Sent: Friday, December 13, 2019 6:51 AM To: Hu, Jun (Nokia - US/Mountain View) <jun...@nokia.com> Cc: ipsec@ietf.org WG <ipsec@ietf.org>; Sahana Prasad <sah...@redhat.com> Subject: RE: [IPsec] Labeled IPsec options
On Fri, 13 Dec 2019, Hu, Jun (Nokia - US/Mountain View) wrote: >> If you select multiple TS's these all become part of one Child SA. So I >> think the granularity of the label does not change between the solutions? > > [Hu Jun] if we agree that label is per CHILD_SA, then with option 1 or 2, > there is possibility for invalid TS combination, following are some examples > of invalid TS: > - with option-1: There are two TS in TSi, first TS contains label-1, > 2nd TS contains label-2 This issue is similar to network ranges though. Say you want to have: 10.0.1.0/24 <-> 192.168.0.0/16 10.0.2.0/24 <-> 172.16.100.0/24 Then you can also not have a TSi containing 10.0.1.0/24, 10.0.2.0/24 and a TSr containing 192.168.0.0/16, 172.16.100.0/24 With 10.0.1.0/24+SEC_LABEL1 and 10.0.1.0/24+SEC_LABEL2 youl have a similar issue, that is you would need to use a seperate CREATE_CHILD_SA to prevent the mixup of TS elements. [Hu Jun] since this label is new, ideally we should avoid to have such similar issue; and if this the label is per CHILD_SA, then of course it will require multiple CHILD_SA to have multiple labels, I don't think that's an issue. So again, I think WG need to get a consensus on the granularity of label before an option could be decided , is it per tunnel, per CHILD_SA or per TS? for me it is per CHILD_SA > - with option-2: TSi contains label-1, while TSr contains a different > label-2 Yes, see above. > With option-3/4 there is no such concern Since the notify or new payload type would be the same for all other TS parts, you do have the same problem. [Hu Jun] sorry, but I fail to see why option-3/4 have same problem if the label is per CHILD_SA and semantic of new notification/payload is for the whole CHILD_SA You also need a different CREATE_CHILD_SA negotiation to specify the different label. So I don't think what you describe is a new issue only affecting some of the solution options. All solutions need a similar workaround to prevent the mixup. Paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
