tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5570

 
 
 

Common Architecture Label IPv6 Security Option (CALIPSO)

Part 2 of 3, p. 19 to 41
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 19 
3.  Architecture

   This document describes a convention for labeling an IPv6 datagram
   within a particular system security policy.  The labels are designed
   for use within a Mandatory Access Control (MAC) system.  A real-world
   example is the security classification system in use within the UK
   Government.  Some data held by the government is "classified", and is
   therefore restricted by law to those people who have the appropriate
   "clearances".

   Commercial examples of information labeling schemes also exist
   [CW87].  For example, one global electrical equipment company has a
   formal security policy that defines six different Sensitivity Levels
   for its internal data, ranging from "Class 1" to "Class 6"
   information.  Some financial institutions use multiple compartments
   to restrict access to certain information (e.g., "mergers and
   acquisitions", "trading") to those working directly on those projects
   and to deny access to other groups within the company (e.g., equity
   trading).  A CALIPSO Sensitivity Label is the network instantiation
   of a particular information security policy, and the policy's related
   labels, classifications, compartments, and Releasabilities.

   Some years ago, the Mandatory Access Control (MAC) policy for US
   Government classified information was specified formally in
   mathematical notation [BL73].  As it happens, many other
   organizations or governments have the same basic Mandatory Access
   Control (MAC) policy for information with differing ("vertical")
   Sensitivity Levels.  This document builds upon the formal definitions
   of Bell-LaPadula [BL73].  There are two basic principles: "no write
   down" and "no read up".

   The first rule means that an entity having minimum Sensitivity Level
   X must not be able to write information that is marked with a
   Sensitivity Level below X.  The second rule means that an entity
   having maximum Sensitivity Level X must not be able to read
   information having a Sensitivity Level above X.  In a normal
   deployment, information downgrading ("write down") must not occur
   automatically, and is permitted if and only if a person with

Top      Up      ToC       Page 20 
   appropriate "downgrade" privilege manually verifies the information
   is permitted to be downgraded before s/he manually relabels (i.e.,
   "downgrades") the information.  Subsequent to the original work by
   Bell and LaPadula in this area, this formal model was extended to
   also support ("horizontal") Compartments of information.

   This document extends Bell-LaPadula to accommodate the notion of
   separate Domains of Interpretation (DOI) [BL73].  Each DOI
   constitutes a single comparable domain of Sensitivity Labels as
   stated by Bell-LaPadula.  Sensitivity Labels from different domains
   cannot be directly compared using Bell-LaPadula semantics.

   This document is focused on providing specifications for (1) encoding
   Sensitivity Labels in packets, and (2) how such Sensitivity Labels
   are to be interpreted and enforced at the IP layer.  This document
   recognizes that there are several kinds of application processing
   that occur above the IP layer that significantly impact end-to-end
   system security policy enforcement, but are out of scope for this
   document.  In particular, how the network labeling policy is enforced
   within processing in an End System is critical, but is beyond the
   scope of a network (IP) layer Sensitivity Label encoding standard.
   Other specifications exist, which discuss such details [TCSEC] [TNI]
   [CMW] [ISO-15408] [CC] [MLOSPP].

   This specification does not preclude an End System capable of
   providing labeled packets across some range of Sensitivity Labels.  A
   Compartmented Mode Workstation (CMW) is an example of such an End
   System [CMW].  This is useful if the End System is capable of, and
   accredited to, separate processing across some range of Sensitivity
   Labels.  Such a node would have a range associated with it within the
   network interface connecting the node to the network.  As an example,
   an End System has the range "SECRET: TOP SECRET" associated with it
   in the Intermediate System to which the node is attached.  SECRET
   processing on the node is allowed to traverse the network to other
   "SECRET :  SECRET" segments of the network, ultimately to a "SECRET :
   SECRET" node.  Likewise, TOP SECRET processing on the node is allowed
   to traverse a network through "TOP SECRET: TOP SECRET" segments,
   ultimately to some "TOP SECRET: TOP SECRET" node.  The node in this
   case can allow a user on this node to access SECRET and TOP SECRET
   resources, provided the user holds the appropriate clearances and has
   been correctly configured.

   With respect to a given network, each distinct Sensitivity Label
   represents a separate virtual network, which shares the same physical
   network.  There are rules for moving information between the various
   virtual networks.  The model we use within this document is based on

Top      Up      ToC       Page 21 
   the Bell-LaPadula model, but is extended to cover the concept of
   differing Domains of Interpretation.  Nodes that implement this
   protocol MUST enforce this mandatory separation of data.

   CALIPSO provides for both horizontal ("Compartment") and vertical
   ("Sensitivity Level") separation of information, as well as
   separation based on DOI.  The basic rule is that data MUST NOT be
   delivered to a user or system that is not approved to receive it.

   NOTE WELL: Wherever we say "not approved", we also mean "not
   cleared", "not certified", and/or "not accredited" as applicable in
   one's operational community.

   This specification does not enable AUTOMATIC relabeling of
   information, within a DOI or to a different DOI.  That is, neither
   automatic "upgrading" nor automatic "downgrading" of information are
   enabled by this specification.  Local security policies might allow
   some limited downgrading, but this normally requires the intervention
   of some human entity and is usually done within an End System with
   respect to the internal Sensitivity Label, rather than on a network
   or in an intermediate-system (e.g., router, guard).  Automatic
   downgrading is not suggested operational practice; further discussion
   of downgrading is outside the scope of this protocol specification.

   Implementers of this specification MUST NOT permit automatic
   upgrading or downgrading of information in the default configuration
   of their implementation.  Implementers MAY add a configuration knob
   that would permit a System Security Officer holding appropriate
   privilege to enable automatic upgrading or downgrading of
   information.  If an implementation supports such a knob, the
   existence of the configuration knob must be clearly documented and
   the default knob setting MUST be that automatic upgrading or
   downgrading is DISABLED.  Automatic information upgrading and
   downgrading is not recommended operational practice.

   Many existing MLS deployments already use (and operationally need to
   use) more than one DOI concurrently.  User feedback from early
   versions of this specification indicates that it is common at present
   for a single network link (i.e., IP subnetwork) to carry traffic for
   both a particular coalition (or joint-venture) activity and also for
   the government (or other organization) that owns and operates that
   particular network link.  On such a link, one CALIPSO DOI would
   typically be used for the coalition traffic and some different
   CALIPSO DOI would typically be used for non-coalition traffic (i.e.,
   traffic that is specific to the government that owns and operates
   that particular network link).  For example, a UK military network
   that is part of a NATO deployment might have and use a UK MoD DOI for

Top      Up      ToC       Page 22 
   information originating/terminating on another UK system, while
   concurrently using a different NATO DOI for information
   originating/terminating on a non-UK NATO system.

   Additionally, operational experience with existing MLS systems has
   shown that if a system only supports a single DOI at a given time,
   then it is impossible for a deployment to migrate from using one DOI
   value to a different DOI value in a smooth, lossless, zero downtime,
   manner.

   Therefore, a node that implements this specification MUST be able to
   support at least two CALIPSO DOIs concurrently.  Support for more
   than two concurrent CALIPSO DOIs is encouraged.  This requirement to
   support at least two CALIPSO DOIs concurrently is not necessarily an
   implementation constraint upon MLS operating system internals that
   are unrelated to the network.

   Indeed, use of multiple DOIs is also operationally useful in
   deployments having a single administration that also have very large
   numbers of compartments.  For example, such a deployment might have
   one set of related compartments in one CALIPSO DOI and a different
   set of compartments in a different CALIPSO DOI.  Some compartments
   might be present in both DOIs, possibly at different bit positions of
   the compartment bitmap in different DOIs.  While this might make some
   implementations more complex, it might also be used to reduce the
   typical size of the IPv6 CALIPSO option in data packets.

   Moving information between any two DOIs is permitted -- if and only
   if -- the owners of the DOIs:

        1) Agree to the exchange,

   AND

        2) Publish a document with a table of equivalencies that
           maps the CALIPSO values of one DOI into the other
           and make that document available to security
           administrators of MLS systems within the deployment
           scope of those two DOIs.

   The owners of two DOIs may choose to permit the exchange on or
   between any of their systems, or may restrict exchange to a small
   subset of the systems they own/accredit.  One-way agreements are
   permissible, as are agreements that are a subset of the full table of
   equivalences.  Actual administration of inter-DOI agreements is
   outside the scope of this document.

