tech-invite   World Map     

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

RFC 5570

 Errata 
Informational
Pages: 52
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: ~rtg

Common Architecture Label IPv6 Security Option (CALIPSO)

Part 1 of 3, p. 1 to 19
None       Next RFC Part

 


Top       ToC       Page 1 
Network Working Group                                        M. StJohns
Request for Comments: 5570                                   Consultant
Category: Informational                                     R. Atkinson
                                                       Extreme Networks
                                                              G. Thomas
                                               US Department of Defense
                                                              July 2009


        Common Architecture Label IPv6 Security Option (CALIPSO)

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.

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

IESG Note

   This RFC specifies the use of an IPv6 hop-by-hop option.  The IESG
   notes that general deployment of protocols with hop-by-hop options
   are problematic, and the development of such protocols is
   consequently discouraged.  After careful review, the IETF has
   determined that a hop-by-hop option is an appropriate solution for
   this specific limited environment and use case.  Furthermore, the
   mechanism specified in this RFC is only applicable to closed IP
   networks.  It is unsuitable for use and ineffective on the global
   public Internet.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Page 2 
   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Top       Page 3 
Table of Contents

   1. Introduction ....................................................4
      1.1. History ....................................................4
      1.2. Intent and Applicability ...................................6
      1.3. Deployment Examples ........................................7
   2. Definitions .....................................................9
      2.1. Domain of Interpretation ...................................9
      2.2. Sensitivity Level .........................................10
      2.3. Compartment ...............................................10
      2.4. Releasability .............................................11
      2.5. Sensitivity Label .........................................16
      2.6. Import ....................................................17
      2.7. Export ....................................................17
      2.8. End System ................................................18
      2.9. Intermediate System .......................................18
      2.10. System Security Policy ...................................19
   3. Architecture ...................................................19
   4. Defaults .......................................................24
   5. Format .........................................................26
      5.1. Option Format .............................................27
      5.2. Packet Word Alignment Considerations ......................30
   6. Usage ..........................................................31
      6.1. Sensitivity Label Comparisons .............................31
      6.2. End System Processing .....................................34
      6.3. Intermediate System Processing ............................37
      6.4. Translation ...............................................40
   7. Architectural and Implementation Considerations ................41
      7.1. Intermediate Systems ......................................42
      7.2. End Systems ...............................................43
      7.3. Upper-Layer Protocols .....................................43
   8. Security Considerations ........................................46
   9. IANA Considerations ............................................48
      9.1. IP Option Number ..........................................48
      9.2. CALIPSO DOI Values Registry ...............................49
   10. Acknowledgments ...............................................50
   11. References ....................................................50
      11.1. Normative References .....................................50
      11.2. Informative References ...................................50

Top      ToC       Page 4 
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 [RFC791] [RFC1038] [RFC1108].
   Although the IETF later deprecated RFC 1108, that IPv4 option
   continues to be in active use within a number of closed Multi-Level
   Secure (MLS) IP networks.

   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.  Some banks use MLS
   technology to restrict sensitive information, for example information
   about mergers and acquisitions.  This IPv6 option, like its IPv4
   predecessors, is only intended for deployment within private
   internetworks, disconnected from the global Internet.  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 Option defined by RFC 1038 was
   designed with one specific purpose in mind: to support the fielding
   of an IPv4 packet-encryption device called a BLACKER [RFC1038].
   Because of this, the definitions and assumptions in those documents
   were necessarily focused on the US Department of Defense and the
   BLACKER device.  Today, IP 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 either 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.

