Network Working Group M. StJohns, Nominum
Internet-Draft R. Atkinson, Extreme Networks
G. Thomas, US Dept of Defense
draft-stjohns-sipso-00.txt 15 February 2007
Son of IPSO (SIPSO)
A Simple IPv6 Sensitivity Labeling Option
Status of this Memo
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.
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.
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; supporting more complex
packet formats usually require significantly more gates than simpler packet
formats. So the pressure to have a 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] 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 marking the sensitivity information
for each IPv6 packet.
1.2. Intent
This document describes a generic way of marking IPv6 datagrams
to reflect their particular sensitivity. Provision is made for separating
data based on domain of interpretation, relative sensitivity
(i.e. security levels), need-to-know or formal access programs
(i.e. compartments or categories), and releasabilities.
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.
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 marking, 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 marking
(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 marking of "SECRET" by itself is
not meaningful; you also have to know the document or data belongs to the
US Department of Defense before you can decide on who is allowed to receive
the data.
An SIPSO DOI is an opaque identifier that is used as a pointer to a
particular set of policies which define the security levels and categories
present within the DOI, and by inference, to the "real world" equivalent
markings (See "Sensitivity Label" below). Registering or defining a set
of real world security policies as an SIPSO DOI results in a standard way
of marking 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 markings such as "Secret" and "Top Secret",
and one would link the SIPSO 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 establishing
it. For example, the US might establish a DOI with specific meanings
which correspond to the normal way its marks 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 SIPSO Domain of Interpretation is different from,
and disjoint from, an ISAKMP/IKE Domain of Interpretation. It is
important not to confuse the two terms.
2.2. Sensitivity Level
A security level represents a mandatory separation of data based
on relative sensitivity. Security 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 security level include "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 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), 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).
The term "category" has the same meaning as "compartment".
2.4 Releasability
A releasability represents a mandatory segregation of data based
on a formal decision to release information to others. Historically,
some MLS deployments handled releasability as if it were a compartment,
but this is problematic, because the semantics of a compartment are
different from the semantics of a releasability.
For example, two companies (ACME and ACE) are engaging in a
technical alliance. ACME marks 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 category 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.
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 only if no releasabilities apply. A DOI
used within a end system may be implicit or explicit depending on its use.
SIPSO Sensitivity Labels always have an explicit DOI. A SIPSO sensitivity
label consists of a sensitivity label of a particular format (defined
below) and ALWAYS contains an explicit DOI.
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.
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=UNCLASSIFIED); A can read/write B
4) A is incomparable 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 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 variously
a minimum and 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 marking is less than or equal
to the maximum marking (e.g. Not incomparable). A range where <minimum>
equals <maximum> may be expressed simply as <minimum>; in this case,
the only acceptable marking is <minimum>.
2.6. Import
The act of receiving a datagram and translating the SIPSO markings
into the appropriate internal (end-system specific) marking.
2.7. Export
The act of selecting an appropriate DOI for an outbound datagram,
translating the internal (end-system specific) marking into an SIPSO
marking 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:
Destination Port
Protocol
End-system
Subnetwork
Network
Sending Interface
Upper Level Protocol Information
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 the interpretation used by all other
devices which will receive this packet.
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
often uses the term Node for what is here called an End System.
2.9. Intermediate System
An Intermediate System is a host or router which receives and
transmits a particular datagram without being either the source or
destination of that datagram. A firewall or security guard device that
applies security policies and forwards packets that comply with the
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.
(N.B. 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 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
marked with a given security policy. The SSP acts as a bridge
between how the organization's mandatory access control policy is
stated and managed and how the network implements that policy.
3. ARCHITECTURE
This document describes a convention for marking an IPv6 datagram
within a particular system security policy. The markings are designed
for use within a Mandatory Access Control (MAC) system. A real world
example is the security classification system in use within the US
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) to those working directly
on those projects and to deny access to other groups within the
company (e.g. equity trading). A SIPSO Sensitivity Label is the
network instantiation of a particular information security policy,
and its related markings, classifications, compartments, and
releasabilities.
Some years ago, the mandatory access control policy for
US classified information was specified formally in mathematical notation.
As it happens, many other organisations have the same basic mandatory
access control policy for information with differing ("vertical")
sensitivity levels. This document builds upon the formal definitions
of Bell-LaPadula.[BL73] There are two basic principles "no write down"
and "no read up". The first rule means that an entity having minimum
sensitivity level X must not be able to write information that is marked
with a sensitivity level below X. The second rule means that an entity
having maximum sensitivity level X must not be able to read information
having a sensitivity level above X. In a normal deployment, information
downgrading ("write down") must not occur automatically and may only occur
if a person with appropriate privilege manually verifies the information
is permitted to be downgraded before the s/he manually re-labels
("downgrades") the information. Subsequent to the original work
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 markings 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 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 a end-system capable of providing
labeled packets across some range of sensitivity labels. A Compartmented
Mode Workstation 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 internet 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 the internet
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 an internet, each distinct sensitivity label
represents a separate virtual internet which shares the same physical
internet. There are rules for moving information between the various
virtual internets. The model we use within this document is based
on the Bell-LaPadula model, but is extended to cover the concept
of differing Domains of Interpretation. Those internet entities
implementing this protocol must enforce this separation of data.
The SIPSO 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 may allow some
limited downgrading, but this normally requires the intervention of some
human entity and is usually done within a end-system with respect to the
internal marking, 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 their implementation's default
configuration. If an implementation supports automatic downgrading or
upgrading of information, there MUST be a well-documented configuration
knob to enable/disable that feature and that knob should only be accessible
to users having appropriate privilege.
This specification does not preclude a node that implements this
specification from supporting multiple DOIs concurrently. Indeed, use of
multiple DOIs might be operationally useful in deployments having very
large numbers of compartments. For example, such a deployment might have
one set of related compartments in one DOI and a different set of
compartments in a different DOI. While this might make some
implementations more complex, it might also reduce the typical size
of the IPv6 SIPSO 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 SIPSO
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, compartment set,
and releasability set (collectively termed a sensitivity label). This
sensitivity label is derived from the internal marking (the end-system
specific implementation of a sensitivity label), and the export DOI.
The export DOI is selected based on any of: the destination end-system,
the destination network, the current DOI for an upper level protocol
(e.g. TCP), or the system default. See the rules under "USAGE - Export"
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 marking based on the sensitivity label contained in the datagram.
This assumes the datagram is marked with a recognizable DOI, there is
a corresponding internal marking equivalent to the SIPSO 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 may have one or more logical interfaces.
A given logical interface is associated with one and only one physical
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
defined for the corresponding physical interface.
In transit, a datagram is handled based on its SIPSO sensitivity
label and is usually neither imported to or exported from the various
intermediate systems it transits. There also is the concept of "SIPSO
Gateways" which import data from one DOI and export it to another DOI
such that the effective sensitivity label is not changed, it is merely
represented using a different DOI. In other words, such devices might
provide on-the-fly remarking of packets at the boundaries between
complete systems of hosts within a single DOI.
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 for the
originating node, and at a minimum only route the packet to an interface
and node where the sensitivity label of the packet falls within the
assigned range of that node. Packets arriving at an node with an invalid
sensitivity label should be discarded. A sensitivity label is valid
if and only if the sensitivity label falls within the range assigned
to the originating node.
If a packet is received from an node which is not aware of SIPSO
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 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 SIPSO option for use
with IPv6 datagrams. SIPSO 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 SIPSO label carried by the packet. An IPv6
datagram must not ever contain more than one SIPSO 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 labels
option used a syntax that was unduly complex.
5.1. Option Format
------------------------------------------------------------
| Option Type | Option Length | Cmpt Length | Rel Length |
+-------------+---------------+-------------+--------------+
| SIPSO Domain of Interpretation |
+-------------+---------------+-------------+--------------+
| Sens Level | RESERVED | CRC-16 Checksum |
------------------------------------------------------------
| Compartment Bitmap (Optional; variable length) |
+-------------+---------------+-------------+--------------+
| Releasability 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 SIPSO 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. The Option Data MUST not change
en-route. If the option is not recognised by an intermediate system
examining the packet, the option should be ignored. If the option
is not recognised by an End System receiving the packet,
then the packet should be dropped.
5.1.2. OPTION LENGTH field
This field contains an unsigned integer 1 octet in size. It has
minimum value is 6. 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.
5.1.4 RELEASABILITY LENGTH field
This field contains an unsigned 8-bit integer. The field specifies
the size of the RELEASABILITY BITMAP field in 64-bit words. The minimum
value is zero, which is used only when the information in this packet has
no associated releasabilities.
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 SIPSO 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 SIPSO 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-16 Checksum
This field contains an unsigned 16-bit integer containing the
CRC-16 checksum calculated over the entire SIPSO option in this packet.
The checksum algorithm is the 16 bit CRC defined by ITU.
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
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.
5.1.10. Releasability Bitmap
This contains a variable number of 64-bit words. Each bit
represents one releasability within the DOI. Each "1" bit within
an octet in the Releasability Bitmap" field indicates that the release
of this packet's data is permitted to the Release Category corresponding
to that particular bit. Hence, each "0" bit indicates that the release
of this packet's data is NOT permitted to the Release Category
corresponding with that bit. The semantics of the Releasability
Bitmap are always interpreted in the context of the DOI specified
in the same SIPSO option. The specification leaves the assignment
of identity to individual bits within a Releasability Bitmap
for a given DOI to the owner of that DOI.
By way of example, each bit in the Releasability Bitmap might
correspond with a distinct foreign country ("foreign" being relative
to the owner of the DOI in use). In such a case, then if all bits
in the Releasability Bitmap were set to 0, the packet's data
would not be releasable to any other country than the one indicated
by the Domain of Interpretation.
5.2. Packet Word Alignment considerations
The basic option is variable length, due to three variable length
fields (Compartment Bitmap and Releasability Bitmap).
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 fields 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 label,
zero or more compartments, and zero or more releasabilities. The
following notation will be used:
A.DOI = the DOI portion of sensitivity label A
A.LEV = the sensitivity portion of sensitivity label A
A.COMP = the compartments portion of sensitivity label A
A.REL = the releasabilities portion of sensitivity label A
A:IGNOR = A, less the compartment bits represented in IGNOR
6.1.1. "Within Range"
A sensitivity label, "M" is "within range" for a particular range
"A:B:IGNOR" if and only if:
1. The range is a valid range. A given range A:B:IGNOR is
valid if and only if B:IGNOR is greater than A:IGNOR.
This implies that A and B are members of the same DOI.
2. The DOI for the sensitivity label matches the DOI for both
the low and high end of the range and, (M.DOI = A.DOI = B.DOI)
3. The sensitivity label has a Security Level which is greater
than or equal to the Security Level contained in the low-end
sensitivity label from the range and which is less than or equal
to the Security Level contained in the high-end sensitivity
label from the range and, (A.LEV <= M.LEV <= B.LEV)
4. The sensitivity label 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 and which is a subset
(proper or otherwise) of the compartment set contained in the
high end sensitivity label from the range.
5. The sensitivity label M has a Releasability set which is a subset
(proper or otherwise) of the releasability set contained in the
low end sensitivity label from the range and which is a superset
(proper or otherwise) of the releasability set contained in the
high end marking from the range.
((A.COMP & ^IGNOR) <= (M.COMP & ^IGNOR) <= (B.COMP & ^IGNOR))
&&
(A.REL >= M.REL >= B.REL)
6.1.2. "Less Than" or "Below Range"
A sensitivity label "M" is "less than" a sensitivity label "A"
while considering a set of ignorable compartments IGNOR, if and only if:
1. Their DOI's are identical (M.DOI = A.DOI), and
2. M's Security Level is less than A's Security Level
M.LEV < A.LEV
3. M.COMP is a subset (proper or otherwise) of A.COMP,
excluding compartments specified in IGNOR.
4. M.REL is a superset (proper or otherwise) of A.REL.
Thus, a marking M is less than or equal to a marking A iff:
(( (M.LEV <= A.LEV)
&& ((M.COMP & ^IGNOR) < (A.COMP & ^IGNOR)))
&& (M.REL >= A.REL))
A sensitivity label, "M", is "below range" for a sensitivity label,
"A:B:IGNOR", if M is less than A.
6.1.3. "Greater Than" or "Above Range"
A sensitivity label, "M" is "greater than" a sensitivity label "B"
while considering a set of ignorable compartments IGNOR if and only if:
1. Their DOI's are identical (M.DOI = B.DOI), AND
2. M's 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 > B.LEV & (M.COMP & ^IGNOR) >= (A.COMP & ^IGNOR)),
OR
3. 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
4. M.REL is a subset (proper or otherwise) of A.REL
( (M.LEV >= B.LEV) &&
((M.COMP & ^IGNOR) > (B.COMP & ^IGNOR)) ) &&
(M.REL <= A.REL) )
A sensitivity label, "M", is "above range" for a sensitivity label,
"A:B:IGNOR", if M is greater than B.
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:
1. They have the exact same DOI, and
2. they have identical security levels, and
3. their compartment sets are identical, and
4. their Releasability sets are identical.
((A.DOI == B.DOI) && (A.LEV == B.LEV)
&& ((A.COMP & ^IGNOR) == (B.COMP & IGNOR))
&& ((A.REL == B.REL))
)
6.1.5. "Disjoint" or "Incomparable"
A marking "A" is disjoint from another marking "B" while considering a
set of ignorable compartments IGNOR either if:
1. Their DOI's differ (A.DOI <> B.DOI) OR,
2. They are neither less than, nor greater than nor
equal to each other (^((A < B) | (A > B) | (A =
B))) OR,
3. Their compartment sets are disjoint from each
other OR,
4. The releasability 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 SIPSO-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 must occur:
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 that a TCP connection
must have the same DOI and marking for the life
of the connection - the DOI is selected at
connection initiation and may not change.
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.
NB: 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 the end-system -- xor
correct operation for a node that is not permitted to send IPv6 packets
through that intermediate-system.
2. Export Marking:
Once the DOI is selected, the SIPSO marking and
values are determined based on the internal marking and
the DOI. In the event the internal marking does not
map to a valid SIPSO marking, 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
marking of the datagram is compared against the
range(s) associated with that logical interface. For
the datagram to be sent, the interface must list the
DOI of the datagram marking as one of the permissible
DOI's and the datagram marking 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 SIPSO checksum if it occurs within the
option. Datagrams with invalid checksums MUST be
silently dropped. They SHOULD be logged.
2. Verify the SIPSO 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 or unknown DOIs
MUST be silently dropped. Such an event SHOULD
be logged as a security fault.
4. Verify the marking within the SIPSO is within the
permitted range for the receiving interface. N.B.
EACH permitted DOI on an interface has a separate
table describing the permitted range for that DOI:
A datagram which has a marking within the permitted
range is accepted for further processing.
A datagram which has a marking disjoint with the
permitted range MUST be silently discarded. This
event SHOULD be logged as a security fault, with an
indication that the packet was discarded because
of a disjoint marking.
A datagram which has a marking below the permitted
range MUST be dropped. This event SHOULD be logged.
It MAY result in an appropriate ICMP error message sent
at the maximum permitted sensitivity label for the interface
for that DOI, depending on the security configuration.
The choice of whether or not to send an ICMP message
MUST be configurable and SHOULD default to OFF. Standard
non-MLS conditions about generating ICMP error messages
(e.g. no error message about a received error message)
continue to apply.
A datagram with a marking above the permitted range
MUST be discarded. This event SHOULD be logged. It
MAY result in an appropriate ICMP error message sent
at the maximum permitted marking for the interface
for that DOI, depending on security configuration.
The choice of whether or not to send an ICMP message
MUST be configurable, and SHOULD default to OFF.
Standard conditions about generating ICMP error messages
(e.g. "generate no error message about an error message")
continue to apply.
5. Once the datagram has been accepted, the import sensitivity
label and DOI are used to associate the appropriate internal
marking with the data contained in the datagram
This information MUST be carried as part of the information
returned to the upper level protocol.
6.3. Intermediate System Rules
This section describes SIPSO-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 SIPSO packet format has been designed so that one can configure
an intermediate system with the minimum sensitivity level, maximum
sensitivity level, minimum compartment bitmap, maximum compartment
bitmap, minimum releasability, and maximum releasability -- and then
deploy that system without forcing it to know the detailed meaning
of each sensitivity level, compartment bit, or releasability bit.
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.
6.3.1. Input
Intermediate Systems (ISs) have slightly different rules for
processing marked datagrams than do end systems. Primarily, ISs
do not IMPORT or EXPORT transit datagrams, they just route 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 SIPSO-labeled packet, an intermediate system must:
1. Determine whether or not this datagram is destined
for (addressed to) this IS. If so, the IS becomes
an end-system for the purposes of receiving this datagram
and the rules for IMPORTing described above are
followed.
2. Verify the SIPSO checksum. Datagrams with invalid checksums
MUST be silently dropped. The drop event SHOULD be logged
as a network fault.
3. Verify the SIPSO has a known and valid DOI.
Datagrams with unrecognized or illegal DOIs MUST
be silently dropped. They 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 drops SHOULD be logged as a security fault.
5. Verify the marking within the SIPSO is within the
permitted range for the receiving interface.
N.B.: EACH permitted DOI on an interface has a separate
table describing the permitted range for that DOI:
A rejected datagram which has a marking 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.
A rejected datagram with a marking above the permitted
range MUST be dropped. The drop event SHOULD be logged
as a security fault. It MAY result in an appropriate ICMP
error message sent at the maximum permitted marking for
the interface for that DOI, depending on the system's
security configuration.. The choice of whether or not
to send an ICMP message, if implemented, MUST be configurable,
and SHOULD default to OFF.
Standard Internet conditions about generating ICMP error
messages (e.g. never generate an error message about a
received error message) continue to apply.
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 IS,
and appropriate ICMP error messages may be generated by the IP module back
to the originating end-system regarding the forwarding of the datagram.
These ICMP messages MUST be sent with the exact same marking as the
datagram causing the error. Note that these generated messages must go
through the same outbound checks as a forwarded datagram as described in
the following paragraphs.
6.3.2. Translation
It is at this point that TRANSLATION of the SIPSO takes place
if at all. Please see the following section for a discussion
of the appropriate processing.
6.3.3. Output
Once the forwarding code has selected the interface through
which the datagram will be transmitted the following takes place:
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.
Datagrams with prohibited DOIs or with out of range
values MUST be dropped. Drop events SHOULD be logged
as a security fault.
Datagrams with prohibited DOIs or out of range values 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 implemented, MUST be configurable,
and SHOULD default to OFF. Standard conditions about generating
ICMP error messages (e.g. never send an error message about
a received error message) apply.
6.4. Translation
A system which provides on-the-fly re-marking 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 an external
(SIPSO) sensitivity label, to an internal sensitivity label and then back
to a new external sensitivity label, or an external sensitivity label can
be directly remapped into another external 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.
Once the output DOI is selected, the output sensitivity label is
determined based on (1) the input sensitivity label and input DOI and (2)
the output DOI. In the event the input sensitivity label does not map
to a valid output sensitivity label for that DOI, the datagram MUST be
silently dropped and the drop event SHOULD be logged as a security fault.
Once the datagram is remarked, 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
7.3.1. TCP-related issues
With respect to an internet, each distinct sensitivity label
represents a separate virtual internet which shares the same physical
internet.
The above statement taken from section 3 has a non-obvious but
critical corollary. If there are separate virtual internets then it is
possible for a system which exists in multiple virtual internets to have
identical TCP connections, each one existing in a different virtual
internet.
TCP connections are normally identified by source and destination
port, and source and destination address. If a system marks datagrams
(which it must do if it exists in multiple virtual internets - e.g. a
"multi-level secure" system), then TCP connections are identified by source
and destination port, source and destination address and SIPSO Security
Marking.
7.3.2. UDP-related Issues
Datagrams addressed to a UDP port should be delivered to all listeners
whose equivalent sensitivity label is greater than or equal to the security
marking of the UDP datagram.
7.3.3. SCTP-related Issues
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 interface on a node might have a sensitivity label
range of Secret:Top Secret while a different interface might have a
sensitivity label range of Unclassified:Unclassified.
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, the
implementation of this mechanism is very critical to overall security of
the systems and networks where this mechanisms is deployed. Use of
high-assurance development techniques is appropriate for this
specification.
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, and communications security
(COMSEC) issues.
IANA CONSIDERATIONS
IANA is requested to assign an IPv6 Hop-by-Hop option number to the
SIPSO option described in this specification. This option is immutable
during transit.
Also, IANA is requested to create a registry for SIPSO 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 2013 must not be used on the network
0.0.0.1 to 0.255.255.255 For private use among consenting parties
For the SIPSO DOI values registry, IANA is requested to issue a new
DoI value to any organisation that requests it. Assignment information
should be made available on the IANA website. A commercial organisation
will normally only be assigned one or two DoI values. A government or
multi-national treaty organisation may be assigned a range of values
if that is requested. Different departments within a given government
each may independently request a range of values.
ACKNOWLEDGEMENTS
This document is directly derived from an Internet-Draft by the first
author written circa 1992. Packet format changes have been made since
that draft, primarily to comply with IPv6 syntax rules.
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.
[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.
[IPSEC] S. Kent, "Security Architecture for the Internet
Protocol", RFC-xxx, date TBD.
[AH] S. Kent, "IP Authentication header", RFC-yyyy, date TBD.
[ESP] S. Kent, "IP Encapsulating Security Payload", RFC-zzzz,
date TBD.
NORMATIVE REFERENCES
[RFC-2460] S. Deering & R. Hinden, Internet Protocol Version 6
Specification, RFC-2460, December 1998.
AUTHORS:
M. StJohns
Nominum
2385 Bay Road
Redwood City, CA
USA 94063-3011
mstjohns@nominum.com
R. Atkinson
Extreme Networks
3585 Monroe Street
Santa Clara, CA
USA 95051
rja@extremenetworks.com
G. Thomas
US Department of Defense
Washington, DC
USA
COPYRIGHT
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions contained
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.
Datatracker
draft-stjohns-sipso-00
This is an older version of an Internet-Draft that was ultimately published as RFC 5570.
