[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 RFC 5570

Network Working Group                                         M. StJohns
Internet-Draft                             R. Atkinson, Extreme Networks
draft-stjohns-sipso-02.txt                 G. Thomas, US Dept of Defense
Expires: 11 MAY 2008                                    11 November 2007


                       Common Architecture Label
                          IPv6 Security Option
                               (CALIPSO)



Status of this Memo

   This is an Internet-Draft.

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering Task
   Force (IETF), its areas, and its working groups. Note that other groups
   may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any time.
   It is inappropriate to use Internet-Drafts as reference material or
   to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


ABSTRACT


     This document describes an optional method for encoding explicit packet
   Sensitivity Labels on IPv6 packets.  It is intended for use only within
   multi-level secure (MLS) networking environments that are both trusted
   and trustworthy.







StJohns & others                                                [Page 1]

Internet-Draft                                               11 NOV 2007


1.  INTRODUCTION


        The original IPv4 specification in RFC-791 includes an option for
   labeling the sensitivity of IP packets. That option was revised by
   RFC-1038 and later by RFC-1108. [RFC-791][RFC-1038][RFC-1108]

       One or another IP Sensitivity Label option has been in limited
   deployment for about two decades, most usually in governmental or military
   internal networks.  There are also some commercial sector deployments where
   corporate security policies require mandatory access controls be applied to
   sensitive data.  For example, some banks use MLS technology to compartment
   information known to their investment banking staff so that their trading
   staff is unaware of that information.  This document specifies the explicit
   packet labeling extensions for IPv6 packets.


1.1 History


        This document is a direct descendent of RFC-1038 and RFC-1108 and
   is a close cousin to the work done in the Commercial IP Security Option
   (CIPSO) Working Group of the Trusted Systems Interoperability Group (TSIG).
   [FIPS-188] The IP Security options defined by 1038 and 1108 were designed
   with one specific purpose in mind: to support the fielding of an IPv4
   packet encryption device called a BLACKER.  Because of this, the
   definitions and assumptions in those documents were necessarily focused on
   the US Department of Defense and the BLACKER device.  Today, packet
   Sensitivity Labeling is most commonly deployed within multi-level secure
   (MLS) environments, often composed of Compartmented Mode Workstations
   (CMWs) connected via a Local Area Network (LAN).  So the mechanism defined
   here is accordingly more general than RFC-1038 or RFC-1108 were.

         Also, the deployment of Compartmented Mode Workstations ran
   into operational constraints caused by the limited, and relatively small,
   space available for IPv4 options.  This caused one non-IETF specification
   for IPv4 packet labeling to have a large number of sub-options.
   A very unfortunate side-effect of having sub-options within an IPv4
   label option was that it became much more challenging to implement
   Intermediate System support for mandatory access controls (e.g. in
   a router or MLS guard system) and still be able to forward traffic
   at or near wire-speed.

        In the last decade, typical Ethernet link speeds have changed
   from 10 Mbps half-duplex to 1 Gbps full-duplex.  A 10 Gbps full- duplex
   Ethernet standard is widely available today.  The IEEE is actively
   developing a standard for 100 Gbps Ethernet as of this writing.
   Forwarding at those speeds typically requires support from ASICs;



StJohns & others                                                [Page 2]

Internet-Draft                                               11 NOV 2007


   supporting more complex packet formats usually require significantly
   more gates than simpler packet formats.  So the pressure to have a
   single simple option format has only increased in the past decade.

        When IPv6 was initially being developed, it was anticipated that
   the availability of IP Security, in particular the Encapsulating Security
   Payload (ESP) and the IP Authentication Header (AH), would obviate the need
   for explicit packet Sensitivity Labels with IPv6. [RFC-1825, IPSEC, AH,
   ESP] For MLS IPv6 deployments where the use of AH or ESP is practical, use
   of AH and/or ESP is recommended.  However, some application architectures,
   most often those not designed for use with Compartmented Mode Workstations
   or other Multi-Level Secure (MLS) computers, multiplex transactions at
   different sensitivity levels and/or with different privileges over a single
   transport-layer communications session. In order to maintain data
   Sensitivity Labeling for such applications, in order to be able to
   implement routing and mandatory access control decisions in routers and
   guards on a per-IP-packet basis, and for other reasons, there is a need to
   have a mechanism for explicitly labeling the sensitivity information for
   each IPv6 packet.


1.2.  Intent


        This document describes a generic way of labeling IPv6 datagrams
   to reflect their particular sensitivity.  Provision is made for
   separating data based on domain of interpretation (e.g. an agency,
   a country, an alliance, or a coalition), relative sensitivity
   (i.e. sensitivity levels), and need-to-know or formal access programs
   (i.e. compartments or categories).

        A commonly used method of encoding Releasabilities as if they were
   Compartments is also described.  This usage does not have precisely the
   same semantics as formal Releasability policies, but existing multi-level
   secure operating systems do not contain operating system support for
   releasabilities as a separate concept from compartments.

        In particular, the authors believe that this mechanism is
   suitable for deployment in UN peace-keeping operations, in NATO
   operations, in all current US Government MLS environments,
   and for deployment in other similar commercial or governmental
   environments.

        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
   "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   RFC-2119.[RFC-2119]




StJohns & others                                                [Page 3]

Internet-Draft                                               11 NOV 2007


2.  DEFINITIONS


        This section defines several terms that are important to understanding
   and correctly implementing this specification.  Because of historical
   variations in terminology in different communities, several terms have
   defined synonyms.


2.1.  Domain of Interpretation


        A Domain of Interpretation (DOI) is a shorthand way of identifying
   the use of a particular labeling, classification and handling system
   with respect to data, the computers and people who process it, and the
   networks that carry it.  The DOI policies, combined with a particular
   Sensitivity Label (which is defined to have meaning within that DOI)
   applied to a datum or collection of data, dictates which systems,
   and ultimately which persons may receive that data.  In other words,
   a label of "SECRET" by itself is not meaningful; you also have to know
   the document or data belongs to the US Department of Defense (or some
   specific commercial firm, some other government, or some multi-national
   organisation) before you can decide on who is allowed to receive the data.

        An CALIPSO DOI is an opaque identifier that is used as a pointer
   to a particular set of policies which define the Sensitivity Levels
   and Compartments present within the DOI, and by inference, to the
   "real world" (e.g. used on paper documents) equivalent labels
   (See "Sensitivity Label" below).  Registering or defining a set of
   real world security policies as a CALIPSO DOI results in a standard
   way of labeling IP data originating from End Systems "accredited" or
   "approved" to operate within that DOI and the constraints of those
   security policies.  For example, if one did this for the US Department
   of Defense, you would list all the acceptable labels such as "Secret"
   and "Top Secret", and one would link the CALIPSO DOI to the
   DOD 5200.28 and DOD 5200.1R documents which define how to mark and
   protect data with the US Department of Defense (DoD).[DoD 5200.28]
   [DoD 5200.1-R]

        The scope of the DOI is dependent on the organization creating
   it. For example, the US might establish a DOI with specific meanings
   which correspond to the normal way it labels classified documents and
   which would apply primarily to the DOD, but might also apply to other
   associated agencies.  A company or other organisation might establish
   a DOI which applies only to itself.

        Note well: A CALIPSO Domain of Interpretation is different
   from,and disjoint from, an ISAKMP/IKE Domain of Interpretation.



StJohns & others                                                [Page 4]

Internet-Draft                                               11 NOV 2007


   It is important not to confuse the two different concepts,
   even though the terms might superficially appear similar.


2.2.  Sensitivity Level


        A Sensitivity Level represents a mandatory separation of data
   based on relative sensitivity.  Sensitivity Levels ALWAYS have a
   specific ordering within a DOI.  Clearance to access a specific level
   of data also implies access to all levels whose sensitivity is
   less than that level.  For example, if the A, B and C are levels,
   and A is more sensitive than B which is in turn more sensitive
   than C (A > B > C), access to data at the B level implies access
   to C as well. As an example, common UK terms for a Sensitivity Level
   include (from low to high) "Unclassified", "Restricted", "Confidential",
   "Secret", and "Most Secret".

         Note well: A Sensitivity Level is only one component of a
   Sensitivity Label.  It is important not to confuse the two terms.
   The term "Sensitivity Level" has the same meaning as the term
   "Security Level".


2.3.  Compartment


        A Compartment represents a mandatory segregation of data based
   on formal information categories, formal information compartments,
   or formal access programs for specific types of data.  For example,
   a small startup company creates "Finance" and "R&D" compartments
   to protect data critical to its success -- only employees with a
   specific need to know (e.g. the accountants and controller for "Finance",
   specific engineers for "R&D") are given access to each compartment.
   Each Compartment is separate and distinct.  Access to one Compartment
   does not imply access to any other Compartment.  Data may be protected
   in multiple compartments (e.g. "Finance" data about a new "R&D" project)
   at the same time, in which case access to ALL of those compartments
   is required to access the data.  Employees only possessing clearance
   for a given sensitivity level (i.e. without having clearance
   for any specific compartments at that sensitivity level) do not have
   access to any data classified in any compartments (e.g. SECRET FINANCE
   dominates SECRET).

        Note Well: The term "category" has the same meaning as "compartment".






StJohns & others                                                [Page 5]

Internet-Draft                                               11 NOV 2007


2.4   Releasability


         A Releasability represents a mandatory segregation of data based
   on a formal decision to release information to others.

          For example, two companies (ACME and ACE) are engaging in a
   technical alliance.  ACME labels all information present within its
   enterprise that is to be shared as part of the alliance as REL ACE
   (e.g.COMPANY CONFIDENTIAL REL ACE).  However, unlike the compartment
   example above, COMPANY CONFIDENTIAL dominates COMPANY CONFIDENTIAL REL ACE.
   This means that ACE employees granted a COMPANY CONFIDENTIAL REL ACE
   clearance can only access releasable material, while ACME employees
   with a COMPANY CONFIDENTIAL clearance can access all information.
   If REL ACE were managed as a compartment, then users granted a
   COMPANY CONFIDENTIAL REL ACE clearance would have access to all of
   ACME's COMPANY CONFIDENTIAL material, which is undesirable.
   Releasabilities can be combined (e.g. COMPANY CONFIDENTIAL REL ACE/ABLE).
   In this case, users possessing a clearance of either COMPANY CONFIDENTIAL,
   COMPANY CONFIDENTIAL REL ACE, COMPANY CONFIDENTIAL REL ABLE,
   or COMPANY CONFIDENTIAL REL ACE/ABLE can access this information.

        Historically, most MLS deployments handled Releasability
   as if it were an inverted Compartment.  Strictly speaking, this
   can be problematic, because the formal semantics of a compartment
   are different from the formal semantics of a Releasability.
   In practice, for some years now some relatively large MLS deployments
   have been encoding Releasabilities as if they were inverted
   Compartments.  The results have been generally acceptable and
   those deployments are generally considered successful by their
   respective user communities.


2.5.  Sensitivity Label


        A Sensitivity Label is a quadruple consisting of a DOI,
   a Sensitivity Level, a Compartment Set, and a Releasability Set.
   The Compartment Set may be the empty set if and only if no compartments
   apply.  A Releasability Set may be the empty set if and only if
   no releasabilities apply.  A DOI used within a end system may be
   implicit or explicit depending on its use.  CALIPSO Sensitivity
   Labels always have an explicit DOI.  A CALIPSO Sensitivity Label
   consists of a Sensitivity Label in a particular format (defined below).
   A CALIPSO Sensitivity Label ALWAYS contains an explicit DOI value.
   In a CALIPSO Sensitivity Label, the Compartment Bitmap field is used
   to encode both the logical Compartment Set and also the logical
   Releasability Set.



StJohns & others                                                [Page 6]

Internet-Draft                                               11 NOV 2007


          A system which does not store a DOI as part of its internal
   Sensitivity Labels must be considered to have an implicit DOI --
   usually that of its primary Accrediting Authority; all objects
   on such a system inherit this implicit DOI.

        Note Well: The term "Security Marking" has the same meaning
   as "Sensitivity Label".

2.5.1 Sensitivity Label Comparison

        Two Sensitivity Labels (A and B) can be compared. Indeed, the
   only real reason that Sensitivity Labels exist is so that they may be
   compared as part of an access control decision.  Comparison is critical
   to determining if a subject (a person, network, etc.) operating at one
   Sensitivity Label (A) should be allowed to access an object (file,
   packet,route, etc) classified at another Sensitivity Label (B).  The
   comparison of two labels (A and B) can return one (and only one)
   of the following results:

     1) A can dominate B (e.g. A=SECRET, B=UNCLASSIFIED); A can read B
     2) B can dominate A (e.g. A=UNCLASSIFIED, B=SECRET); A cannot access B
     3) A equals B (e.g. A=SECRET, B=SECRET); A can read/write B
     4) A is incomparable to B (e.g. A=SECRET R&D, B=SECRET FINANCE);
        A cannot access B


        By definition, if A and B are members of different DOIs,
   the result of comparison is always incomparable.  It is possible
   to overcome this if and only if A and/or B can be promoted such that
   the labels are interpretable within a single DOI.