Top      ToC       Page 5 
   In the last decade or so, typical Ethernet link speeds have changed
   from 10 Mbps half-duplex to 1 Gbps full-duplex.  The 10 Gbps full-
   duplex Ethernet standard is widely available today in routers,
   Ethernet switches, and even in some servers.  The IEEE is actively
   developing standards for both 40 Gbps Ethernet and 100 Gbps Ethernet
   as of this writing.  Forwarding at those speeds typically requires
   support from Application-Specific Integrated Circuits (ASICs);
   supporting more complex packet formats usually requires significantly
   more gates than supporting simpler packet formats.  So the pressure
   to have a single simple option format has only increased in the past
   decade, and is only going to increase in the future.

   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 [RFC1825]
   [RFC4301] [RFC4302] [RFC4303].  For MLS IPv6 deployments where the
   use of AH or ESP is practical, the use of AH and/or ESP is
   recommended.

   However, some applications (e.g., distributed file systems), most
   often those not designed for use with Compartmented Mode Workstations
   or other Multi-Level Secure (MLS) computers, multiplex different
   transactions at different Sensitivity Levels and/or with different
   privileges over a single IP communications session (e.g., with the
   User Datagram Protocol).  In order to maintain data Sensitivity
   Labeling for such applications, 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.

   Existing Layer 3 Virtual Private Network (VPN) technology can't solve
   the set of issues addressed by this specification, for several
   independent reasons.  First, in a typical deployment, many labeled
   packets will flow from an MLS End System through some set of networks
   to a receiving MLS End System.  The received per-packet label is used
   by the receiving MLS End System to determine which Sensitivity Label
   to associate with the user data carried in the packet.  Existing
   Layer 3 VPN specifications do not specify any mechanism to carry a
   Sensitivity Label.  Second, existing Layer 3 VPN technologies are not
   implemented in any MLS End Systems, nor in typical single-level End
   System operating systems, but instead typically are only implemented
   in routers.  Adding a Layer 3 VPN implementation to the networking
   stack of an MLS End System would be a great deal more work than
   adding this IPv6 option to that same MLS End System.  Third, existing
   Layer 3 VPN specifications do not support the use of Sensitivity
   Labels to select a VPN to use in carrying a packet, which function is

Top      ToC       Page 6 
   essential if one wanted to obviate this IPv6 option.  Substantial new
   standards development, along with significant new implementation work
   in End Systems, would be required before a Layer 3 VPN approach to
   these issues could be used.  Developing such specifications, and then
   implementing them in MLS systems, would need substantially greater
   effort than simply implementing this IPv6 label option in an MLS End
   System (or in a label-aware router).  Further, both the MLS user
   community and the MLS implementer community prefer the approach
   defined in this specification.

1.2.  Intent and Applicability

   Nothing in this document applies to any system that does not claim to
   implement this document.

   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), the 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 some formal Releasability policies, but
   existing Multi-Level Secure operating systems do not contain
   operating system support for Releasabilities as a separate concept
   from compartments.  The semantics for this sort of Releasability
   encoding is close to the formal policies and has been deployed by a
   number of different organizations for at least a decade now.

   In particular, the authors believe that this mechanism is suitable
   for deployment in United Nations (UN) peace-keeping operations, in
   North Atlantic Treaty Organisation (NATO) or other coalition
   operations, in all current US Government MLS environments, and for
   deployment in other similar commercial or governmental environments.
   This option would not normally ever be visible in an IP packet on the
   global public Internet.

   Because of the unusually severe adverse consequences (e.g., loss of
   life, loss of very large sums of money) likely if a packet labeled
   with this IPv6 Option were to escape onto the global public Internet,
   organizations deploying this mechanism have unusually strong
   incentives to configure security controls to prevent labeled packets
   from ever appearing on the global public Internet.  Indeed, a primary
   purpose of this mechanism is to enable deployment of Mandatory Access
   Controls for IPv6 packets.

Top      ToC       Page 7 
   However, to ensure interoperability of both End Systems and
   Intermediate Systems within such a labeled deployment of IPv6, it is
   essential to have an open specification for this option.

   This option is NOT designed to be an all-purpose label option and
   specifically does not include support for generic Domain Type
   Enforcement (DTE) mechanisms.  If such a DTE label option is desired,
   it ought to be separately specified and have its own (i.e.,
   different) IPv6 option number.

   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 [RFC2119].

