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: > > > But this is not a reason to oppose labelled IPsec. It's a reason to > > > want an extended IP packet labelling standard. > > > > 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. 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. > 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. > And you can continue to use explicit labelling either to transit label- > reading routers if you must. In which case you are now worse off since you have both the AH/ESP overhead as well as the security label overhead. > > I'm not exactly sure how you envision this working, but for the sake of > > argument lets say that for the certificate derived security labels node A > > sends a cert to node B as part of the IKE negotiation which node B then > > uses to derive a security label for the SA matching node A's traffic > > (indirectly labeling node A's traffic as it is received). This is an > > interesting scenario because it doesn't actually involve any security > > labels being transfered over the network, either via IKE or AH/ESP; in > > fact, if you implement it correctly you could probably achieve this today > > using a standard IPsec implementation on node A (only node B and its > > IPsec implementation need to be label aware). I hasn't thought about > > this too much until just now, but I would almost consider this case to be > > a method of fallback labeling; instead of deriving the security label > > from an IP address you derive it from an authentication token. > > You could have PAD entries that set labels. We do that today in > OpenSolaris. I apologize, but I'm not familiar with OpenSolaris's IPsec - do you use the pad to assign labels when none are present (the fallback case) or do you use it to limit the range of labels you will accept from a remote node? Based on your comment I suspect it is at least the former, I just wanted to clarify. -- paul moore linux @ hp _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
