On Tue, 17 Oct 2006, Venkat Yekkirala wrote: > We are NOT overloading the security identifier (secmark) on the skb since > there's no such thing as an internal Vs. external label in the > secpoint design. There's only a "default" label that very intuitively > gets overridden by a "real" label that comes with the data
This approach is too confusing. You will have to work within the following constraints: - Internal and external labeling mechanisms are entirely orthogonal: one represents local knowledge of the packet and the other represents remote information about a peer. - Internal secmarks cannot be modified once set. - Secmark will not be renamed. - No new field will be added to the skb. If you need to encode multiple things on secmark, do it internally (as I've suggested a couple of times). I suggest implementing a 'peer' class to manage IPsec labeling policy, with a very simple policy construct similar to that of the packet class. That way, the user can simply think about packets and peers when configuring policy, which are representations of real things. -- James Morris <[EMAIL PROTECTED]> -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