1.3.  Deployment Examples

   Two deployment scenarios for IP packet Sensitivity Labels are most
   common.  We should first note that in typical deployments, all people
   having access to an unencrypted link are cleared for all unencrypted
   information traversing that link.  Also, MLS system administrators
   normally have previously been cleared to see all of the information
   processed or stored by that MLS system.  This specification does not
   seek to eliminate all potential covert channels relating to this IPv6
   option.

   In the first scenario, all the connected nodes in a given private
   internetwork are trusted systems that have Multi-Level Secure (MLS)
   operating systems, such as Compartmented Mode Workstations (CMWs),
   that support per-packet Sensitivity Labels [TCSEC] [TNI] [CMW]
   [MLOSPP].  In this type of deployment, all IP packets carried within
   the private internetwork are labeled, the IP routers apply mandatory
   access controls (MAC) based on the packet labels and the sensitivity
   ranges configured into the routers, all End Systems include packet
   Sensitivity Labels in each originated packet, and all End Systems
   apply Mandatory Access Controls to each received packet.  Packets
   received by a router or End System that have a Sensitivity Label
   outside the permitted range for the receiving interface (or, in the
   case of a router, outside the permitted range for either the incoming
   or the outgoing interface) are dropped because they violate the MAC
   policy.

   The second scenario is a variation of the first, where End Systems
   with non-MLS operating systems are present on certain subnetworks of
   the private internetwork.  By definition, these non-MLS End Systems
   operate in "system high" mode.  In "system high" mode, all
   information on the system is considered to have the sensitivity of
   the most sensitive data on the system.  If a system happens to
   contain data only at one Sensitivity Level, this would also be an

Top      ToC       Page 8 
   example of "system high" operation.  In this scenario, each
   subnetwork that contains any single-level End Systems has one single
   "default" Sensitivity Label that applies to all single-level systems
   on that IP subnetwork.  Because those non-MLS End Systems are unable
   to create packets containing Sensitivity Labels and are also unable
   to apply MAC enforcement on received packets, security gateways
   (which might, for example, be label-aware IP routers) connected to
   such subnetworks need to insert sensitivity labels to packets
   originated by the "system high" End Systems that are to be forwarded
   off subnet.  While the CALIPSO IPv6 option is marked as "ignore if
   unrecognized", there are some deployed IPv6 End Systems with bugs.
   Users can't fix these operating system bugs; some users need to be
   able to integrate their existing IPv6 single-level End Systems to
   have a useful overall MLS deployment.  So, for packets destined for
   IP subnetworks containing single-level End Systems, those last-hop
   security gateways also apply Mandatory Access Controls (MAC) and then
   either drop (if the packet is not permitted on that destination
   subnet) exclusive-or remove Sensitivity Labels and forward packets
   onto those "system high" subnetworks (if the packet is permitted on
   that destination subnetwork).

   The authors are not aware of any existing MLS network deployments
   that use a commercial Network Address Translation (NAT), Network
   Address and Port Translation (NAPT), or any other commercial
   "middlebox" device.  For example, NAT boxes aren't used, unlike
   practices in some segments of the public Internet.

   Similarly, the authors are not aware of any existing MLS network
   deployments that use a commercial firewall.  MLS networks normally
   are both physically and electronically isolated from the global
   Internet, so operators of MLS networks are not concerned about
   external penetration (e.g., by worms, viruses, or the like).
   Similarly, all users of the MLS network have been cleared using some
   process specific to that organization, and hence are believe to be
   trustworthy.  In a typical deployment, all computers connected to the
   MLS network are in a physically secure room or building (e.g.,
   protected by guards with guns).  Electronic equipment that enters
   such a space typically does not leave.  Items such as USB memory
   sticks are generally not permitted; in fact, often the USB ports on
   MLS computers have been removed or otherwise made inoperable to
   prevent people from adding or removing information.

   Also, for security reasons, content transformation in the middle of
   an MLS network is widely considered undesirable, and so is not
   typically undertaken.  Hypothetically, if such content transformation
   were undertaken, it would be performed by a certified MLS system that
   has been suitably accredited for that particular purpose in that
   particular deployment.

Top      ToC       Page 9 
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 user
   communities, several terms have defined synonyms.

   The verb "dominate" is used in this document to describe comparison
   of two Sensitivity Labels within a given Domain of Interpretation.
   Sensitivity Label A dominates Sensitivity Label B if the Sensitivity
   Level of A is greater than or equal to the Sensitivity Level of B AND
   the Compartment Set of A is a superset (proper or improper) of the
   Compartment Set of B.  This term has been used in Multi-Level Secure
   circles with this meaning for at least two decades.

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; one
   also must know that the document or data belongs to some specific
   organization (e.g., US Department of Defense (DoD), US Department of
   Energy (DoE), UK Ministry of Defence (MoD), North Atlantic Treaty
   Organisation (NATO), United Nations (UN), a specific commercial firm)
   before one can decide on who is allowed to receive the data.

   A 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, one would list all the acceptable labels such
   as "SECRET" and "TOP SECRET", and one would link the CALIPSO DOI to
   the [DoD5200.28] and [DoD5200.1-R] documents, which define how to
   mark and protect data with the US Department of Defense (DoD)
   [DoD5200.28] [DoD5200.1-R].