2.5.2  Range

        A range is a pair of Sensitivity Labels which indicate both
   a minimum and a maximum acceptable Sensitivity Label for objects
   compared against it.  A range is usually expressed as
   "<minimum> : <maximum>" and always has the property that the minimum
   Sensitivity Label is less than or equal to the maximum Sensivitity Label.
   In turn, this requires that the two Sensitivity Labels MUST be
   comparable.

        A range where <minimum> equals <maximum> may be expressed
   simply as  "<minimum>"; in this case, the only acceptable
   Sensitivity Label is <minimum>.







StJohns & others                                                [Page 7]

Internet-Draft                                               11 NOV 2007


2.6.  Import

        The act of receiving a datagram and translating the CALIPSO
   Sensitivity Label of that packet into the appropriate internal
   (i.e. End System specific) Sensitivity Label.

2.7.  Export

        The act of selecting an appropriate DOI for an outbound datagram,
   translating the internal (End System specific) label into an CALIPSO
   Sensitivity Label based on that DOI, and sending the datagram.  The
   selection of the appropriate DOI may be based on many factors including,
   but not necessarily limited to:

        Source Port
        Destination Port
        Transport Protocol
        Application Protocol
        Application Information
        End System
        Subnetwork
        Network
        Sending Interface
        System Implicit/Default DOI

        Regardless of the DOI selected, the Sensitivity Label of the
   outbound datagram must be consistent with the security policy monitor
   of the originating system and also with the DOI definition used by all
   other devices cognisant of that DOI.

