| From: KAMLIA::thomson "Barbara Thomson UEG Engineering 15-May-1997 1902" 15-MAY-1997 19:08:01.22
To: [email protected]
CC: smurf::bat
Subj: MLS+ MultiSix Architecture Network Modules
source:
http://www.zk3.dec.com/sec/MLS/standards/multisix/arch/modules.html
[Image]
MultiSix Architecture
Network Modules
[Image]
* Network Security Layers
The MultiSix architecture implements a concept of network security layers.
The Network Level Module (NLM) performs network mandatory access control on
outbound and inbound IP packets and handles any IP security options. The
Session Management Module (SSM) performs process access control on socket
sends and receives, establishes the security attributes to be attached to
outgoing data, and extracts the security attributes from incoming data. For
more information refer to MultiSix Design
* Network Level Module (NLM)
* Outbound NLM Processing
The oubound NLM security processing is similar to the inbound side in
that it is invoked from the standard network layer output function upon
receipt of a packet from the transport layer or from the input network
layer in the case of forwarding. In the case of Internet packets, the
security NLM layer is called from the IP output function. The
processing is roughly summarized below:
Outbound NLM Processing
.------------.
| tcp_output |
| udp_output |
| ip_forward |
| ... |
|____________|
|
|
.----V----. .----------------. OK .-----------.
+->|ip_output|->|Select Route |------>|Output to |
| |_________| |Select Labelling| |Network |
| |Add options | |Interface |
| |________________| |___________|
| | Incomplete
| |
| OK .----v---------. fail .-----.
+<--------------| NLM Daemon |-------->|drop |
|______________| |_____|
The outbound NLM security software determines a route to the
destination that is appropriate for the SL of the packet that is being
sent. The outbound NLM software also determines an appropriate network
security option format based on the new route, and generates the option
for this packet. The network layer software incorporates the option
into the packet and sends it to the data link layer (network adapter).
As in the inbound case, if help from a daemon is needed to complete the
NLM security processing, the packet is put on the NLM packet queue
awaiting a response. A successful status is returned to the caller at
this point regardless of the outcome of the response from the daemon.
If the packet fails the security checks anywhere along the line it is
simply dropped. From the caller's point of view it is the same as if
the packet had actually been put on the wire but never reached its
destination.
* Inbound NLM Processing
Inbound message traffic from the network interface (data link layer) is
passed into the NLM security layer from the input network layer. In the
case of Internet packets, the call is made from the IP input routine
after checksumming the packet header. The processing is roughly
summarized below:
Inbound NLM Processing
.--------. .-------------. Yes .----------.
+-->| ipintrq|-->|Accred Done? |--+------O--->|ip_forward|
| |________| |_____________| | | |__________|
| | No | |
| | | |
| Maybe .----V------. OK | .----V---------.
| +<---| SL Accred |----->+ |Protocol Stack|
| | |___________| |______________|
| | |
| | |Fail
|OK .----V------. Fail .-V----.
+<---|NLM Daemon |----->| Drop |
|___________| |______|
The NLM security layer extracts and interprets any network level
security options that are present, determines if the sensitivity label
(SL) is appropriate, applies internal format security attributes to the
MBUF that contains the message, and returns the packet to the input
network layer. From there it may either be passed up the traditional
network layer stack or forwarded to the next hop if is destined for
some other host.
If at any point in this processing help is needed from an NLM daemon, a
request is sent to the appropriate process and the input packet is put
on an NLM queue awaiting a response from the daemon. When the response
arrives and it is determined that the packet may be accepted into the
system,
Session Management Module(SMM)
The socket structure has been modified so that so_snd and so_rcv are in
reality pairs of socket buffers. Each pair has both a top side and a bottom
side. The top side is only accessed by the new session security layer. The
bottom side retains it traditional semantics and is accessed by the lower
network stack layers with no visible changes.
* Outbound SMM Processing
For outbound data, the top side of the so_snd pair is used to queue up data
originating at the syscall (or equivalent) interface until it is ready to be
passed to the lower layers. The strategy used to decide when to move the
data from the top side to the bottom side is dependent upon the Session
Attribute Management Protocol (SAMP) configured for the endpoint destination
of data. The essence of the strategy, however, independent of the SAMP, is
to guarantee that the bottom side only has data which can be labelled at the
network layer with uniform attributes. Using this strategy avoids any
visibility at lower layers to attribute modulation boundaries.
Outbound SMM Processing
.--------------. .-----.--->.-----.--->.-----.
|SO_SND_TOP |--->|.....| |.....| |.....|
|--------------| |.....| |_____| |.....|
|SO_SND_BOTTOM | |_____| | |_____|
|______________| | | |
| .--V--. .--V--. .--V--.
| |Attr | |Attr | |Attr |
| |_____| |_____| |_____|
|
| .-----.
.---------->|.hdr.|
|.....|
|.....|
|.hdr.|
|.....|
|_____|
|
.--V--.
|Attr |
|_____|
* Inbound SMM Processing
For inbound data the bottom side of the so_rcv_pair contains MBUFs
originating at the lower layer protocol, and the top side contains MBUFs
ready to be passed up to an application. Transfer from the bottom side to
the top side is under control of the session management module (SMM). Data
is queued on the bottom side by the lower protocol layers in the normal
fashion.
Similar to the outbound case, the strategy used to decide when to move the
data from the bottom side to the top side is dependent upon the SAMP of the
originator of the packet. The essence of the strategy in this case, however,
is to guarantee that the top side has data queued as separate records each
with a homogeneous set of attributes and with any session header removed.
Inbound SMM Processing
.--------------. .-----.--->.-----.--->.-----.
|SO_RCV_TOP |--->|.....| |.....| |.....|
|--------------| |.....| |_____| |.....|
|SO_RCV_BOTTOM | |_____| | |_____|
|______________| | | |
| .--V--. .--V--. .--V--.
| |Attr | |Attr | |Attr |
| |_____| |_____| |_____|
|
| .-----.--->.----.
+---------->|.hdr.| |....|
|.....| |....|
|.hdr.| |____|
|.....| |
|_____| |
| |
.--V--. .-V---.
|Attr | |Attr |
|_____| |_____|
Note the main difference here from the outbound side. In the inbound case
there may be multiple records with different attributes queued on the bottom
side at any given point in time. Also, for a datagram socket there could be
data on the bottom side with and without SMM headers, determined by the
source of the datagram.
|