Top      Up      ToC       Page 23 
   When data leaves an End System it is exported to the network, and
   marked with a particular DOI, Sensitivity Level, and Compartment Set.
   (This triple is collectively termed a Sensitivity Label.)  This
   Sensitivity Label is derived from the internal Sensitivity Label (the
   end-system-specific implementation of a given Sensitivity Label), and
   the Export DOI.  Selection of the Export DOI is described in detail
   in Section 6.2.1.

   When data arrives at an End System, it is imported from the network
   to the End System.  The data from the datagram takes on an internal
   Sensitivity Label based on the Sensitivity Label contained in the
   datagram.  This assumes the datagram is marked with a recognizable
   DOI, there is a corresponding internal Sensitivity Label equivalent
   to the CALIPSO Sensitivity Label, and the datagram is "within range"
   for the receiving logical interface.

   A node has one or more physical interfaces.  Each physical interface
   is associated with a physical network segment used to connect the
   node, router, LAN, or WAN.  One or more Sensitivity Label ranges are
   associated with each physical network interface.  Sensitivity Label
   ranges from multiple DOIs must be enumerated separately.  Multiple
   ranges from the same DOI are permissible.

   Each node also might have one or more logical network interfaces.

   A given logical network interface might be associated with more than
   one physical interface.  For example, a switch/router might have two
   separate Ethernet ports that are associated with the same Virtual
   Local Area Network (VLAN), where that one VLAN mapped to a single
   IPv6 subnetwork [IEEE802.1Q].

   A given physical network interface might have more than one
   associated logical interface.  For example, a node might have 2
   logical network interfaces, each for a different IP subnetwork
   ("super-netting"), on a single physical network interface (e.g., on a
   single Network Interface Card of a personal computer).
   Alternatively, also as an example, a single Ethernet port might have
   multiple Virtual LANs (VLANs) associated with it, where each VLAN
   could be a separate logical network interface.

   One or more Sensitivity Label ranges are associated with each logical
   network interface.  Sensitivity Label ranges from multiple DOIs must
   be enumerated separately.  Multiple ranges from the same DOI are
   permissible.  Each range associated with a logical interface must
   fall within a range separately defined for the corresponding physical
   interface.

Top      Up      ToC       Page 24 
   There is specific user interest in having IPv6 routers that can apply
   per-logical-interface mandatory access controls based on the contents
   of the CALIPSO Sensitivity Labels in IPv6 packets.  The authors note
   that since the early 1990s, and continuing through today, some
   commercial IPv4 router products provide MAC enforcement for the RFC
   1108 IP Security Option.

   In transit, a datagram is handled based on its CALIPSO Sensitivity
   Label, and is usually neither imported to or exported from the
   various Intermediate Systems it transits.  There also is the concept
   of "CALIPSO Gateways", which import data from one DOI and export it
   to another DOI such that the effective Sensitivity Label is NOT
   changed, but is merely represented using a different DOI.  In other
   words, such devices would be trustworthy, trusted, and authorized to
   provide on-the-fly relabeling of packets at the boundaries between
   complete systems of End Systems within a single DOI.  Typically, such
   systems require specific certification(s) and accreditation(s) before
   deployment or use.

