Michael Richardson writes: > > It has to be a traffic selector. > > It has to be a traffic selector so that it can be selected (so do labeled > IPsec SA), or not selected (do not do it). Any other mechanism > (notification) can not be unambiguously rejected by a responder.
Not true. Traffic selectors in IKEv2 do have very strict processing rules, and for most of the cases I do not think security labels will follow those rules, or trying to force the security labels to follow those rules will just cause confusion. This includes ORing the different selectors together, narrowing any traffic selectors to include any subset of the original selectors, combining traffic selectors as long as the combined selectors are not wider than what was originally proposed etc. All of these will not really make traffic selectors suitable for the security label use. My understanding is that security labels are something that is dictated by the one end, and other end must agree on that and then both ends will be matching and marking the packets with suitable security labels when it goes to the SA and comes out from the SA. I.e., when kernel has packet going out to some IPsec SA tunnel, it will check the security label associated with the packet (or socket, or interface or whatever), and finds one IPsec SA which matches both the security label and also allows the packet to be sent to that SA (i.e., matches both traffic selector and the security label). When the other end gets packet from the IPsec SA which is tied to certain security label, it will do normal exit tunnel checks by checking the traffic selectors, and then it will MARK the packet with security label associated with the IPsec SA, so that when it is going forward it will have correct security label associated to it. To allow that is is completely possible to do this negotiation using notify payloads. I.e., initiator sends SECURITY_LABEL status notification to the other end which includes the security label to be associated to this Child SA. If the other end agrees on the proposal, it will reply with the SECURITY_LABEL notify payload containing exactly same security label than what was proposed by the other end (or simply empty data as actually the label does not matter here as only thing that matters is that both ends agree on same security label). If other end does not understand SECURITY_LABEL notify at all, it will ignore it and initiator will see this and can tear down the Child SA, and indicate that other end does not support security labels. If other end do support the security labels, but do not accept this policy, it can either return NO_PROPOSAL_CHOSEN if it does not want to indicate why proposal was unacceptable, or we might add new error notification INVALID_SECURITY_LABEL which indicates that proposal was otherwise ok, but security label was not unacceptable. This is similar to how we negotiate transport mode in IKEv2, i.e., initiator includes USE_TRANSPORT_MODE notify, and responder confirms it by sending it too. NON_FIRST_FRAGMENTS_ALSO does about same thing. IPCOMP_SUPORTED does bit more complicated negotiation inside the notify payloads, initiator proposes list, and responder picks one. SIGNATURE_HASH_ALGORITHMS negotiation for RFC7427 does yet another different type of negotiation inside notify payloads. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