2.8.  End System

        An End System (ES) is a host or router from which a datagram
   originates or to which a datagram is ultimately delivered.  The IPv6
   community often uses the term Node for what is here called an End System.

2.9.  Intermediate System

        An Intermediate System (IS) is a node that receives and transmits
   a particular datagram without being either the source or destination
   of that datagram.  An IPv6 router is an example of an Intermediate System.
   A firewall or security guard device that applies security policies and
   forwards packets that comply with those security policies is another
   example of an intermediate system.

        An intermediate system may handle ("forward") a datagram
   without necessarily importing or exporting the datagram to/from itself.




StJohns & others                                                [Page 8]

Internet-Draft                                               11 NOV 2007


        NOTE WELL: Any given system can be both an end system and an
   intermediate system -- which role the system assumes at any given time
   depends on the address(es) of the datagram you are considering and the
   address(es) associated with that system.

2.10 System Security Policy

        A system security policy (SSP) consists of a Sensitivity Label
   and the organizational security policies associated with content labeled
   with a given security policy.  The SSP acts as a bridge between how
   the organization's Mandatory Access Control (MAC) policy is stated
   and managed and how the network implements that policy.

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 also
   exist. For example, one global electrical equipment company has
   a formal security policy that defines 6 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 & 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 its 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
   organisations 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



StJohns & others                                                [Page 9]

Internet-Draft                                               11 NOV 2007


   automatically, and is permitted if and only if a person with
   appropriate "downgrade" privilege manually verifies the information
   is permitted to be downgraded before the s/he manually re-labels
   (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).  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 standards for encoding
   Sensitivity Labels in packets, as well as certain standards for how
   these 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] [CMW] [ISO-15408] [CC] [DoD MLOS PP]

         This standard 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 an 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 a 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 the Bell-LaPadula model, but is extended to cover the concept of



StJohns & others                                               [Page 10]

Internet-Draft                                               11 NOV 2007


   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 a 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.

        Some existing MLS deployments already use more than one DOI
   concurrently.  User feedback from early drafts of this specification
   indicates that it is not uncommon 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
   organisation) that owns and operates that particular network link.
   On such a link, one CALIPSO DOI would typically be used for the
   "coalition" traffic and a 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).

        Additionally, operational experience with existing MLS systems
   has shown that if a system only supports a single DOI at a given time,



