Re: [IPsec] WGLC of draft-ietf-ipsecme-labeled-ipsec

[Paul Wouters <[e-mail]>]

On Wed, 3 Nov 2021, Valery Smyslov wrote:

> It can represent optionality of the security label.

An optional security label has no meaning. If you have
a real case of optional security labels, lets year it. Otherwise,
I think we should move on without supporting optional security
labels. From a security point of view, it just makes no sense. From
a migration point of view, it can be done without further protocol
support.

>> It is too ambiguous with "no security label". It makes
>> common sense to me to simply not allow it. And comparing a 0 size NULL
>> with a zero byte also seems just way to risky.
>
> I failed to understand why do you think implementers are so stupid,
> that even such a primitive task would run them into problems.

Experience reading and acting on opensource code ?

>> Ideally, I would have
>> stated "a minimum length of one non-zero octet".
>>
>> I guess we need to get other people's opinion on this.
>
> OK, let's wait for other opinions.

Okay, good.

>> In our implementation you can define two "conns", one with and one
>> without. And choosing the right one will work. On the responder, there
>> is a connection switching mechanism that can switch to the better
>> matching connection once the TS payloads are read from IKE_AUTH. So
>> first you add all the conns with sec_label. And after a while, you can
>> just remove all the conns without sec_label.
>
> When upgraded initiator contacts not yet upgraded responder this won't work.

Correct. this assumes you have an established system of updating
configurations, like cloud/terraform based, or puppet or system roles
or ansible or what not.

> To make this case workable the initiator must implement a complex logic
> (first it tries TS with seclabels, then it receives TS_UNACCEPTABLE,
> which BTW may come due to any reason, but it guesses that it may be
> due to seclabels, and perform another attempt with no seclabels).
> This logic complicates IKEv2 state machine and may lead to more
> serious implementation errors.

I don't think this is a change to the state machine. It is a change
to the allowed configuration and/or default action. No state machine
changes are needed.

You can simple choose to not support the unlikely use case. Security
labels are dictated to systems _before_ you are allowed to access them.
The hypothetical upgrade case is not a real life deployment scenario.

Still, with todays automated (cloud) deployments, you first upgrade the
required software, then upgrade the required configuration files, then
let machines switch to the new behaviour.

> If you make TS_SECLABLE with no data an indication,
> that seclabels are optional for this connection, then it would
> require require minimum changes to IKE state machine and in fact
> is much safer with regard to implementation errors.

I fail to see how it would be safer to include a mechanism for
allowing for mismatched configurations to establish a less secure
connection ?

> And more efficient from protocol point of view.

Thie claimed efficiency is for a use case (upgrading via optional
security labels without configuration change) that I just don't see
a real life use case for. And it comes at a cost of complexity and
error handling of configuration mismatch cases that would be more
likely, not less likely, to be prone to errors.


>>>> Changed. Old text:
>>>>
>>>>     A responder that selected a TS with TS_SECLABEL MUST use the Security
>>>>     Label for all selector operations on the resulting IPsec SA.  It MUST
>>>>     NOT select a TS_set with a TS_SECLABEL without using the specified
>>>>     Security Label, even if it deems the Security Label optional, as the
>>>>     initiator TS_set with TS_SECLABEL means the initiator mandates using
>>>>     that Security Label.
>>>>
>>>> New text:
>>>>
>>>>     A responder that selected a TS with TS_SECLABEL MUST use the Security
>>>>     Label for all selector operations on the resulting TS. It MUST
>>>>     NOT select a TS_SECLABEL without using the specified Security Label,
>>>>     even if it deems the Security Label optional, as the initiator has
>>>>     indicated (and expects) that Security Label will be set for all
>>>>     traffic matching the negotiated TS.
>>>
>>> I'm a bit confused with the part of \new text:
>>>
>>> "...all selector operations on the resulting TS."
>>> What do you mean? Did you mean
>>> "on the resulting Traffic Selector"?
>>> Or am I missing something?
>>
>> I mean to say, if you pick a TS with TS_SECLABEL, you MUST have a
>> security label as part of your SPD selector mechanism. You cannot
>> decide to ignore it and only use IP address based SPD selectors.
>
> Isn't it obvious?