4.  Defaults

   This Section describes the default behavior of CALIPSO-compliant End
   Systems and Intermediate Systems.  Implementers MAY implement
   configuration knobs to vary from this behavior, provided that the
   default behavior (i.e., if the system administrator does not
   explicitly change the configured behavior of the device) is as
   described below.  If implementers choose to implement such
   configuration knobs, the configuration parameters and the behaviors
   that they enable and disable SHOULD be documented for the benefit of
   system administrators of those devices.

   Each Intermediate System or End System is responsible for properly
   interpreting and enforcing the MLS Mandatory Access Control policy.
   Practically, this means that each node must evaluate the label on the
   inbound packet, ensure that this Sensitivity Label is valid (i.e.,
   within range) for the receiving interface, and at a minimum only
   forward the packet to an interface and node where the Sensitivity
   Label of the packet falls within the assigned range of that node's
   receiving interface.

   Packets with an invalid (e.g., out-of-range) Sensitivity Label for
   the receiving interface MUST be dropped upon receipt.  A Sensitivity
   Label is valid if and only if the Sensitivity Label falls within the
   range assigned to the transmitting interface on the sending system
   and within the range assigned to the receiving interface on the
   receiving system.  These rules also need to be applied by
   Intermediate Systems on each hop that a CALIPSO-labeled packet
   traverses, not merely at the end points of a labeled IP session.  As

Top      Up      ToC       Page 25 
   an example, it is a violation of the default MLS MAC policy for a
   packet with a higher Sensitivity Level (e.g., "MOST SECRET") to
   transit a link whose maximum Sensitivity Level is less than that
   first Sensitivity Level (e.g., "SECRET").

   If an unlabeled packet is received from a node that does not support
   CALIPSO Sensitivity Labels (i.e., unable to assign Sensitivity Labels
   itself) and the packet is destined for a node that supports CALIPSO
   Sensitivity Labels, then the receiving intermediate system needs to
   insert a Sensitivity Label.  This Sensitivity Label MUST be equal to
   the maximum Sensitivity Label assigned to the originating node if and
   only if that is known to the receiving node.  If this receiving
   Intermediate System does not know which Sensitivity Label is assigned
   to the originating node, then the maximum Sensitivity Label of the
   interface that received the unlabeled packet MUST be inserted.

   NOTE WELL: The procedure in the preceding paragraph is NOT a label
   upgrade -- because it is not changing an existing label; instead, it
   is simply inserting a Sensitivity Label that has the only "safe"
   value, given that no other information is known to the receiving
   node.  In large-scale deployments, it is very unlikely that a given
   node will have any authoritative a priori information about the
   security configuration of any node that is NOT on a directly attached
   link.

   If a packet is to be sent to a node that is defined to not be
   Sensitivity Label aware, from a node that is label aware, then the
   Sensitivity Label MAY be removed upon transmission if and only if
   local security policy explicitly permits this.  The originating node
   is still responsible for ensuring that the Sensitivity Label on the
   packet falls within the Sensitivity Label range associated with the
   receiving node.  If the packet will traverse more than one subnetwork
   between origin and destination, and those subnetworks are labeled,
   then the packet SHOULD normally contain a Sensitivity Label so that
   the packet will be able to reach the destination and the Intermediate
   Systems will be able to apply the requisite MAC policy to the packet.

   NOTE WELL: In some IPv4 MLS network deployments that exist as of the
   publication date, if a first-hop router receives an unlabeled IPv4
   packet, the router inserts an appropriate Sensitivity Label into that
   IPv4 packet, in the manner described above.  So sending a packet
   without a label across a multiple subnetwork path to a destination
   does not guarantee that the packet will arrive containing no
   Sensitivity Label.

Top      Up      ToC       Page 26 
5.  Format

   This section describes the format of the CALIPSO option for use with
   IPv6 datagrams.  CALIPSO is an IPv6 Hop-By-Hop Option, rather than an
   IPv6 Destination Option, to ensure that a security gateway or router
   can apply access controls to IPv6 packets based on the CALIPSO label
   carried by the packet.

   An IPv6 datagram that has not been tunneled contains at most one
   CALIPSO label.  In the special case where (1) a labeled IPv6 datagram
   is tunneled inside another labeled IPv6 datagram AND (2) IP Security
   is NOT providing confidentiality protection for the inner packet, the
   outer CALIPSO Sensitivity Label must have the same meaning as the
   inner CALIPSO Sensitivity Label.  For example, it would be invalid to
   encapsulate an unencrypted IPv6 packet with a Sensitivity Label of
   (SECRET, no compartments) inside a packet with an outer Sensitivity
   Label of (UNCLASSIFIED).

   If the inner IPv6 packet is tunneled inside the Encapsulating
   Security Payload (ESP) and confidentiality is being provided to that
   inner packet, then the outer packet MAY have a different CALIPSO
   Sensitivity Label -- subject to local security policy.

   As a general principle, the meaning of the Sensitivity Labels must be
   identical when one has a labeled cleartext IP packet that has been
   encapsulated (tunneled) inside another labeled IP packet.  This is
   true whether one has IPv6 tunneled in IPv6, IPv4 tunneled in IPv6, or
   IPv6 tunneled in IPv4.  This is essential to maintaining proper
   Mandatory Access Controls.

   This option's syntax has been designed with intermediate systems in
   mind.  It is now common for an MLS network deployment to contain an
   Intermediate Systems acting as a guard (sometimes several acting as
   guards).  Such a guard device needs to be able to very rapidly parse
   the Sensitivity Label in each packet, apply ingress interface MAC
   policy, forward the packet while aware of the packet's Sensitivity
   Label, and then apply egress interface MAC policy.

   At least one prior IP Sensitivity Label option [FIPS-188] used a
   syntax that was unduly complex to parse in IP routers, hence that
   option never was implemented in an IP router.  So there is a
   deliberate effort here to choose a streamlined option syntax that is
   easy to parse, encode, and implement in more general terms.