StJohns & others                                               [Page 11]

Internet-Draft                                               11 NOV 2007


   then it is impossible for a deployment to migrate from using one
   DOI value to a different DOI value in a smooth, lossless manner.

        Therefore, a node that implements this specification MUST
   be able to support at least 2 CALIPSO DOIs concurrently.  Support
   for more than 2 concurrent CALIPSO DOIs is encouraged.  This
   requirement to support at least 2 CALIPSO DOIs concurrently is
   not necessarily an implementation constraint upon portions of
   the MLS system 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,
        2) Publish a table of equivalencies which maps the CALIPSO
           values of one DOI into the other and make that table
           available within the 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 which are a subset of the full table of equivalences.
   Actual administration of inter-DOI agreements is outside the scope
   of this document.

        When data leaves an end system it is "exported" to the network,
   and marked with a particular DOI, Sensitivity Level, and
   Compartment Set. (This quadruple 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.  The export DOI
   is selected based on a range of parameters described in detail later
   in this document.

         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



StJohns & others                                               [Page 12]

Internet-Draft                                               11 NOV 2007


   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.

        An host or router 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.  Each physical interface
   has one or more Sensitivity Label ranges associated with it.
   Sensitivity Label ranges from multiple DOIs must be enumerated
   separately.  Multiple ranges from the same DOI are permissible.

        Each host or router also might have one or more logical
   network interfaces. A given logical interface is associated with one
   and only one physical interface.  A given physical interface might
   have more than one associated logical interface.  For example, a
   single Ethernet port might have multiple [IEEE 802.1Q] Virtual LANs
   (VLANs) associated with it, where each VLAN could be a separate
   logical interface.   Each logical interface has one or more
   Sensitivity Label ranges associated with it.  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.

        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.

        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 authorised to provide on-the-fly re-labeling of packets at the
   boundaries between complete systems of hosts within a single
   DOI.  Typically, such systems require specific certification(s)
   and accreditation(s) before deployment or use.

4. DEFAULTS

        Each Intermediate System or End System is responsible for
   properly interpreting and enforcing the 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



StJohns & others                                               [Page 13]

Internet-Draft                                               11 NOV 2007


   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 arriving at a node with an invalid
   (e.g. out of range) Sensitivity Label MUST be dropped.  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 need to be applied on each
   hop a CALIPSO-labelled packet traverses, not merely at the end
   points of a labelled IP session.

        If a packet is received from an node which is not aware of
   CALIPSO Sensitivity Labels (i.e. unaware to assign Sensitivity Labels
   itself) and the packet is destined for an node which is sensitivity
   label aware, the receiving node will insert a Sensitivity Label.
   This Sensitivity Label will be equal to the maximum Sensitivity Label
   assigned to the originating node if that is known.  If the receiving
   node does not know which Sensitivity Label is assigned to the originating
   node, the maximum Sensitivity Label of the interface the packet was
   received upon will be inserted.

        If a packet is to be sent to an node which is defined to not
   be Sensitivity Label aware, from an node which 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.


5.  FORMAT

        This section describes the format of the CALIPSO option for use
   with IPv6 datagrams.  CALIPSO is an IPv6 hop-by-hop option to ensure
   that a security gateway or router could apply access controls to
   IPv6 packets based on the CALIPSO label carried by the packet.
   An IPv6 datagram MUST NOT ever contain more than one CALIPSO label.

        This option format is designed with intermediate systems in mind.
   It is now common for a 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 used a syntax that was unduly complex to implement in IP
   routers.  So there is a deliberate effort to choose a streamlined
   packet syntax that is easy to parse, to encode, and to implement
   generally.



StJohns & others                                               [Page 14]

Internet-Draft                                               11 NOV 2007


5.1.  Option Format

   ------------------------------------------------------------
   | Option Type | Option Length | Cmpt Length | Sens Level   |
   +-------------+---------------+-------------+--------------+
   |             CALIPSO Domain of Interpretation             |
   +-------------+---------------+-------------+--------------+
   |                     Checksum (CRC-32)                    |
   ------------------------------------------------------------
   |      Compartment Bitmap (Optional; variable length)      |
   +-------------+---------------+-------------+--------------+


5.1.1.  OPTION TYPE field

      This field contains an unsigned 8-bit value.  Its value is (to be
   assigned by IANA).  In the event the IPv6 packet is fragmented by the
   sending system, this option must be copied on fragmentation.

      The CALIPSO option is an IPv6 Hop-by-Hop Option.  Following the
   nomenclature of RFC-2460, Section 4.2, the Option Data field of this
   option must have 4n+2 alignment.[RFC-2460] The Option Data MUST not
   change en-route. If the option type is not recognised by an intermediate
   system examining the packet, the option MAY be ignored.  If the option
   type is not recognised by an End System receiving the packet, then the
   packet MUST be dropped.

5.1.2.  OPTION LENGTH field

        This field contains an unsigned integer 1 octet in size.  It has
   minimum value is 10.  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 64-bit words.
   The minimum value is zero, which is only when the information in
   this packet is not in any compartment.

        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 the sum of the
   set of logical Compartments and the set of logical Releasabilities.




StJohns & others                                               [Page 15]

Internet-Draft                                               11 NOV 2007


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.

   NOTE WELL: The DOMAIN OF INTERPRETATION 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   RESERVED field

        This field is reserved.  It MUST be set to all zeros by the
   originating node.  Receiving systems MUST zero this field upon receipt
   in order to reduce the potential bandwidth of network-derived covert
   channels.

5.1.8.  CRC-32 Checksum Field

        This field contains an unsigned 32-bit integer containing the
   CRC-32 checksum calculated over the entire CALIPSO option in this packet.
   The checksum algorithm is the 32-bit CRC defined by ITU. [ITU-T V.42]
   For processing simplicity, this is always present, even when AH is used.

5.1.9.  Compartment Bitmap

        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



StJohns & others                                               [Page 16]

Internet-Draft                                               11 NOV 2007


   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.  When encoding a Releasability
   on the wire, a "1" in the corresponding bit of the Compartment
   Bitmap indicates that the data is not releasable to the indicated
   Release Group and a  "0" in the corresponding bit of the Compartment
   Bitmap indicates the data is releasable to the indicated
   Release Group.  This permits 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 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 and most End Systems perform best when
   processing fixed length, fixed location items.  So the IPv6 base
   specification levies certain requirements on IPv6 optional headers.
   So the Compartment Bitmap field must have length in quanta of 64-bit
   words (e.g. 0 bits, 64 bits, 128 bits)

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 (MAC)
   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:




StJohns & others                                               [Page 17]

Internet-Draft                                               11 NOV 2007


     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
     A:IGNOR      = Sensitivity Label A, less the compartment bits
                     represented in IGNOR

6.1.1.  "Within Range"

        A Sensitivity Label, "M", is "within range" for a particular range
   "LO:HI:IGNOR" while considering a set of ignorable compartments IGNOR,
   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:IGNOR is
              valid if and only if HI:IGNOR is greater than LO:IGNOR.

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

        3.  The Sensitivity Label M has a Sensitivity Level which is
            greater than or equal to the Sensitivity Level contained
            in the low-end Sensitivity Label (LO) from the range and
            which is less than equal to the Sensitivity Level contained
            in the high-end Sensitivity Label (HI) from the range.

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

   AND

        4.  The Sensitivity Label M has a Compartment set which is a
            superset (proper or otherwise) of the compartment set
            contained in the Sensitivity Label from the low-end range
            (LO) and which is a subset (proper or otherwise) of the
            compartment set contained in the high end sensitivity
            label (HI) from the range.

            ((LO.COMP & ^IGNOR) <= (M.COMP & ^IGNOR) <= (HI.COMP & ^IGNOR))


6.1.2.  "Less Than" or "Below Range"

        A Sensitivity Label "M" is "less than" a Sensitivity Label "LO"
   while considering a set of ignorable compartments IGNOR, if and only if:

        1.   The DOI for the Sensitivity Label M is identical to the



StJohns & others                                               [Page 18]

Internet-Draft                                               11 NOV 2007


             DOI for both the low-end and high-end of the range.

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

        2.   The sensitivity level of M is less than the sensitivity
             level of A.

             (M.LEV < LO.LEV)

        3.   M.COMP is a subset (proper or otherwise) of A.COMP,
             excluding compartments specified in IGNOR.

             (M.COMP & ^IGNOR) <= (LO.COMP & ^IGNOR)

   A Sensitivity Label "M" is "below range" for a Sensitivity Label
   "LO:HI:IGNOR", if M:IGNOR is less than LO:IGNOR.

6.1.3.  "Greater Than" or "Above Range"

        A Sensitivity Label, "M" is "greater than" a Sensitivity Label "HI"
   while considering a set of ignorable compartments IGNOR if and only if:

        1.   Their DOI's are identical.

             (M.DOI == HI.DOI)

        2A.  The Sensitivity Label M's sensitivity level is greater than
             B's level while M's compartment set is a superset (proper or
             otherwise) of B's compartment set

             (M.LEV > HI.LEV) &&
             ((M.COMP & ^IGNOR) >= (HI.COMP & ^IGNOR))

   XOR

        2B.  M's level is greater than or equal to A's level,
             while M's compartment set is a proper superset of A's
             compartment set.

             (M.LEV >= HI.LEV) && ((M.COMP & ^IGNOR) >= (HI.COMP & ^IGNOR))

   A Sensitivity Label, "M", is "above range" for a Sensitivity Label,
   "LO:HI:IGNOR", if M:IGNOR is greater than B:IGNOR.

6.1.4.  "Equal To"

        A Sensitivity Label "A" is "equal to" another Sensitivity Label "B"
   while considering a set of ignorable compartments IGNOR if and only if:



StJohns & others                                               [Page 19]

Internet-Draft                                               11 NOV 2007


        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, while considering
            a set of ignorable compartment bits IGNOR.

            ((A.COMP & ^IGNOR) == (B.COMP & ^IGNOR))

6.1.5.  "Disjoint" or "Incomparable"

        A Sensitivity Label "A" is disjoint from another Sensitivity Label
   "B" while considering a set of ignorable compartments IGNOR if any
   of these conditions are true:

        1.   Their DOI's differ.

             (A.DOI <> B.DOI)

        2.   They are neither less than, nor greater than,
             nor equal to each other.

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

        3.   Their compartment sets are disjoint from each
             other

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


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.  Nothing in this document applies
   to an IPv6 End System that does not claim to implement or conform
   with this specification.

6.2.1  Export

        An end system which 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:



StJohns & others                                               [Page 20]

Internet-Draft                                               11 NOV 2007


        1. Selection of the export DOI:

        a)     If the system implements or permits only one
               DOI, that DOI is the export DOI.
        b) elseIf the upper level protocol selects a DOI, that
               DOI is the one used.

               Note Well:
                          A connection-oriented transport-layer
               protocol session (e.g. TCP session, SCTP session)
               MUST have the same DOI and Sensitivity Label
               for the life of the 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.

        c) elseIf 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.
        d) elseIf there is a specific DOI associated with the
           sending logical interface (i.e. IP address),
               then that DOI is selected.
        e)     Else the default DOI for the system is selected.

   Note Well:
              In the event the End System selects and uses a specific
   DOI and that DOI is not recognised by the originating End System'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
   represents either incorrect configuration of either the Intermediate
   System or of the End System -- xor 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 standard (e.g. with
   different VLAN IDs corresponding to different sensitivity ranges)
   might ease proper system configuration in this respect.

        2.  Export Labeling:



StJohns & others                                               [Page 21]

Internet-Draft                                               11 NOV 2007


             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
        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 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 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.

        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.

        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.

        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.



StJohns & others                                               [Page 22]

Internet-Draft                                               11 NOV 2007


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

             A datagram which has 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.

              datagram which has a Sensitivity Label below
             the permitted range MUST be dropped.  This event
             SHOULD be logged as a security fault.  An ICMP
             error message MUST NOT be sent in this case.

             A datagram with a Sensitivity Label above the
             permitted range MUST be dropped.  This event
             SHOULD be logged.  An ICMP error message MUST NOT
             be sent in this case.

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

6.3.  Intermediate System Rules

        This section describes CALIPSO-related processing for IPv6 packets
   transiting an IPv6 Intermediate System that claims to implement and
   comply with this specification.  Nothing in this document applies
   to an IPv6 Intermediate System that does not claim to comply
   with this specification.

        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 ASIC or 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.




StJohns & others                                               [Page 23]

Internet-Draft                                               11 NOV 2007


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:

        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 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.

        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.

        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.




StJohns & others                                               [Page 24]

Internet-Draft                                               11 NOV 2007


             A rejected datagram which has a Sensitivity Label below
             or disjoint with the permitted range MUST be silently
             dropped.  Such an event SHOULD be logged as a security
             fault, including details about the fault.  An ICMP
             error message MUST NOT be sent in this case.

             A rejected datagram with a Sensitivity Label above the
             permitted range MUST be dropped.  The drop event
             SHOULD be logged as a security fault.  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

        It is at this point that TRANSLATION of the CALIPSO takes place
   if at all.  Please see Section 6.4 for a discussion of the appropriate
   processing for 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.  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.

        2.  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.



