So during the last meeting when we discussed Labeled IPsec, a few interesting items came up:
1) Is this actually a traffic selector ? Or is it a notify? 2) Is there a use case for "narrowing" on a security label ? 3) Can or should there be different labels in different directions ? 4) Can or should there be different labels for different address families? I think whether to use a TS as part of the TSi/TSr's should follow the answers to these questions. I don't think anyone has seen a plausaible security label narrowing. It was pointed out that my example in the draft was actually incorrect. (also that things like "top secret" really should not include "secret", just like "secret" does not include "top secret"). And SElinux based labeles don't work with these kind of hierachies anyway. While there could be different labels in different directions, it hardly makes sense, for example a TCP connection. And where it might be possible, I think such an IPsec SA really conflates two different IPsec SA's. For example, a service on a port where the IPsec SA is both for incoming and outgoing connections are really two security contexts that can be split into two IPsec SAs one for client (any to port X) and one for server (port Y to any) So in a way, a NOTIFY might make sense. But then we do run the risk of an IPsec SA being installed with the notify ignored using a default security context instead of the security context required. Having it as part of the TSi/TSr payloads makes that a lot more clear. Thoughts? Paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
