Re: [IPsec] Labeled IPsec options

["Hu, Jun (Nokia - US/Mountain View)" <[e-mail]>]

-----Original Message-----
From: Paul Wouters <[e-mail]> 
Sent: Friday, December 13, 2019 6:51 AM
To: Hu, Jun (Nokia - US/Mountain View) <[e-mail]>
Cc: [e-mail] WG <[e-mail]>; Sahana Prasad <[e-mail]>
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