StJohns & others                                               [Page 25]

Internet-Draft                                               11 NOV 2007


        3.  Datagrams with prohibited DOIs or out of range
            Sensitivity Labels MAY result in an appropriate ICMP
            error message, depending upon the security configuration
            of the system.  If an ICMP Error Message is sent, 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 OFF.
            Standard conditions about generating ICMP error
            messages (e.g. never send an ICMP error message
            about a received ICMP error message) apply.

6.4.  Translation

        A system which provides on-the-fly re-labeling 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, XOR 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" and "Export" sections above.  This section describes
   direct relabeling.  The choice of which method to use for relabeling
   is an implementation decision outside the scope of this document.

        A system which 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 been accepted (passing all the appropriate
   checks described in section 5.3), it may be relabeled.  To determine the
   new Sensitivity Label, first determine the new DOI.  The selection of the
   new DOI may be based on any of DESTINATION END SYSTEM, DESTINATION
   NETWORK, DESTINATION SUBNET, 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.



StJohns & others                                               [Page 26]

Internet-Draft                                               11 NOV 2007


        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 is re-labeled, the output procedures under
   Section 5.3 "Intermediate Systems" are followed, with the exception
   that any error that would cause a ICMP error message to be generated
   back to the originating End System instead MUST drop the datagram.
   Such a drop SHOULD be logged as a security fault.

7.  IMPLEMENTATION ISSUES AND HINTS

        The following are "hints" not "requirements".  Implementation
   experience could eventually turn some of them into implementation
   requirements.

7.1.  Intermediate Systems

        Performance is optimised if there is hardware support
   for applying the mandatory access controls based on this label option.

7.2.  End Systems

        It is possible to create two DOIs with different overlapping
   compartment ranges.  This can be used to reduce the size of the IPv6
   Sensitivity Label option in some deployments.

7.3.  Upper-Level Protocols

        As CALIPSO is an IP option, this document focuses upon
   the network-layer handling of packets containing CALIPSO options.
   This section provides some discussion of upper-layer protocol issues.

        This section is not a complete specification for how an
   MLS host handles information internally after the decision has been
   made to accept a received IPv6 packet containing a CALIPSO option.
   Implementers of MLS systems might wish also to consult [TCSEC],
   [CMW], [CC], [ISO-15408], and [DoD MLOS PP].

        In a typical MLS host, the information received from
   the network (i.e. information not dropped by the network-layer
   as a result of the CALIPSO processing described in this document)
   is assigned an internal Sensitivity Label while inside the host
   operating system.  The MLS host uses the Bell-LaPadula Mandatory
   Access Control policy [BL73] to determine how that information



StJohns & others                                               [Page 27]

Internet-Draft                                               11 NOV 2007


   is processed, including to which transport-layer sessions or
   to which applications the information is delivered.

        Within this section, we use one additional notation,
   in an attempt to be both clear and concise.  Here, the string
   "W:XY" defines a Sensitivity Label where the sensitivity level
   is W && where X and Y are the only compartments enabled,
   while the string "W::" defines a Sensitivity Label where the
   sensitivity level is W and there are no compartments enabled.