Top      ToC       Page 10 
   The scope of the DOI is dependent on the organization creating it.
   In some cases, the creator of the DOI might not be identical to a
   given user of the DOI.  For example, a multi-national organization
   (e.g., NATO) might create a DOI, while a given member nation or
   organization (e.g., UK MoD) might be using that multi-national DOI
   (possibly along with other DOIs created by others) within its private
   networks.  To provide a different example, the United States might
   establish a DOI with specific meanings, which correspond to the
   normal way it labels classified documents and which would apply
   primarily to the US DoD, but those specific meanings might also apply
   to other associated agencies.  A company or other organization also
   might establish a DOI, which applies only to itself.

   NOTE WELL: A CALIPSO Domain of Interpretation is different from, and
   is disjoint from, an Internet Security Association and Key Management
   Protocol (ISAKMP) / Internet Key Exchange (IKE) Domain of
   Interpretation.  It is important not to confuse the two different
   concepts, even though the terms might superficially appear to be
   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

Top      ToC       Page 11 
   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".
   Some user communities have used the term "category", while other user
   communities have used the term "compartment", but the terms have
   identical meaning.

2.4.  Releasability

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

   Historically, most MLS deployments handled Releasability as if it
   were an inverted Compartment.  Strictly speaking, this provides
   slightly different semantics and behavior than a paper marked with
   the same Releasabilities would obtain, because the formal semantics
   of Compartments are different from the formal semantics of
   Releasability.  The differences in behavior are discussed in more
   detail later in this sub-section.

   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 tolerable and those deployments
   are generally considered successful by their respective user
   communities.  This description is consistent with these MLS
   deployments, so has significant operational experience behind it.

2.4.1.  Releasability Conceptual Example

   For example, two companies (ABC and XYZ) are engaging in a technical
   alliance.  ABC labels all information present within its enterprise
   that is to be shared as part of the alliance as REL XYZ (e.g.,
   COMPANY CONFIDENTIAL REL XYZ).

   However, unlike the compartment example above, COMPANY CONFIDENTIAL
   dominates COMPANY CONFIDENTIAL REL XYZ.  This means that XYZ
   employees granted a COMPANY CONFIDENTIAL REL XYZ clearance can only
   access releasable material, while ABC employees with a COMPANY
   CONFIDENTIAL clearance can access all information.

Top      ToC       Page 12 
   If REL XYZ were managed as a compartment, then users granted a
   COMPANY CONFIDENTIAL REL XYZ clearance would have access to all of
   ABC's COMPANY CONFIDENTIAL material, which is undesirable.

   Releasabilities can be combined (e.g., COMPANY CONFIDENTIAL REL
   XYZ/ABLE).  In this case, users possessing a clearance of either
   COMPANY CONFIDENTIAL, COMPANY CONFIDENTIAL REL XYZ, COMPANY
   CONFIDENTIAL REL ABLE, or COMPANY CONFIDENTIAL REL XYZ/ABLE can
   access this information.

2.4.2.  Releasability Encoding

   Individual bits in this option's Compartment Bitmap field MAY be used
   to encode "releasability" information.  The process for making this
   work properly is described below.

   This scheme is carefully designed so that intermediate systems need
   not know whether a given bit in the Compartment Bitmap field
   represents a compartment or a Releasability.  All that an
   Intermediate System needs to do is apply the usual comparison
   (described in Section 2.5.1 and 2.5.2) to determine whether or not a
   packet's label is in-range for an interface.  This simplifies both
   the configuration and implementation of a label-aware Intermediate
   System.

   Unlike bits that represent compartments, bits that represent a
   Releasability are "active low".

   If a given Releasability bit in the Compartment Bitmap field is "0",
   the information may be released to that community.  If the
   compartment bit is "1", the information may not be released to that
   community.

   Only administrative interfaces used to present or construct binary
   labels in human-readable form need to understand the distinction
   between Releasability bits and non-Releasability bits.  Implementers
   are encouraged to describe Releasability encoding in the
   documentation supplied to users of systems that implement this
   specification.

