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.
- 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. 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