It is. But I wanted to clarify it because it might be that the IKE
daemon needs to "do something" to make that happen that goes beyond
installing an IPsec SA. I'm okay to leave it out.

>> In our implementation, using the selector means _setting_ the SElinux
>> context (sec_label) on the decrypted packet before releasing it to the
>> OS for further processing by the application. The application might make
>> security decisions based on the sec_label, so not "applying" the sec_label
>> negotiated would be a security violation of the negotiated policy.
>>
>> That is, things might appear to work but in fact might be working
>> without sec_label security and the remote peer has no way of detecting
>> this. It is trusting the peer to apply the security policy to the
>> packets.
>>
>> If you have a suggested text you prefer, please let me know.
>
> No, I just was wondering why you replaced "IPsec SA" with "TS" in this sentence.

Ok.

>>>> (I avoided talking about IPsec SA or Child SA, as one of those _may_
>>>> include multiple different TS'es)
>>>
>>> So what? I think that the essence of this text is that if TS_SECLABEL
>>> is used, then it is applied for the whole Traffic Selector for this Child SA.
>>> Am I missing the essence?
>>
>> I avoided talking about IPsec / Child SA because different ones can have
>> different negotiated TS_SECLABELS - eg they can be independent from the
>> exchange we are talking about. (I think we are saying the same thing?)
>
> Of course different IPsec SAs can have different Traffic Selectors.
> But you talked not about any IPsec SA, but about the IPsec SA that
> resulted from negotiation, which included Traffic Selector with seclabels:
>
> Old text.
>
>     A responder that selected a TS with TS_SECLABEL MUST use the Security
>     Label for all selector operations on the resulting IPsec SA.
>                                                                       ^^^^^^^^^^^^^^^^^^
>
> I think, that this sentence is more clear than the corresponding one from new text
> (the rest of new text is OK).

I'm okay removing it.

> Well, I still don't think that the idea, that this document defines a behavior
> for not yet defined TS_TYPEs and will need to be updated if the defined
> behavior is wrong, is a good engineering approach. But I can live with it.

I agree that RFC 7296 should have thought about it and specified it for
to be designed TS_TYPEs, but it didn't. So here we are.

> OK. I seem to understand the source of my confusion.
>
> With first para of Section 3.2 you seem to imply the following negotiation scenario:
>
> Initiator:
>   TSi = (TS_SECLABEL="nfs-client", TS_SECLABEL="nfs-server")
>   TSi = (TS_SECLABEL="nfs-client", TS_SECLABEL="nfs-server")
>
> Responder:
>   TSi = (TS_SECLABEL="nfs-client")
>   TSi = (TS_SECLABEL="nfs-server")
>
> Am I right?

No. Our implementation never uses more than one sec_label, due to the
nature of the sec_label. In our case, it basically comes from an ACQUIRE
message, so the IKE daemon has no way of determining that the reply to
a packet we send would require a different sec_label by the remote peer.
In fact, the IKE daemon does not even know if the reply traffic would
match the inbound SA sec-label or not. The remote peer's sec-label will
receive its own ACQUIRE if the return traffic has another sec-label set,
and will negotiate a second IPsec SA that only differs in label.


> If you mean this case, then it's a major change what the semantics of traffic selectors currently is.

I don't mean that.

> You seem to imply that with regard to seclabels matching the following logic applies:
> for outgoing packet to match SPD only TSi should be checked on initiator
> and only TSr on responder and visa versa for incoming packet.
> But this is not how it is defined in RFC7296 and how it works now -
> both TSi and TSr are checked for any packet.

I do not imply that.

> Unless I'm missing something and my speculations above are wrong,

It is.

> Either remove the possibility of having different seclabels in TSi and TSr
> or add clarification and describe, that this is another update for RFC 7296
> (and probably for 4301 too).

I do not believe our SElinux based labeled IPsec should limit how people
can use security labels in general.

Paul