2.4.2.  Releasability Encoding Examples

   For objects, such as IP packets, let bits 0-3 of the Compartment
   Bitmap field be dedicated to controlling Releasability to the
   communities A, B, C, and D, respectively.

Top      ToC       Page 13 
   Example 1:  Not releasable to any community:
               This is usually how handling restrictions
               such as "No Foreigners (NO FORN)" are encoded.
                   ABCD == 1111

   Example 2:  Releasable only to community A and community C:
                   ABCD == 0101

   Example 3:  Releasable only to community B:
                   ABCD == 1011

   Example 4:  Releasable to communities A,B,C, & D:
                   ABCD == 0000

   For subjects, such as clearances of users, the same bit encodings are
   used for Releasabilities as are used for objects (see above).

   Example 1: Clearance not belonging to any community:
              This user can see information belonging
              to any Releasability community, since s/he
              is not in any Releasability community.
                   ABCD = 1111

   Example 2: Clearance belonging to community A and C:
              This user can only see Releasable AC information,
              and cannot see Releasable A information.
                   ABCD == 0101

   Example 3: Clearance belonging to community B:
              This user can only see Releasable B information.
                   ABCD == 1011

   Example 4: Clearance belongs to communities A,B,C, and D:
              This user can only see Releasable ABCD information,
              and cannot (for example) see Releasable AB or
              Releasable BD information.
                   ABCD == 0000

   Now we consider example comparisons for an IP router that is
   enforcing MAC by using CALIPSO labels on some interface:

   Let the MINIMUM label for that router interface be:
            CONFIDENTIAL RELEASABLE AC

   Therefore, this interface has a minimum Releasability of 0101.

   Let the MAXIMUM label for that router interface be:
            TOP SECRET NOT RELEASABLE

Top      ToC       Page 14 
   Therefore, this interface has a maximum Releasability of 1111.

   For the range comparisons, the bit values for the current packet need
   to be "greater than or equal to" the minimum value for the interface
   AND also the bit values for the current packet need to be "less than
   or equal to" the maximum value for the interface, just as with
   compartment comparisons.  The inverted encoding scheme outlined above
   ensures that the proper results occur.

   Consider a packet with label CONFIDENTIAL RELEASABLE AC:
       1) Sensitivity Level comparison:
          (CONFIDENTIAL <= CONFIDENTIAL <= TOP SECRET)
          so the Sensitivity Level is "within range" for that
          router interface.
       2) Compartment bitmap comparison:
          The test is [(0101 >= 0101) AND (0101 <= 1111)],
          so the Compartment bitmap is "within range" for
          that router interface.

   Consider a packet with label CONFIDENTIAL RELEASABLE ABCD:
       1) Sensitivity Label comparison:
          (CONFIDENTIAL <= CONFIDENTIAL <= TOP SECRET)
          so the Sensitivity Level is "within range" for that
          router interface.
       2) Compartment bitmap comparison:
          The test is [(0000 >= 0101) AND (0000 <= 1111)],
          so the Compartment Bitmap is NOT "within range" for
          that router interface.

   Consider a packet with label SECRET NOT RELEASABLE:
       1) Sensitivity Label comparison:
          (CONFIDENTIAL <= SECRET <= TOP SECRET)
          so the Sensitivity Level is "within range" for that
          router interface.
       2) Compartment bitmap comparison:
          The test is [(1111 >= 0101) AND (1111 <= 1111)],
          so the Compartment bitmap is "within range" for that
          router interface.

2.4.3.  Limitations of This Releasability Approach

   For example, if one considers a person "Jane Doe" who is a member of
   two Releasability communities (A and also B), she is permitted to see
   a paper document that is marked "Releasable A", "Releasable B", or
   "Releasable AB" -- provided that her Clearance and Compartments are
   in-range for the Sensitivity Level and Compartments (respectively) of
   the paper document.