Top      Up      ToC       Page 27 
5.1.  Option Format

   The CALIPSO option is an IPv6 Hop-by-Hop Option and is designed to
   comply with IPv6 optional header rules.  Following the nomenclature
   of Section 4.2 of RFC 2460, the Option Type field of this option must
   have 4n+2 alignment [RFC2460].

   The CALIPSO Option Data MUST NOT change en route, except when (1)
   "DOI translation" is performed by a trusted Intermediate System, (2)
   a CALIPSO Option is inserted by a trusted Intermediate System upon
   receipt of an unlabeled IPv6 packet, or (3) a CALIPSO Option is
   removed by a last-hop trusted Intermediate System immediately prior
   to forwarding the packet to a destination node that does not
   implement support for CALIPSO labels.  The details of these three
   exceptions are described elsewhere in this document.

   If the option type is not recognized by a node examining the packet,
   the option is ignored.  However, all implementations of this
   specification MUST be able to recognize this option and therefore
   MUST NOT ignore this option if it is present in an IPv6 packet.

   This option is designed to comply with the IPv6 optional header rules
   [RFC2460].  The CALIPSO option is always carried in a Hop-By-Hop
   Option Header, never in any other part of an IPv6 packet.  This rule
   exists because IPv6 routers need to be able to see the CALIPSO label
   so that those routers are able to apply MLS Mandatory Access Controls
   to those packets.

   The diagram below shows the CALIPSO option along with the required
   (first) two fields of the Hop-By-Hop Option Header that envelops the
   CALIPSO option.  The design of the CALIPSO option is arranged to
   avoid the need for 16 bits of padding between the HDR EXT LEN field
   and the start of the CALIPSO option.  Also, the CALIPSO Domain of
   Interpretation field is laid out so that it normally will be 32-bit
   aligned.

   ------------------------------------------------------------
   | Next Header | Hdr Ext Len   | Option Type | Option Length|
   +-------------+---------------+-------------+--------------+
   |             CALIPSO Domain of Interpretation             |
   +-------------+---------------+-------------+--------------+
   | Cmpt Length |  Sens Level   |     Checksum (CRC-16)      |
   +-------------+---------------+-------------+--------------+
   |      Compartment Bitmap (Optional; variable length)      |
   +-------------+---------------+-------------+--------------+

Top      Up      ToC       Page 28 
5.1.1.  Option Type Field

   This field contains an unsigned 8-bit value.  Its value is 00000111
   (binary).

   Nodes that do not recognize this option should ignore it.  In many
   cases, not all routers in a given MLS deployment will contain support
   for this CALIPSO option.  For interoperability reasons, it is
   important that routers that do not support the CALIPSO forward this
   packet normally, even though those routers do not recognize the
   CALIPSO option.

   In the event the IPv6 packet is fragmented, this option MUST be
   copied on fragmentation.  Virtually all users want the choice of
   using the IP Authentication Header (a) to authenticate this option
   and (b) to bind this option to the associated IPv6 packet.

5.1.2.  Option Length Field

   This field contains an unsigned integer one octet in size.  Its
   minimum value is eight (e.g., when the Compartment Bitmap field is
   absent).  This field specifies the Length of the option data field of
   this option in octets.  The Option Type and Option Length fields are
   not included in the length calculation.

5.1.3.  Compartment Length Field

   This field contains an unsigned 8-bit integer.  The field specifies
   the size of the Compartment Bitmap field in 32-bit words.  The
   minimum value is zero, which is used only when the information in
   this packet is not in any compartment.  (In that situation, the
   CALIPSO Sensitivity Label has no need for a Compartment Bitmap).
   Note that measuring the Compartment Bitmap field length in 32-bit
   words permits the header to be 64-bit aligned, following IPv6
   guidelines, without wasting 32 bits.  Using 64-bit words for the size
   of the Compartment Bitmap field length would force 32 bits of padding
   with every option in order to maintain 64-bit alignment; wasting
   those bits in every CALIPSO option is undesirable.

   Because this specification represents Releasabilities on the wire as
   inverted Compartments, the size of the Compartment Bitmap field needs
   to be large enough to hold not only the set of logical Compartments,
   but instead to hold both the set of logical Compartments and the set
   of logical Releasabilities.

   Recall that the overall length of this option MUST follow IPv6
   optional header rules, including the word alignment rules.  This has
   implications for the valid values for this field.  In some cases, the

Top      Up      ToC       Page 29 
   length of the Compartment Bitmap field might need to exceed the
   number of bits required to hold the sum of the logical Compartments
   and the logical Releasabilities, in order to comply with IPv6
   alignment rules.

