On Monday 07 December 2009 04:51:10 pm Nicolas Williams wrote: > On Mon, Dec 07, 2009 at 04:37:50PM -0500, Paul Moore wrote: > > I've mentioned all of this before, but my main fundamental concern with > > the proposed labeled IPsec spec is that not everyone who wants labeled > > networking wants IPsec. Look at the CALIPSO effort as an example, it was > > created because users needed a way to communicate security labels over > > the network but did not want or need IPsec (they already had security > > mechanisms in place and IPsec was seen as an unnecessary burden, > > especially for the smaller devices). What I would really like to see is > > a spec providing for a general security label to be assigned per-packet, > > similar to CALIPSO but without the reliance on MLS (imagine the FIPS-188 > > freeform tag). This way users who only need to labeling support are not > > required to go through the IPsec end node processing while those users > > who do not already have a fully trusted network can run IPsec on the > > untrusted links to secure the packet, the label and their binding. > > 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? > The two should support much the same semantics where possible, though IPsec > can provide more functionality (e.g., derive labels from authentication > elements). 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. Do you know of users who need to network peer security labels based on authentication tokens or are you simply posting this as an example? Also, do you see the need for user auth tokens, machine auth tokens or both? -- paul moore linux @ hp _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
