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