[redhat-lspp] LSPP Development Telecon 10/16/2006 Minutes

[James Morris]

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
<jmorris at namei.org>