5.1.5.  Domain of Interpretation Field

   This field contains an unsigned 32-bit integer.  IANA maintains a
   registry with assignments of the DOI values used in this field.  The
   DOI identifies the rules under which this datagram must be handled
   and protected.  The NULL DOI, in which this field is all zeros, MUST
   NOT appear in any IPv6 packet on any network.

   NOTE WELL: The Domain Of Interpretation value where all 4 octets
   contain zero is defined to be the NULL DOI.  The NULL DOI has no
   compartments and has a single level whose value and CALIPSO
   representation are each zero.  The NULL DOI MUST NOT ever appear on
   the wire.  If a packet is received containing the NULL DOI, that
   packet MUST be dropped and the event SHOULD be logged as a security
   fault.

5.1.6.  Sensitivity Level Field

   This contains an unsigned 8-bit value.  This field contains an opaque
   octet whose value indicates the relative sensitivity of the data
   contained in this datagram in the context of the indicated DOI.  The
   values of this field MUST be ordered, with 00000000 being the lowest
   Sensitivity Level and 11111111 being the highest Sensitivity Level.

   However, in a typical deployment, not all 256 Sensitivity Levels will
   be in use.  So the set of valid Sensitivity Level values depends upon
   the CALIPSO DOI in use.  This sensitivity ordering rule is necessary
   so that Intermediate Systems (e.g., routers or MLS guards) will be
   able to apply MAC policy with minimal per-packet computation and
   minimal configuration.

5.1.7.  16-Bit Checksum Field

   This 16-bit field contains the a CRC-16 checksum as defined in
   Appendix C of RFC 1662 [RFC1662].  The checksum is calculated over
   the entire CALIPSO option in this packet, including option header,
   zeroed-out checksum field, option contents, and any required padding
   zero bits.

   The checksum MUST always be computed on transmission and MUST always
   be verified on reception.  This checksum only provides protection
   against accidental corruption of the CALIPSO option in cases where

Top      Up      ToC       Page 30 
   neither the underlying medium nor other mechanisms, such as the IP
   Authentication Header (AH), are available to protect the integrity of
   this option.

   Note that the checksum field is always required, even when other
   integrity protection mechanisms (e.g., AH) are used.  This method is
   chosen for its reliability and simplicity in both hardware and
   software implementations, and because many implementations already
   support this checksum due to its existing use in various IETF
   specifications.

5.1.8.  Compartment Bitmap Field

   This contains a variable number of 64-bit words.  Each bit represents
   one compartment within the DOI.  Each "1" bit within an octet in the
   Compartment Bitmap field represents a separate compartment under
   whose rules the data in this packet must be protected.  Hence, each
   "0" bit indicates that the compartment corresponding with that bit is
   not applicable to the data in this packet.  The assignment of
   identity to individual bits within a Compartment Bitmap for a given
   DOI is left to the owner of that DOI.

   This specification represents a Releasability on the wire as if it
   were an inverted Compartment.  So the Compartment Bitmap holds the
   sum of both logical Releasabilities and also logical Compartments for
   a given DOI value.  The encoding of the Releasabilities in this field
   is described elsewhere in this document.  The Releasability encoding
   is designed to permit the Compartment Bitmap evaluation to occur
   without the evaluator necessarily knowing the human semantic
   associated with each bit in the Compartment Bitmap.  In turn, this
   facilitates the implementation and configuration of Mandatory Access
   Controls based on the Compartment Bitmap within IPv6 routers or guard
   devices.

5.2.  Packet Word Alignment Considerations

   The basic option is variable length, due to the variable length
   Compartment Bitmap field.

   Intermediate Systems that lack custom silicon processing capabilities
   and most End Systems perform best when processing fixed-length,
   fixed-location items.  So the IPv6 base specification levies certain
   requirements on all IPv6 optional headers.

Top      Up      ToC       Page 31 
   The CALIPSO option must maintain this IPv6 64-bit alignment rule for
   the option overall.  Please note that the Compartment Bitmap field
   has a length in quanta of 32-bit words (e.g., 0 bits, 32 bits, 64
   bits, 96 bits), which permits the overall CALIPSO option length to be
   64-bit aligned -- without requiring 32 bits of NULL padding with
   every CALIPSO option.

6.  Usage

   This section describes specific protocol processing steps required
   for systems that claim to implement or conform with this
   specification.

6.1.  Sensitivity Label Comparisons

   This section describes how comparisons are made between two
   Sensitivity Labels.  Implementing this comparison correctly is
   critical to the MLS system providing the intended Mandatory Access
   Controls (MACs) to network traffic entering or leaving the system.

   A Sensitivity Label consists of a DOI, a Sensitivity Level, and zero
   or more Compartments.  The following notation will be used:

     A.DOI  = the DOI portion of Sensitivity Label A
     A.LEV  = the Sensitivity Level portion of Sensitivity Label A
     A.COMP = the Compartments portion of Sensitivity Label A

6.1.1.  "Within Range"

   A Sensitivity Label "M" is "within range" for a particular range
   "LO:HI" if and only if:

        1.  M, LO, and HI are members of the same DOI.

            (M.DOI == LO.DOI == HI.DOI)

        2.  The range is a valid range.  A given range LO:HI is
            valid if and only if HI dominates LO.

            ((LO.LEV  <= HI.LEV)  &&  (LO.COMP <= HI.COMP))

        3.  The Sensitivity Level of M dominates the low-end (LO)
            Sensitivity Level AND the Sensitivity Level of M is
            dominated by the high-end (HI) Sensitivity Level.

            (LO.LEV <= M.LEV <= HI.LEV)

   AND

Top      Up      ToC       Page 32 
        4.  The Sensitivity Label M has a Compartment Set that
            dominates the Compartment Set contained in the
            Sensitivity Label from the low-end range (LO), and
            that is dominated by the Compartment Set contained
            in the high-end Sensitivity Label (HI) from the range.

            (LO.COMP <= M.COMP <= HI.COMP)

