Implementing CIPSO -- domains of interpretation, etc

[Robert Watson]

Over the past few months, we've seen a lot of interest in a CIPSO
implementation for TrustedBSD.  Right now, labels are maintained
internally on in flight packets (mbufs), network interfaces, sockets, IP
fragment queues, etc, but are not externalized onto wire networks.  In the
past, Ilmar Habibulin has implemented basic CIPSO support for earlier
TrustedBSD MLS implementations, but I'm looking at generalizing that
support so that various policies (MLS, TE using SEBSD, etc) can carry
label data over the network.  The MAC Framework as found in the MAC
development tree currently has an entry point to offer CIPSO IP header
options to the MAC policies for interpretation (and permits MAC policies
to generate an ICMP error on rejecting a label, if they choose).

However, we don't have an entry point due to some requirements for
externalization that are a little hard to represent in the current stack
layout.  For example, in our earlier designs, we wanted to determine
whether CIPSO was required for a packet based on the properties of the
outgoing network interfaces: i.e., some interfaces might operate as
single-level, but others might operate as multi-level with CIPSO
requirements and a domain of interpretation configured for the interfaces. 
However, the IP header construction is performed (in most cases) before
the routing decision is made, so the interface is not available at the
most logical point to insert the header in the existing code, so that
disposition of the interface isn't available to determine if we want to
use CIPSO, and if so, how to generate the CIPSO header.  In Ilmar's
earlier implementation, he generated CIPSO based on the socket sourcing
the packet, so much earlier in the packet building process.  However, this
wouldn't permit the following desired behavior: if a packet sourced from
a single-level interface is to be routed over a multi-level interface, its
CIPSO label will reflect the label assigned from the single-level
interface on ingress.

I'm looking for two sorts of information to influence the approach we take
for CIPSO:

(1) Information on how other network stack implementations approach this
    problem -- do they make CIPSO decisions based on the interface
    identified for routing?  If so, do the stacks not construct the header
    chain until after the routing step is done, or do they reprocess the
    packet to insert the header if CIPSO is required (picking up extra
    memory copies, etc).  If they don't use the interface for CIPSO
    disposition on transmission, what do they use?  The socket?  The
    route?  Do implementations generally internalize the CIPSO label when
    the packet comes in, discard the CIPSO data, and then re-insert it on
    the outbound path, or do they keep it along the way only rewriting if
    necessary?

(2) The RFC defining CIPSO isn't extraordinarily explicit about how to
    construct CIPSO labels for common use.  CIPSO labels are subject to a
    domain of interpretation; I believe most implementations map network
    values to internal label values, since most implementations have more
    expressive labeling facilities than can be represented in common CIPSO
    use.  Many systems appear to use a configured table (perhaps
    mechanically maintained) to map externalized values (perhaps on a
    per-source, per-interface, ... basis) to internalized values, and
    likewise to determine how to represent outgoing label data to specific
    interfaces or hosts.  How do most systems address this -- what tends
    to work, what doesn't, and what is most useful, behavior-wise?

Finally, we've had some interest in trusted routing -- i.e., including the
label of a packet or its source in the decision making process for routing
the packet out another interface.  Is this behavior we should be
providing and that is commonly used, or is it something we should defer?
We don't have to address it at the same time as CIPSO, but if we have our
fingers in the routing code anyway... :-)

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org      Network Associates Laboratories


To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message