7.3.1.  TCP-related issues

        With respect to a network, each distinct Sensitivity Label
   represents a separate virtual network which shares the same
   physical network.

        The above statement taken from section 3 has a non-obvious,
   but critical, corollary.  If there are separate virtual networks
   then it is possible for a system which exists in multiple virtual
   networks to have identical TCP connections, each one existing
   in a different virtual network.

        TCP connections are normally identified by source and
   destination port, and source and destination address.  If a system
   labels datagrams with the CALIPSO option (which it must do if it
   exists in multiple virtual networks - e.g. a "multi-level secure"
   system), then TCP connections are identified by source and destination
   port, source and destination address, and a Sensitivity Label
   (optionally, a Sensitivity Label range).

        CALIPSO-labelled TCP data that is received should be sent to all
   TCP listeners for that particular TCP connection where the Sensitivity
   Label of the received TCP data is within range for that listener.

7.3.2.  UDP-related Issues

        Unlike TCP or SCTP, UDP is a stateless protocol, at least
   conceptually.  However, many implementations of UDP have some
   session state (e.g. Protocol Control Blocks in 4.4 BSD), although
   the UDP protocol specifications do not require any state.

        One consequence of this is that in widely used host
   implementations of UDP and IPv6, a UDP listener might be bound only
   to a particular UDP port on its host -- without binding to a
   particular remote IP address or local IP address.

        Datagrams addressed to a UDP port SHOULD be delivered to all
   listeners on that destination UDP port whose Sensitivity Label range



StJohns & others                                               [Page 28]

Internet-Draft                                               11 NOV 2007


   includes the Sensitivity Label of the received UDP datagram.

        For example, if a listener on UDP port X has a Sensitivity
   Label range with a minimum of "S:AB" and a maximum of "S:AB",
   then only datagrams with a destination of UDP port X and a
   Sensitivity Label of "S:AB" will be delivered to that listener.

        For example, if a listener on UDP port Y has a Sensitivity
   Label range with a minimum of "W::" and a maximum of "X:ABC"
   (where X dominates W), then a datagram addressed to UDP port Y
   with a Sensitivity Label of "W:A" normally would be delivered
   to that listener.

7.3.3.  SCTP-related Issues

        With respect to a network, each distinct Sensitivity Label
   represents a separate virtual network which shares the same
   physical network.

        The above statement taken from section 3 has a non-obvious,
   but critical, corollary.  If there are separate virtual networks
   then it is possible for a system which exists in multiple virtual
   networks to have identical SCTP connections, each one existing
   in a different virtual network.

        As with TCP, SCTP is a connection-oriented transport
   protocol and has substantial session state.  In single-level hosts,
   this state includes the set of remote IP addresses, the set of local
   IP addresses, the remote SCTP port number, and the local SCTP port
   number.  In MLS hosts, the SCTP session state also includes the
   Sensitivity Label (or, optionally, the Sensitivity Label range)
   for each SCTP session.  Unlike TCP, SCTP has the ability to shift
   an existing SCTP session from one endpoint IP address to a different
   IP address that belongs to the same endpoint.

        CALIPSO-labelled SCTP data that is received should be sent
   to all SCTP listeners for that particular SCTP connection where the
   Sensitivity Label of the received SCTP data is within range for that
   listener's Sensitivity Label range.

        Further, although a node might be multi-homed, it is entirely
   possible that only one of those interfaces is reachable for a given
   Sensitivity Label value.  For example, one network interface on a node
   might have a Sensitivity Label range from "A::" to "B:XY" (where B
   dominates A), while a different network interface on the same node might
   have a Sensitivity Label range from "U::" "U::" (where A dominates U).
   In that example, if a packet has a CALIPSO label of "A:X", then that
   packet will not be able to use the "U"-only network interface.  This



StJohns & others                                               [Page 29]

Internet-Draft                                               11 NOV 2007


   might lead to novel operational issues with SCTP sessions.  Implementers
   ought to give special attention to this SCTP-specific issue.

SECURITY CONSIDERATIONS

        This document describes a mechanism for adding explicit
   Sensitivity Labels to IPv6 datagrams.  The primary purpose of these
   labels is to facilitate application of Mandatory Access Controls (MAC)
   in End Systems or Intermediate Systems that implement this
   specification.  As such, correct implementation of this mechanism
   is very critical to the overall security of the systems and networks
   where this mechanisms is deployed.  Use of high-assurance development
   techniques is encouraged.

        A concern is that since this label is used for mandatory
   access controls, some method of binding the Sensitivity Label
   option to the rest of the packet is needed.  Without such binding,
   malicious modification of the Sensitivity Label in a packet
   would go undetected.  So, implementations of this Sensitivity Label
   option MUST also implement support for the IP Authentication Header.
   Implementations MUST permit the system administrator to configure
   whether AH is used or not.

        This mechanism is only intended for deployment in very limited
   circumstances where a set of systems and networks are in a well-protected
   operating environment and the threat of external or internal attack
   on this mechanism is considered acceptable to the accreditor of those
   systems and networks.  Accreditors of a given deployment should
   consider not only personnel clearances and physical security issues,
   but also electronic security (e.g. TEMPEST), network security (NETSEC),
   communications security (COMSEC), and other issues.

IANA CONSIDERATIONS

        IANA is requested to assign an IPv6 Hop-by-Hop option number
   to the CALIPSO option described in this specification.  This option
   is immutable during transit.

        Also, IANA is requested to create a registry for CALIPSO DOI
   values.  The initial values for this registry, shown in dotted-quad
   format, are as follows:

      DOI Value                  Organisation or Use
      0.0.0.0                    Null DOI; must not be used on the network
      0.0.0.1 to 0.255.255.255   For private use among consenting parties


        For the CALIPSO DOI values registry, IANA is requested to issue



StJohns & others                                               [Page 30]