6.1.2.  "Less Than" or "Below Range"

   A Sensitivity Label "M" is "less than" some other Sensitivity Label
   "LO" if and only if:

        1.   The DOI for the Sensitivity Label M is identical
             to the DOI for both the low-end and high-end of
             the range.

             (M.DOI == LO.DOI == HI.DOI)

   AND EITHER

        2.   The Sensitivity Level of M is less than the
             Sensitivity Level of LO.

             (M.LEV < LO.LEV)

   OR

        3.   The Compartment Set of Sensitivity Label M is
             dominated by the Compartment Set of Sensitivity
             Label LO.

             (M.COMP <= LO.COMP)

   A Sensitivity Label "M" is "below range" for a Sensitivity Label
   "LO:HI", if LO dominates M and LO is not equal to M.

6.1.3.  "Greater Than" or "Above Range"

   A Sensitivity Label "M" is "greater than" some Sensitivity Label "HI"
   if and only if:

        1.   Their DOI's are identical.

             (M.DOI == HI.DOI)

   AND EITHER

Top      Up      ToC       Page 33 
        2A.  M's Sensitivity Level is above HI's Sensitivity Level.

             (M.LEV > HI.LEV)

   OR

        2B.  M's Compartment Set is greater than HI's Compartment Set.

             (M.COMP > HI.COMP)

   A Sensitivity Label "M" is "above range" for a Sensitivity Label,
   "LO:HI", if M dominates HI and M is not equal to HI.

6.1.4.  "Equal To"

   A Sensitivity Label "A" is "equal to" another Sensitivity Label "B"
   if and only if:

        1. They have the exact same DOI.

           (A.DOI == B.DOI)

        2. They have identical Sensitivity Levels.

           (A.LEV == B.LEV)

        3. Their Compartment Sets are identical.

           (A.COMP == B.COMP)

6.1.5.  "Disjoint" or "Incomparable"

   A Sensitivity Label "A" is disjoint from another Sensitivity Label
   "B" if any of these conditions are true:

        1. Their DOI's differ.

           (A.DOI <> B.DOI)

        2. B does not dominate A, A does not dominate B,
           and A is not equal to B.

           (^( (A < B) || (A > B) || (A == B) ))

Top      Up      ToC       Page 34 
        3. Their Compartment Sets are disjoint from each other;
           A's Compartment Set does not dominate B's Compartment
           Set AND B's Compartment Set does not dominate A's
           Compartment Set.

             (^( (A.COMP >= B.COMP) || (A.COMP <= B.COMP) ))

6.2.  End System Processing

   This section describes CALIPSO-related processing for IPv6 packets
   imported or exported from an End System claiming to implement or
   conform with this specification.  This document places no additional
   requirements on IPv6 nodes that do not claim to implement or conform
   with this document.

6.2.1.  Export

   An End System that sends data to the network is said to "export" it
   to the network.  Before a datagram can leave an end system and be
   transmitted over a network, the following ordered steps must occur:

      1. Selection of the export DOI:

        a) If the upper-level protocol selects a DOI,
           then that DOI is selected.

        b) Else, if there are tables defining a specific default
           DOI for the specific destination End System address
           or for the network address, then that DOI is selected.

        c) Else, if there is a specific DOI associated with the
           sending logical interface (i.e., IP address), then that
           DOI is selected.

        d) Else the default DOI for the system is selected.

   NOTE WELL: A connection-oriented transport-layer protocol session
   (e.g., Transmission Control Protocol (TCP) session, Stream Control
   Transmission Protocol (SCTP) session) MUST have the same DOI and same
   Sensitivity Label for the life of that connection.  The DOI is
   selected at connection initiation and MUST NOT change during the
   session.

   A trusted multi-level application that possesses appropriate
   privilege MAY use multiple connection-oriented transport-layer
   protocol sessions with differing Sensitivity Labels concurrently.

Top      Up      ToC       Page 35 
   Some trusted UDP-based applications (e.g., remote procedure call
   service) multiplex different transactions having different
   Sensitivity Levels in different packets for the same IP session
   (e.g., IP addresses and UDP ports are constant for a given UDP
   session).  In such cases, the Trusted Computing Base MUST ensure that
   each packet is labeled with the correct Sensitivity Label for the
   information carried in that particular packet.

   In the event the End System selects and uses a specific DOI and that
   DOI is not recognized by the originating node's first-hop router, the
   packet MUST be dropped by the first-hop router.  In such a case, the
   networking API should indicate the connection failure (e.g., with
   some appropriate error, such as ENOTREACH).  This fault represents
   (1) incorrect configuration of either the Intermediate System or of
   the End System or (2) correct operation for a node that is not
   permitted to send IPv6 packets with that DOI through that
   Intermediate System.

   When an MLS End System is connected to an MLS LAN, it is possible
   that there would be more than one first-hop Intermediate System
   concurrently, with different Intermediate Systems having different
   valid Sensitivity Label ranges.  Thoughtful use of the IEEE 802
   Virtual LAN (VLAN) standard (e.g., with different VLAN IDs
   corresponding to different sensitivity ranges) might ease proper
   system configuration in such deployments.

        2.  Export Labeling:

        Once the DOI is selected, the CALIPSO Sensitivity
        Label and values are determined based on the internal
        Sensitivity Label and the DOI.  In the event the internal
        Sensitivity Level does not map to a valid CALIPSO
        Sensitivity Label, then an error SHOULD be returned
        to the upper-level protocol and that error MAY be
        logged.  No further attempt to send this datagram
        should be made.

        3.  Access Control:

        Once the datagram is marked and the sending logical
        interface is selected (by the routing code), the
        datagram's Sensitivity Label is compared against the
        Sensitivity Label range(s) associated with that logical
        interface.  For the datagram to be sent, the interface
        MUST list the DOI of the datagram Sensitivity Label as
        one of the permissible DOI's and the datagram Sensitivity
        Label must be within range for the range associated with
        that DOI.   If the datagram fails this access test, then

