On Monday 07 December 2009 07:41:21 pm Nicolas Williams wrote: > On Mon, Dec 07, 2009 at 06:59:13PM -0500, Paul Moore wrote: > > On Monday 07 December 2009 06:20:31 pm Dan McDonald wrote: > > > On Mon, Dec 07, 2009 at 05:53:59PM -0500, Paul Moore wrote: > > > > Why spend the time and effort to develop two specifications (not to > > > > mention the actual implementations) when one IP option based labeling > > > > spec could solve both use cases at the same time? > > > > > > Because sometimes you want to put sensitive traffic on public networks, > > > without the overhead of tunnel mode (until we can get the world to go > > > beyond 1500-byte datagrams, overhead IS a problem). > > > > It is worth noting that this does introduce a scalability concern in the > > case where a system communicates with another using a large number of > > security labels. It is only made worse on systems that have "rich" > > security labels which consist of more than just MLS attributes; e.g. > > SELinux labels contain user, role, type and MLS ranges, each unique > > combination represents a new label and in the case of labeled IPsec, a > > new SA. It is possible that a traditional, unlabeled IPsec configuration > > which would only use a single SA could potentially expand to several > > thousand SAs depending on the number of security labels in use for that > > particular policy. We've already seen issues related to this with > > SELinux. > > For any discrete packet flow (say, a TCP connection), it makes no sense > to have more than one label or clearance range. Thus at worst you end > up with a narrowed SA pair (or two, during re-keys) per-flow. > > For protocols like NFS you'd have to do labelling in the protocol. > I.e., for NFS you'd let IP/IPsec determine the labels/clearances of the > client and server, and then the client and server would deal with > labelling of files and user processes'/threads' actions. > > IOW, the number of SAs will be bounded by the number of concurrent, > discrete packet flows, not by the number of labels.
I agree that it only makes sense to assign a single label to a discrete packet flow, no argument there. If you re-read what I wrote I wasn't talking about an individual connection/flow between two nodes but rather the general case of IPsec protected communications between two nodes. The point I'm trying to make is that labeled IPsec adds the flow's security label to the SA's traffic selector which has the potential to increase the number of SAs on the system by making the SAs more selective. For example, it is possible to configure a SPD such that all communication between two nodes is protected with a single SA; if labeled IPsec is used, the number of SAs in use would grow to equal the number security labels used in communications between the two nodes. If the two systems only communicate with label "Coke" then only a single SA is needed. However, if the two systems have two or more communication channels using with at least one channel using "Coke" and another using "Pepsi" then two SAs will need to be created to convey the two unique security labels. You can easily see how this example can be applied with finer grained SPDs as well. > > Also, on the topic of performance, labeled IPsec requires that the IPsec > > processing occur at the end node making it impossible to offload IPsec to > > a gateway. On small or heavily loaded systems this can quickly outweigh > > any advantages gained by decreased header sizes. > > I don't see why you believe this. What don't you understand, that labeled IPsec requires IPsec processing to occur at the end node or that requiring IPsec on small devices can incur more of a performance penalty than a separate labeling protocol? Perhaps I'm wrong about one of those statements, if I am I would appreciate help in understanding why. > > > IPsec SAs are perfect repositories for sensitivity information. > > > > There is a subtle problem with using SAs for labeling that hasn't really > > been discussed in this forum and may not be immediate obvious. All of > > the labeled security mechanisms I've seen generate the packet/SA's > > security label from the application which generates the network traffic > > (the sender). The fact that IPsec SAs are not tightly bound to > > applications/senders, instead relying on the traffic selectors to match > > packets to the SA, can make things more difficult for security policy > > developers and security administrators. As an example, compare the > > security policy required for both CIPSO and labeled IPsec traffic on a > > SELinux system. > > See RFC5660. See also the charter of the BTNS WG (though it's likely to > be concluded before completing IPsec API work). I just quickly skimmed RFC5660 and the BTNS charter so please correct me if I am misunderstanding things, but I don't see either the IPsec connection latching or BTNS charter having much impact on MAC security policies. Granted, the IPsec connection latching seems like an excellent idea but I'm fairly certain that systems which implement MAC using labeled security will still need to have MAC security policy in place to control (and provide the desired level of assurance) how IPsec SA based labeling is applied to network traffic; at least for implementations going through some form of security certification (I'm thinking Common Criteria). IPsec latching may make this easier but I don't see how it would remove the requirement on MAC control over the process or change the MAC security policy, the basics of the SA based labeling remain the same. -- paul moore linux @ hp _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
