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
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