Top      Up      ToC       Page 36 
        an error SHOULD be returned to the upper-level protocol
        and MAY be logged.  No further attempt to send this
        datagram should be made.

6.2.2.  Import

   When a datagram arrives at an interface on an End System, the
   receiving End System MUST:

        1.   Verify the CALIPSO checksum.  Datagrams with
             invalid checksums MUST be silently dropped.
             Such a drop event SHOULD be logged as a security
             fault with an indication of what happened.

        2.   Verify the CALIPSO has a known and valid DOI.
             Datagrams with unrecognized or illegal DOIs MUST
             be silently dropped.  Such an event SHOULD be
             logged as a security fault with an indication
             of what happened.

        3.   Verify the DOI is a permitted one for the receiving
             interface.  Datagrams with prohibited DOI values
             MUST be silently dropped.  Such an event SHOULD
             be logged as a security fault with an indication
             of what happened.

        4.   Verify the CALIPSO Sensitivity Label is within
             the permitted range for the receiving interface:

             NOTE WELL: EACH permitted DOI on an interface has
             a separate table describing the permitted range
             for that DOI.

             A datagram with a Sensitivity Label within the
             permitted range is accepted for further processing.

             A datagram with a Sensitivity Label disjoint with
             the permitted range MUST be silently dropped.
             Such an event SHOULD be logged as a security fault,
             with an indication that the packet was dropped
             because of a disjoint Sensitivity Label.  An ICMP
             error message MUST NOT be sent in this case.

             A datagram with a Sensitivity Label below the
             permitted range MUST be dropped.  This event
             SHOULD be logged as a security fault, with an
             indication that the packet was below range.
             An ICMP error message MUST NOT be sent in this case.

Top      Up      ToC       Page 37 
             A datagram with a Sensitivity Label above the
             permitted range MUST be dropped.  This event
             SHOULD be logged as a security fault, with an
             indication that the packet was above range.
             An ICMP error message MUST NOT be sent in this case.

        5.   Once the datagram has been accepted, the receiving
             system MUST use the import Sensitivity Label and DOI
             to associate the appropriate internal Sensitivity Label
             with the data in the received datagram.  This label
             information MUST be carried as part of the information
             returned to the upper-layer protocol.

6.3.  Intermediate System Processing

   This section describes CALIPSO-related processing for IPv6 packets
   transiting an IPv6 Intermediate System that claims to implement and
   comply with this specification.  This document places no additional
   requirements on IPv6 Intermediate Systems that do not claim to comply
   or conform with this document.

   The CALIPSO packet format has been designed so that one can configure
   an Intermediate System with the minimum sensitivity level, maximum
   Sensitivity Level, minimum compartment bitmap, and maximum
   compartment bitmap -- and then deploy that system without forcing the
   system to know the detailed human meaning of each Sensitivity Level
   or compartment bit value.  Instead, once the minimum and maximum
   labels have been configured, the Intermediate System can apply a
   simple algorithm to determine whether or not a packet is within range
   for a given interface.  This design should be straight-forward to
   implement in Application-Specific Integrated Circuit (ASIC) or Field
   Programmable Gate Array (FPGA) hardware, because the option format is
   simple and easy to parse, and because only a single comparison
   algorithm (defined in this RFC, hence known in advance) is needed.

6.3.1.  Input

   Intermediate Systems have slightly different rules for processing
   marked datagrams than do End Systems.  Primarily, Intermediate
   Systems do not IMPORT or EXPORT transit datagrams, they just forward
   them.  Also, in most deployments intermediate systems are used to
   provide Mandatory Access Controls to packets traversing more than one
   subnetwork.

   The following checks MUST occur before any other processing.  Upon
   receiving a CALIPSO-labeled packet, an Intermediate System must:

Top      Up      ToC       Page 38 
        1.  Determine whether or not this datagram is destined
            for (addressed to) this Intermediate System.  If
            so, then the Intermediate System becomes an End
            System for the purposes of receiving this
            particular datagram and the rules for IMPORTing
            described above are followed.

        2.  Verify the CALIPSO checksum.  Datagrams with
            invalid checksums MUST be silently dropped.  The
            drop event SHOULD be logged as a security fault
            with an indication of what happened and MAY
            additionally be logged as a network fault.

            NOTE WELL:
            A checksum failure could indicate a general network
            problem (e.g., noise on a radio link) that is
            unrelated to the presence of a CALIPSO option, but
            it also could indicate an attempt by an adversary
            to tamper with the value of a CALIPSO label.

        3.  Verify the CALIPSO has a known and valid DOI.
            Datagrams with unrecognized or illegal DOIs MUST
            be silently dropped.  Such an event SHOULD be
            logged as a security fault with an indication of
            what happened.

        4.  Verify the DOI is a permitted one for the receiving
            interface.  Datagrams with prohibited DOIs MUST be
            silently dropped.  Such a drop SHOULD be logged as
            a security fault with an indication of what
            happened.

        5.  Verify the Sensitivity Label within the CALIPSO
            is within the permitted range for the receiving
            interface:

            NOTE WELL:
            Each permitted DOI on an interface has a separate
            table describing the permitted range for that DOI.

            A rejected datagram with a Sensitivity Label below
            or disjoint with the permitted range MUST be
            silently dropped.  Such an event SHOULD be logged
            as a security fault with an indication of what
            happened.  An ICMP error message MUST NOT be sent
            in this case.

