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). IPsec SAs are perfect repositories for sensitivity information. And you can continue to use explicit labelling either to transit label-reading routers if you must. > 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. Dan _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
