> 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.
Migration is not the only use case. For closed environments I tend to agree with you. But for open environments, you generally don't know whether peer that you contact for the first time supports security labels or not. As far as I understand, there is pretty limited support for them in OSes, so the use case when initiator proposes both using security labels and not using them makes sense for me. After all, initiator's policy will control which traffic it is willing to send over the SA depending on whether security labels are supported by the peer. > >> 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 ? No. Just my opinion. > >> 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. Please, see above another scenario. > > 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 have to somehow handle the case when the responder returns TS_UNACCEPTABLE. Currently it's a fatal error (requires changing local policy). In your case implementations will need to handle it properly. > 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. You are talking here about closed homogenous system. I don't think it's so simple in multi-domain heterogenous systems, that are not controlled from a single center. > > 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 ? By "safer" I meant less implementation errors. > > 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. See another use case above. And of course optionality must be controlled via local configuration, so it is not built in the protocol. If initiator's policy states, that security labels are optional, it includes an empty TS_SECLABEL along with others, if not - it doesn't. So I'm puzzled why you write "without configuration change". > >>>> 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. OK, please. > >>>> (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. Or retain the old text for the first sentence (cited above). > > 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. OK, this all is clear and aligned with my understanding. > > 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. Here I'm lost completely. If my guess of what the first para of Section 3.2 means to say was wrong, then can you please clarify its meaning? If it is not about selecting different security labels in TSi and TSr by the responder, then what it is about? Regards, Valery. > Paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