Internet-Draft                                               11 NOV 2007


   a new DOI value to any organisation that requests it.  Assignment
   information normally should be made available on the IANA website.
   A commercial organisation will normally only be assigned one or two
   DOI values.  A national government or multi-national treaty organisation
   may be assigned a range of values if that is requested.  Different
   departments within a given national government each may independently
   request a range of values.

ACKNOWLEDGEMENTS

        This document is directly derived from an Internet-Draft titled
   "Son of IPSO (SIPSO)" written by the first author circa 1992.  Packet
   format changes have been made since that draft, primarily to comply
   with IPv6 syntax rules.

        Steve Brenneman, L.C. Bruzenak, Jarrett Lu, Paul Moore, and
   Bill Sommerfeld (in alphabetical order) provided feedback on earlier
   versions of this document.  We also would like to thank the several
   anonymous reviewers, particularly for sharing their insights into
   operational considerations with MLS networking.

INFORMATIVE REFERENCES
      [BL73]         Bell, D.E. & LaPadula, L.J., "Secure Computer Systems:
                     Mathematical Foundations and Model", Technical Report
                     M74-244, The MITRE Corporation, Bedford, MA, May 1973.

      [CMW]          US Defense Intelligence Agency, "Compartmented Mode
                     Workstation Evaluation Criteria", Technical Report
                     DDS-2600-6243-91, Washington, DC.

      [DOD 5200.1]   US Department of Defense, "DoD Information Security
                     Program", Directive 5200.1, 13 December 1996.

      [DOD 5200.1-R] US Department of Defense, "Information Security Program
                     Regulation", DoD 5200.1-R, 17 January 1997.

      [DoD 5200.28]  US Department of Defense, "Security Requirements
                     for Automated Information Systems," Directive 5200.28,
                     21 March 1988.

      [DoD MLOS PP]  US Department of Defense, "Protection Profile
                     for Multi-level Operating Systems in Environments
                     requiring Medium Robustness, Version 1.22, 23 May
                     2001

      [ISO-15408]    International Stanards Organisation, "Evaluation
                     Criteria for IT Security", ISO/IEC 15408, 2005.




StJohns & others                                               [Page 31]

Internet-Draft                                               11 NOV 2007


      [CC]           "Common Criteria for Information Technology Security
                     Evaluation", Version 3.1, Revision 1, CCMB-2006-09-001,
                     September 2006.

      [TCSEC]        US Department of Defense, "Trusted Computer System
                     Evaluation Criteria", DoD 5200.28-STD, 26 December 1985.

      [DoD 8500.1]   US Department of Defense, "Information Assurance",
                     Directive 8500.1, 24 October 2002.

      [FIPS-188]     US National Institute of Standards & Technology,
                     "Standard Security Labels for Information Transfer",
                     Federal Information Processing Standard (FIPS) 188,
                     September 1994.

      [RFC-791]      J. Postel, Internet Protocol, RFC-791, September 1981.

      [RFC-1038]     M. StJohns, Draft Revised IP Security Option, RFC-1038,
                     January 1988.

      [RFC-1108]     S. Kent, US DoD Security Options for the Internet
                     Protocol, RFC-1108, November 1991.

      [RFC-1825]     R. Atkinson, Security Architecture for the Internet
                     Protocol, RFC-1825, August 1995.

      [RFC-2119]    S. Bradner, "Key words for use in RFCs to Indicate
                    Requirement Levels", RFC-2119, March 1997.

      [IPSEC]       S. Kent, "Security Architecture for the Internet
                    Protocol", RFC-4301, December 2005.

      [AH]          S. Kent, "IP Authentication Header", RFC-4302,
                    December 2005.

      [ESP]         S. Kent, "IP Encapsulating Security Payload", RFC-4303,
                    December 2005.

NORMATIVE REFERENCES

      [RFC-2460]     S. Deering & R. Hinden, Internet Protocol Version 6
                     Specification, RFC-2460, December 1998.

      [ITU-T V.42]   ITU-T, modem standard V.42 (for CRC-32 definition)
                     XXX [Is this the correct reference ?]






StJohns & others                                               [Page 32]

Internet-Draft                                               11 NOV 2007


AUTHORS:

   M. StJohns
   Germantown, MD

   R. Atkinson
   Extreme Networks
   3585 Monroe Street
   Santa Clara, CA
   USA 95051

   rja@extremenetworks.com
   +1 (408)579-2800

   G. Thomas
   US Department of Defense
   Washington, DC
   USA

IETF IPR Clause

     The IETF takes no position regarding the validity or scope of any
     Intellectual Property Rights or other rights that might be claimed
     to pertain to the implementation or use of the technology
     described in this document or the extent to which any license
     under such rights might or might not be available; nor does it
     represent that it has made any independent effort to identify any
     such rights.  Information on the procedures with respect to rights
     in RFC documents can be found in BCP 78 and BCP 79.

     Copies of IPR disclosures made to the IETF Secretariat and any
     assurances of licenses to be made available, or the result of an
     attempt made to obtain a general license or permission for the use
     of such proprietary rights by implementers or users of this
     specification can be obtained from the IETF on-line IPR repository
     at http://www.ietf.org/ipr.

     The IETF invites any interested party to bring to its attention
     any copyrights, patents or patent applications, or other
     proprietary rights that may cover technology that may be required
     to implement this standard.  Please address the information to the
     IETF at ietf-ipr@ietf.org.

COPYRIGHT

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions contained



StJohns & others                                               [Page 33]

Internet-Draft                                               11 NOV 2007


   in BCP 78, and except as set forth therein, the authors retain all their
   rights.

   This document and the information contained herein are provided on an "AS
   IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS
   SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE
   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
   OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

   Draft Expires: 11 MAY 2008







































StJohns & others                                               [Page 34]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/