Top      ToC       Page 15 
   Now, let us consider an equivalent electronic example implemented and
   deployed as outlined above.  In this, we consider two Releasability
   communities (A and B).  Those bits will be set to 00 for the
   electronic user ID used by user "Jane Doe".

   However, the electronic Releasability approach above will ONLY permit
   her to see information marked as "Releasable AB".  The above
   electronic approach will deny her the ability to read documents
   marked "Releasable A" or "Releasable B".  This is because "Releasable
   A" is encoded as "01", "Releasable B" is encoded as "10", while
   "Releasable AB" is encoded as "00".  If one looks at the compartment
   dominance computation, "00" dominates "00", but "00" does NOT
   dominate "01", and "00" also does NOT dominate "10".

   Users report that the current situation is tolerable, but not ideal.
   Users also report that various operational complexities can arise
   from this approach.

   Several deployments work around this limitation by assigning an
   electronic user several parallel clearances.  Referring to the
   (fictitious) example above, the user "Jane Doe" might have one
   clearance without any Releasability, another separate clearance with
   Releasability A, and a third separate clearance with Releasability B.
   While this has implications (e.g., a need to be able to associate
   multiple separate parallel clearances with a single user ID) for
   implementers of MLS systems, this specification cannot (and does not)
   levy any requirements that an implementation be able to associate
   multiple clearances with each given user ID because that level of
   detail is beyond the scope of an IP labeling option.

   Separating the Releasability bits into a separate bitmap within the
   CALIPSO option was seriously considered.  However, existing MLS
   implementations lack operating system support for Releasability.  So
   even if CALIPSO had a separate bitmap field, those bits would have
   been mapped to Compartment bits by the sending/receiving nodes, so
   the operational results would not have been different than those
   described here.

   Several MLS network deployments connect MLS End Systems both to a
   labeled national network and also to a labeled coalition network
   simultaneously.  Depending on whether the data is labeled according
   to national rules or according to coalition rules, the set of
   Releasability marks will vary.  Some choices are likely to lead to
   more (or fewer) incorrect Releasability decisions (although the
   results of the above Releasability encodings are believed to be
   fail-safe).

Top      ToC       Page 16 
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 an 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.

   End Systems using operating systems with MLS capabilities that also
   implement IPv6 normally will be able to include CALIPSO labels in
   packets they originate and will be able to enforce MAC policy on the
   CALIPSO labels in any packets they receive.

   End Systems using an operating system that lacks Multi-Level Secure
   capabilities operate in "system high" mode.  This means that all data
   on the system is considered to have the Sensitivity Label of the most
   sensitive data on the system.  Such a system normally is neither
   capable of including CALIPSO labels in packets that it originates nor
   of enforcing CALIPSO labels in packets that it receives.

   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,
   Sensitivity Labels exist primarily so they can be compared as part of
   a Mandatory 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 dominates B (e.g., A=SECRET, B=UNCLASSIFIED);
        A can read B,

     2) B dominates A (e.g., A=UNCLASSIFIED, B=SECRET);
        A cannot access B,

Top      ToC       Page 17 
     3) A equals B (e.g., A=SECRET, B=SECRET);
        A can read/write B,

     exclusive-or

     4) A is incomparable to B (e.g., A=SECRET R&D, B=SECRET FINANCE);
        A cannot access B, and also, B cannot access A.

   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 translated into some common
   DOI, such that the labels are then interpretable.

2.5.2.  Sensitivity Label 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 maximum Sensitivity
   Label dominates the minimum Sensitivity 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>.

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:

Top      ToC       Page 18 
           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 cognizant of that DOI.

2.8.  End System

   An End System is a host or router from which a datagram originates or
   to which a datagram is ultimately delivered.

   The IPv6 community has defined the term Node to include both
   Intermediate Systems and End Systems [RFC2460].

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 Intermediate System might also be called a
   "gateway", "guard", or "router" in some user communities.

   So an IPv6 router is one example of an Intermediate System.  A
   firewall or security guard device that applies security policies and
   forwards IPv6 packets that comply with those security policies is
   another example of an Intermediate System.

   An Intermediate System may handle ("forward") a datagram destined for
   some other node without necessarily importing or exporting the
   datagram to/from itself.

   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 being considered and
   the address(es) associated with that system.

Top      ToC       Page 19 
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.  Typically,
   the SSP is a document created by the Information Systems Security
   Officer (ISSO) of the site or organization covered by that SSP.



(page 19 continued on part 2)

Next RFC Part