[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference smurf::dec_mls_plus

Title:dec_mls_plus
Moderator:SMURF::BAT
Created:Mon Nov 29 1993
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:534
Total number of notes:2544

509.0. "what is routing algorithm in MLS+?" by SMURF::BAT (Segui la tua beatitudine) Thu May 15 1997 22:09

    Mark Sowards called and said that one of the programmers at Lockheed,
    Wm Author, wanted to know how MLS+ makes it routing decisions.
T.RTitleUserPersonal
Name
DateLines
509.1This does not provide all the answers, just someSMURF::BATSegui la tua beatitudineThu May 15 1997 23:27197
From:	KAMLIA::thomson "Barbara Thomson UEG Engineering  15-May-1997 1902" 15-MAY-1997 19:08:01.22
To:	sowards@mail.dec.com
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.