Top      Up      ToC       Page 39 
            A rejected datagram with a Sensitivity Label above
            the permitted range MUST be dropped.  The drop
            event SHOULD be logged as a security fault with an
            indication of what happened.  An ICMP error message
            MUST NOT be sent in this case.

   If and only if all the above conditions are met is the datagram
   accepted by the IPv6 Intermediate System for further processing and
   forwarding.

   At this point, the datagram is within the permitted range for the
   Intermediate System, so appropriate ICMP error messages MAY be
   created by the IP module back to the originating End System regarding
   the forwarding of the datagram.  These ICMP messages MUST be created
   with the exact same Sensitivity Label as the datagram causing the
   error.  Standard rules about generating ICMP error messages (e.g.,
   never generate an ICMP error message in response to a received ICMP
   error message) continue to apply.  Note that these locally generated
   ICMP messages must go through the same outbound checks (including MAC
   checks) as any other forwarded datagram as described in the following
   paragraphs.

6.3.2.  Translation by Intermediate Systems

   It is at this point, after input processing and before output
   processing, that translation of the CALIPSO from one DOI to another
   DOI takes place in an Intermediate System, if at all.  Section 6.4
   describes the two possible approaches to translation.

6.3.3.  Output

   Once the forwarding code has selected the interface through which the
   datagram will be transmitted, the following takes place:

        1.  If the output interface requires that all packets
            contain a CALIPSO label, then verify that the packet
            contains a CALIPSO label.

        2.  Verify the DOI is a permitted one for the sending
            interface and that the datagram is within the
            permitted range for the DOI and for the interface.

        3.  Datagrams with prohibited DOIs or with out-of-range
            Sensitivity Labels MUST be dropped.  Any drop event
            SHOULD be logged as a security fault, including
            appropriate details about which datagram was
            dropped and why.

Top      Up      ToC       Page 40 
        4.  Datagrams with prohibited DOIs or out-of-range
            Sensitivity Labels MAY result in an ICMP "Destination
            Unreachable" error message, depending upon the
            security configuration of the system.

            If the cause of the dropped packet is that the
            DOI is prohibited or unrecognized, then a reason
            code of "No Route to Host" is used.  If the dropped
            packet's DOI is valid, but the Sensitivity Label
            is out of range, then a reason code of
            "Administratively Prohibited" is used.  If an
            unlabeled packet has been dropped because the
            packet is required to be labeled, then a reason
            code of "Administratively Prohibited" is used.

            In all cases, if an ICMP Error Message is sent,
            then it MUST be sent with the same Sensitivity
            Label as the rejected datagram.

            The choice of whether or not to send an ICMP
            message, if sending an ICMP message for this case
            is implemented, MUST be configurable, and SHOULD
            default to not sending an ICMP message.  Standard
            conditions about generating ICMP error messages
            (e.g., never send an ICMP error message about a
            received ICMP error message) continue to apply.

6.4.  Translation

   A system that provides on-the-fly relabeling is said to "translate"
   from one DOI to another.  There are basically two ways a datagram can
   be relabeled:

   Either the Sensitivity Label can be converted from a CALIPSO
   Sensitivity Label, to an internal Sensitivity Label, and then back to
   a new CALIPSO Sensitivity Label, exclusive-or a CALIPSO Sensitivity
   Label can be directly remapped into a new CALIPSO Sensitivity Label.

   The first of these methods is the functional equivalent of
   "importing" the datagram then "exporting" it and is covered in detail
   in the "Import" (Section 6.2.2) and "Export" (Section 6.2.1) sections
   above.

   The remainder of this section describes the second method, which is
   direct relabeling.  The choice of which method to use for relabeling
   is an implementation decision outside the scope of this document.

Top      Up      ToC       Page 41 
   A system that provides on-the-fly relabeling without importing or
   exporting is basically a special case of the Intermediate System
   rules listed above.  Translation or relabeling takes place AFTER all
   input checks take place, but before any output checks are done.

   Once a datagram has passed the Intermediate System input processing
   and input validation described in Section 6.3.1, and has been
   accepted as valid, the CALIPSO in that datagram may be relabeled.  To
   determine the new Sensitivity Label, first determine the new output
   DOI.

   The selection of the output DOI may be based on any of Incoming DOI,
   Incoming Sensitivity Label, Destination End System, Destination
   Network, Destination Subnetwork, Sending Interface, or Receiving
   Interface, or combinations thereof.  Exact details on how the output
   DOI is selected are implementation dependent, with the caveat that it
   should be consistent and reversible.  If a datagram from End System A
   to End System B with DOI X maps into DOI Y, then a datagram from B to
   A with DOI Y should map into DOI X.

   Once the output DOI is selected, the output Sensitivity Label is
   determined based on (1) the input DOI and input Sensitivity Label and
   (2) the output DOI.  In the event the input Sensitivity Label does
   not map to a valid output Sensitivity Label for the output DOI, then
   the datagram MUST be silently dropped and the drop event SHOULD be
   logged as a security fault.

   Once the datagram has been relabeled, the Intermediate System output
   procedures described in Section 6.3.3 are followed, with the
   exception that any error that would cause an ICMP error message to be
   generated back to the originating End System instead MUST silently
   drop the datagram without sending an ICMP error message.  Such a drop
   SHOULD be logged as a security fault.



(page 41 continued on part 3)

Next RFC Part