On Thu, May 03, 2018 at 08:45:15PM -0400, Paul Wouters wrote: > On Fri, 4 May 2018, Tero Kivinen wrote:
> > 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. > > I think this is true. Especially now it seems there is no narrowing to > be done from one security label to another one. It depends on the label system. For something like MLS you can narrow a label since labels actually represent label sets or ranges, the label being a bitmask of compartments and a classification level: you can always remove bits from the mask and reduce the classification level. That is, for some systems the labels can be narrowed (but not broadened). I expect that typically the maximal label ranges for each node will be carried by their credentials (e.g., certificates) or be looked up in directories. In this case, a TS or NOTIFY would only be usedo to narrow the label range for an SA further than the two nodes' maximal label ranges. When there is no need to do this, then there is no need for a TS or NOTIFY payload to carry a label [range]. I mentioned socket options before because, really, without them, it's just too hard for applications to drive narrowing of SAs. And I mentioned connection latching because without that socket options don't make much sense either. Incidentally, Solaris/Illumos have a socket option by which an application can request a narrowed SA... Solaris/Illumos also have a sort of minimal connection latching. Without APIs, there's almost no point to narrowing the label ranges of SAs as applications then have to resort to modifying IPsec policy, and often that's just ETOOHARD. Connection latching is essentially a way of delegating IPsec configuration changes to the ULP. > >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 would say "dictated by both ends", but yes :) Two nodes would have some label range/set each and a credential each asserting the node's label range. The data that can be sent from one to the other has to be labeled with a label that is in the recipient's label range. A node could send more-classified data than its local labels to another node that can accept it. Think of a military officer classifying a memo at a higher level than they can read. In general communication will be within the intersection of the two nodes' label ranges, but it can be asymmetric. The nodes might also be running processes with reduced label ranges. This should be a source of desire to narrow child SAs' label ranges. If narrowed SAs are used for some flow, then the label of the flow is informative. If there is no need to deliver that information from IPsec to the application, then there is not much point to labeling narrowed SAs in transport mode, except that SA lifetimes and flow (connection) lifetimes are not bound to each other... ....If a connection ends and its 5-tuple is reused later and a packet floating about is finally delivered, but with a now-incorrect label. My spidey sense says that you want to narrow and label the SAs, but maybe it's just a waste of resources. But if an application needs to know the label of a flow, and without the ULP or application protocol being able to carry it, then the only way to get at it is from the SAs used to protect the flow (see my comments about connection latching and socket options), in which case narrowing the SAs would help. In this case, too, APIs would be rather handy. And what about SG use cases? Here, I think an SG needs to see narrowed label choices for specific flows if it has multiple outbound routes for a given destination at different label ranges. That seems a bit unlikely to me, but I wouldn't know. Another possibility is that the SG's route to some node has a different label range than another node traversing the SA to the first node, in which case the SA needs to know the individual traffic flows' labels, and we should assume that there's no way to send those at the ULP, in which case we need narrowed SAs. (I'll note that SGs are the sort of application that can be expected to modify IPsec configuration on the fly as needed.) > >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. If there are multiple SAs whose traffic selectors match the 5-tuple, but at different labels, then a sender has to pick carefully. If we never narrow SAs, then it's probably safe to assume this just doesn't happen (why would it?), but narrowing SAs does happen, and is supported. If there is no matching SA, then one will have to be negotiated that matches the 5-tuple, including the flow's label. This all sounds to me a lot like labels are traffic selectors. Whether they are represented as such on the wire in IKE is another story, but their function really looks to me a lot like traffic selectors. > >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. > > This I don't like as much. I'd rather see a failure on the responder on > some critical flag payload it does not understand. Yeah, but it's not that big a deal to not have that failure on the responder. Presumably the initiator will just delete the then-useless SA, else the responder will hold that resource for a while. > But also, the initiator should not yet have Child SA's ? (but that might > be implementation specific) In that case the parent IKE SA may have a broader label range/set than the child SAs. If the responder can't handle the label the particular packet flow needs and the initiator knows it, then the initiator should not even bother creating a child SA pair for that flow. Again, this could only happen if the application somehow conveyed the narrowed label range to the IPsec layer... > >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. Assuming the label ranges/sets are carried by the nodes' credentials, then there is no need for a label proposal unless the nodes wish to narrow the resulting SAs' label ranges. An empty intersection of the two nodes' label ranges would be an error in a MAC system, and the IKE SA establishment will not complete, let alone the child SA establishments. > >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. I mean, it can work fine. Notionally, ISTM that a pack flow's 5-tuple and label both are used to select SAs, therefore labels are -at least notionally- traffic selectors. Nico -- _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
