Re: Labeled IPsec options

On Fri, 13 Dec 2019, Valery Smyslov wrote:

>>>> I don't think that matters. Security labels are never optional but
>>>> always mandatory. And it seems very unlikely to have a mix of child
>>>> sa's with and without label. So they will all have a label, and then
>>>> failing the  IKE SA is fine,
>>>
>>> Do you want to say, that it's impossible to have two SGWs with
>>> multiple networks behind them so, that traffic from some networks will
>>> have security labels and traffic from the others won't have?
>>
>> I'm not saying it is impossible. I am saying it is not likely to be a real
> life
>> configuration. If you classify network traffic with labels, your goal is
> to not
>> have unlabeled traffic come in at all. You might have a label
> SEC_WHATEVER,
>> but it still seems far more likely you would mark the traffic as having
> come
>> from SGWx with some kind of LABELx to track the origin throughout your
>> network.
>>
>>> If such a configuration is possible, then it's perfectly OK to have a
>>> mix of labelled and non-labelled IPsec SAs created by one IKE SA.
>>
>> I'd argue the reverse. It would likely be better not to allow such an
> awful
>> configuration :)
>
> So, am I right that you want all IPsec SAs created from a single IKE SA to
> either
> have labels or not?

I described what I think are real life scenarios between two gateways. I
was not specifying whether did appeared in a single IKE SA or a single
IKE_AUTH/CREATE_CHILD_SA.

See my previous email how we also have IPV4 ranges that we find are not
combinable and thus we need to use a seperate CREATE_CHILD_SA to install
the subset of allowed v4 combinations. The same would apply to labels.

> If so, then it looks like an IKE SA property, and thus
> an ability
> to use labels should really be negotiated when IKE SA is created

I don't think there is a need to ban the option to do it in seperate
exchanges. I don't think we need to force admins to create two IKE SA's
between the same endpoints to get labeled and unlabeled IPsec SA's.

> (well, I don't care whether it is SECLABELS_SUPPORTED or SECLABELS_REQUIRED
> notification :-)). And since peers know that seclabels are supported, we
> won't
> have any problems with legacy implementations (for example, the responder
> cannot ignore label in notification in option 3).

Sure, but one suggests the code can do it, the other suggests the
configuration insists on it. It avoids the implementor question of
"if we understand seclabels, but this connection does not use/require
them, should I answer a SECLABELS_SUPPORTED notify with a reply?".

Paul