One document matched: draft-stjohns-sipso-04.txt
Differences from draft-stjohns-sipso-03.txt
Network Working Group M. StJohns
Internet-Draft R. Atkinson, Extreme Networks
draft-stjohns-sipso-04.txt G. Thomas, US Dept of Defense
Expires: 4 JAN 2009 4 July 2008
Common Architecture Label
IPv6 Security Option
(CALIPSO)
Status of this Memo
This is an Internet-Draft.
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum
of six months and may be updated, replaced, or obsoleted
by other documents at any time. It is inappropriate
to use Internet-Drafts as reference material or to cite
them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be
accessed at
http://www.ietf.org/shadow.html.
ABSTRACT
This document describes an optional method for encoding
explicit packet Sensitivity Labels on IPv6 packets. It is
intended for use only within Multi-Level secure (MLS) networking
environments that are both trusted and trustworthy.
StJohns Et Alia [Page 1]
Internet-Draft 04 JUL 08
Table of Contents
1. INTRODUCTION ........................................3
1.1. History .............................................3
1.2. Intent ..............................................4
1.3. Deployment Examples..................................5
2. DEFINITIONS .........................................6
2.1. Domain of Interpretation.............................6
2.2. Sensitivity Level ...................................8
2.3. Compartment .........................................8
2.4. Releasability .......................................9
2.5. Sensitivity Label ..................................14
2.6. Import .............................................15
2.7 Export .............................................16
2.8. End System .........................................16
2.9. Intermediate System ................................16
2.10. System Security Policy .............................17
3. ARCHITECTURE........................................17
4. DEFAULTS............................................22
5. FORMAT..............................................24
5.1 Option Format ......................................25
5.2 Packet Word Alignment...............................28
6. USAGE...............................................29
6.1 Sensitivity Label Comparisons.......................29
6.2 End System Processing ..............................32
6.3 Intermediate System Processing......................35
7. IMPLEMENTATION CONSIDERATIONS.......................39
7.1 Intermediate Systems................................40
7.2 End Systems.........................................40
7.3 Transport-Layer Protocols...........................40
8. SECURITY CONSIDERATIONS.............................43
9. IANA CONSIDERATIONS.................................44
REFERENCES..........................................46
StJohns Et Alia [Page 2]
Internet-Draft 04 JUL 08
1. INTRODUCTION
The original IPv4 specification in RFC-791 includes
an option for labeling the sensitivity of IP packets.
That option was revised by RFC-1038 and later by RFC-1108.
[RFC-791][RFC-1038][RFC-1108] Although the IETF later
deprecated RFC-1108, the option continues to be in active
use within a number of closed 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.
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 option,
like its IPv4 predecessors, is nearly always deployed 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.[RFC-1038] 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
StJohns Et Alia [Page 3]
Internet-Draft 04 JUL 08
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 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 ASICs; supporting more complex
packet formats usually require 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 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. [RFC-1825, IPSEC, AH, ESP]
For MLS IPv6 deployments where the use of AH or ESP is
practical, use of AH and/or ESP is recommended.
However, some 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, in
order to be able to implement routing and Mandatory Access
Control decisions in routers and guards on a per-IP-packet basis,
and for other reasons, there is a need to have a mechanism for
explicitly labeling the sensitivity information for each IPv6
packet.
1.2. Intent
This document describes a generic way of labeling IPv6
datagrams to reflect their particular sensitivity. Provision is
made for separating data based on domain of interpretation
(e.g. an agency, a country, an alliance, or a coalition), the
relative sensitivity (i.e. sensitivity levels), and need-to-know
or formal access programs (i.e. compartments or categories).
StJohns Et Alia [Page 4]
Internet-Draft 04 JUL 08
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 organisations for at least
a decade now.
In particular, the authors believe that this mechanism is
suitable for deployment in UN peace-keeping operations, in 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.
However, to ensure interoperability of hosts 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. [RFC-2119]
1.3 Deployment Examples
Two deployment scenarios for IP packet sensitivity
labels are most common.
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][CMW][DOD MLOS PP] 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 hosts include packet sensitivity labels in
each originated packet, and all hosts apply Mandatory Access
StJohns Et Alia [Page 5]
Internet-Draft 04 JUL 08
Controls to each received packet. Packets received by a router
or host 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 the outgoing interface) are
dropped because they violate the MAC policy.
The second scenario is a variation of the first where hosts
with non-MLS operating systems are present on certain subnetworks
of the private internetwork. By definition, these non-MLS hosts
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 example of "system high" operation. In this second
scenario, each subnetwork that contains any single-level hosts
has one single "default" Sensitivity Label that applies to all
of those single-level systems on that IP subnetwork. Because
those non-MLS hosts are unable to create packets containing
sensitivity labels and are also unable to apply MAC enforcement
on received packets, security gateways (which are often
specialised IP routers) connected to such subnetworks need to
insert sensitivity labels to packets originated by the
system-high hosts that are to be forwarded off subnet. For
packets destined for such IP subnetworks, those last-hop IP
routers also apply MAC and then either drop (if the packet is
not permitted on that destination subnet) xor remove sensitivity
labels and forward packets onto those system-high subnetworks
(if the packet is permitted on that destination subnetwork).
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.
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
StJohns Et Alia [Page 6]
Internet-Draft 04 JUL 08
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 organisation (e.g. US Dept of Defense,
US Dept of Energy, UK Ministry of Defence, NATO, 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 DOD 5200.28
and DOD 5200.1R documents which define how to mark and protect
data with the US Department of Defense (DoD). [DoD 5200.28,
DoD 5200.1-R]
The scope of the DOI is dependent on the organization creating
it. In some cases, the creator of the DOI might not be identical
to a given user of the DOI. For example, a multi-national
organisation (e.g. NATO) might create a DOI, while a given member
nation or organisation (e.g. UK MoD) might be using that
multi-national DOI (posssibly along with other DOIs created by
others) within its private networks. To provide a different
example, the US might establish a DOI with specific meanings
which correspond to the normal way it labels classified documents
and which would apply primarily to the US DOD, but those specific
meanings might also apply to other associated agencies. A
company or other organisation 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 ISAKMP/IKE Domain of
Interpretation. It is important not to confuse the two different
concepts, even though the terms might superficially appear
similar.
StJohns Et Alia [Page 7]
Internet-Draft 04 JUL 08
2.2. Sensitivity Level
A Sensitivity Level represents a mandatory separation of data
based on relative sensitivity. Sensitivity Levels ALWAYS have a
specific ordering within a DOI. Clearance to access a specific
level of data also implies access to all levels whose sensitivity
is less than that level. For example, if the A, B, and C are
levels, and A is more sensitive than B which is in turn more
sensitive than C (A > B > C), access to data at the B level
implies access to C as well. As an example, common UK terms for
a Sensitivity Level include (from low to high) "Unclassified",
"Restricted", "Confidential", "Secret", and "Most Secret".
NOTE WELL: A Sensitivity Level is only one component of a
Sensitivity Label. It is important not to confuse the two terms.
The term "Sensitivity Level" has the same meaning as the term
"Security Level".
2.3. Compartment
A Compartment represents a mandatory segregation of data
based on formal information categories, formal information
compartments, or formal access programs for specific types of
data. For example, a small startup company creates "Finance"
and "R&D" compartments to protect data critical to its success
-- only employees with a specific need to know (e.g. the
accountants and controller for "Finance", specific engineers for
"R&D") are given access to each compartment. Each Compartment is
separate and distinct. Access to one Compartment does not imply
access to any other Compartment. Data may be protected in
multiple compartments (e.g. "Finance" data about a new "R&D"
project) at the same time, in which case access to ALL of those
compartments is required to access the data. Employees only
possessing clearance for a given sensitivity level (i.e. without
having clearance for any specific compartments at that
sensitivity level) do not have access to any data classified in
any compartments (e.g. SECRET FINANCE dominates SECRET).
NOTE WELL: The term "category" has the same meaning as
"compartment". Some user communities have used the term
"category", while other user communities have used the term
"compartment", but the terms have identical meaning.
StJohns Et Alia [Page 8]
Internet-Draft 04 JUL 08
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 behaviour 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 behaviour 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.
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
StJohns Et Alia [Page 9]
Internet-Draft 04 JUL 08
information.
2.4.2 Releasability Encoding
Individual bits in this option's Compartment Bitmap field
MAY be used to encode "releaseability" 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 elsewhere) to determine whether a packet's
label is in-range for an interface or not. 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.
Example 1, Not releasable to any community:
This is usually how handling restrictions
such as "No Foreigners (NO FORN)" are encoded.
ABCD == 1111
StJohns Et Alia [Page 10]
Internet-Draft 04 JUL 08
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, & 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.
StJohns Et Alia [Page 11]
Internet-Draft 04 JUL 08
Let the MAXIMUM label for that router interface be:
TOP SECRET NOT RELEASABLE
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.
StJohns Et Alia [Page 12]
Internet-Draft 04 JUL 08
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.
Now, let us consider an equivalent electronic example
implemented and deployed as outlined above. In this
we consider 2 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, and can lead to various operational complexities.
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 able to associate
multiple clearances with each given user-id because that
level of detail is beyond the scope of an IP labelling 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
StJohns Et Alia [Page 13]
Internet-Draft 04 JUL 08
results would not have been different than those described
here.
Several MLS network deployments connect MLS hosts both to
a labelled national network and also to a labelled coalition
network simultaneously. Depending on whether the data is
labelled 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).
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.
Hosts 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.
Hosts 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".
StJohns Et Alia [Page 14]
Internet-Draft 04 JUL 08
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,
3) A equals B (e.g. A=SECRET, B=SECRET);
A can read/write B,
xor
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 promoted such
that the labels are interpretable within some single DOI.
2.5.2 Range
A range is a pair of Sensitivity Labels which indicate
both a minimum and a maximum acceptable Sensitivity Label for
objects compared against it. A range is usually expressed as
"<minimum> : <maximum>" and always has the property that the
maximum Sensitivity Label dominates the minimum Sensivitity
Label. In turn, this requires that the two Sensitivity Labels
MUST be comparable.
A range where <minimum> equals <maximum> may be expressed
simply as "<minimum>"; in this case, the only acceptable
Sensitivity Label is <minimum>.
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.
StJohns Et Alia [Page 15]
Internet-Draft 04 JUL 08
2.7. Export
The act of selecting an appropriate DOI for an outbound
datagram, translating the internal (End System specific) label
into an CALIPSO Sensitivity Label based on that DOI, and sending
the datagram. The selection of the appropriate DOI may be based
on many factors including, but not necessarily limited to:
Source Port
Destination Port
Transport Protocol
Application Protocol
Application Information
End System
Subnetwork
Network
Sending Interface
System Implicit/Default DOI
Regardless of the DOI selected, the Sensitivity Label of the
outbound datagram must be consistent with the security policy
monitor of the originating system and also with the DOI
definition used by all other devices cognisant of that DOI.
2.8. End System
An End System 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, which includes
both routers and end systems. This document sometimes uses
the term "host" to refer to an end system.
2.9. Intermediate System
An Intermediate System (IS) is a node that receives and
transmits a particular datagram without being either the source
or destination of that datagram. This document sometimes uses
the term "router" or "guard" to refer to an intermediate system.
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.
StJohns Et Alia [Page 16]
Internet-Draft 04 JUL 08
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.
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 Security administrator of the site or organisation
covered by that SSP.
3. ARCHITECTURE
This document describes a convention for labeling an IPv6
datagram within a particular system security policy. The labels
are designed for use within a Mandatory Access Control (MAC)
system. A real world example is the security classification
system in use within the UK Government. Some data held by the
government is "classified", and is therefore restricted by law
to those people who have the appropriate "clearances".
Commercial examples of information labelling schemes also
exist.[CW87] For example, one global electrical equipment company
has a formal security policy that defines 6 different Sensitivity
Levels for its internal data, ranging from "Class 1" to "Class 6"
information. Some financial institutions use multiple
compartments to restrict access to certain information
(e.g. "mergers & acquisitions", "trading") to those working
directly on those projects and to deny access to other groups
within the company (e.g. equity trading). A CALIPSO Sensitivity
Label is the network instantiation of a particular information
security policy, and the policy's related labels,
classifications, compartments, and releasabilities.
Some years ago, the Mandatory Access Control (MAC) policy
for US Government classified information was specified formally
in mathematical notation.[BL73] As it happens, many other
organisations or governments have the same basic Mandatory Access
Control (MAC) policy for information with differing ("vertical")
Sensitivity Levels. This document builds upon the formal
definitions of Bell-LaPadula.[BL73] There are two basic
principles "no write down" and "no read up".
StJohns Et Alia [Page 17]
Internet-Draft 04 JUL 08
The first rule means that an entity having minimum Sensitivity
Level X must not be able to write information that is marked with
a Sensitivity Level below X. The second rule means that an
entity having maximum Sensitivity Level X must not be able to
read information having a Sensitivity Level above X. In a normal
deployment, information downgrading ("write down") must not occur
automatically, and is permitted if and only if a person with
appropriate "downgrade" privilege manually verifies the
information is permitted to be downgraded before s/he manually
re-labels (i.e. "downgrades") the information. Subsequent to the
original work by Bell and LaPadula in this area, this formal
model was extended to also support ("horizontal") Compartments of
information.
This document extends Bell-LaPadula to accommodate the notion
of separate Domains of Interpretation (DOI). [BL73] Each DOI
constitutes a single comparable domain of Sensitivity Labels
as stated by Bell-LaPadula. Sensitivity Labels from different
domains cannot be directly compared using Bell-LaPadula semantics.
This document is focused on providing standards for encoding
Sensitivity Labels in packets, as well as certain standards for
how these labels are to be interpreted and enforced at the IP
layer. This document recognizes that there are several kinds of
application processing that occur above the IP layer that
significantly impact end-to-end system security policy
enforcement, but are out of scope for this document. In
particular, how the network labeling policy is enforced within
processing in an end system is critical, but is beyond the scope
of a network (IP) layer Sensitivity Label encoding standard.
Other specifications exist which discuss such details. [TCSEC]
[CMW] [ISO-15408] [CC] [DoD MLOS PP]
This standard does not preclude an End System capable of
providing labeled packets across some range of Sensitivity
Labels. A Compartmented Mode Workstation (CMW) is an example of
such an End System.[CMW] This is useful if the End System is
capable of, and accredited to, separate processing across some
range of Sensitivity Labels. Such a node would have a range
associated with it within the network interface connecting the
node to the network. As an example, an End System has the range
"SECRET: TOP SECRET" associated with it in the Intermediate
System to which the node is attached. SECRET processing on the
node is allowed to traverse the network to other "SECRET :
SECRET" segments of the network, ultimately to a "SECRET :
SECRET" node. Likewise, TOP SECRET processing on the node is
allowed to traverse a network through "TOP SECRET: TOP SECRET"
segments, ultimately to some "TOP SECRET: TOP SECRET" node. The
StJohns Et Alia [Page 18]
Internet-Draft 04 JUL 08
node in this case can allow a user on this node to access SECRET
and TOP SECRET resources, provided the user holds the appropriate
clearances and has been correctly configured.
With respect to a given network, each distinct Sensitivity
Label represents a separate virtual network which shares the same
physical network. There are rules for moving information between
the various virtual networks. The model we use within this
document is based on the Bell-LaPadula model, but is extended to
cover the concept of differing Domains of Interpretation. Nodes
that implement this protocol MUST enforce this mandatory
separation of data.
CALIPSO provides for both horizontal ("Compartment") and
vertical ("Sensitivity Level") separation of information, as well
as separation based on DOI. The basic rule is that data MUST NOT
be delivered to a user or system that is not approved to receive
it.
NOTE WELL: wherever we say "not approved", we also mean
"not cleared", "not certified", and/or "not accredited"
as applicable in one's operational community.
This specification does not enable AUTOMATIC relabeling of
information, within a DOI or to a different DOI. That is,
neither automatic "upgrading" nor automatic "downgrading" of
information are enabled by this specification. Local security
policies might allow some limited downgrading, but this normally
requires the intervention of some human entity and is usually
done within an End System with respect to the internal
Sensitivity Label, rather than on a network or in an
intermediate-system (e.g. router, guard). Automatic downgrading
is not suggested operational practice; further discussion of
downgrading is outside the scope of this protocol specification.
Implementers of this specification MUST NOT permit automatic
upgrading or downgrading of information in the default
configuration of their implementation. Implementers MAY add a
configuration knob that would permit a System Security Officer
holding appropriate privilege to enable automatic upgrading or
downgrading of information. If an implementation supports such a
knob, the existence of the configuration knob must be clearly
documented and the default knob setting MUST be that automatic
upgrading or downgrading is DISABLED. Automatic information
upgrading and downgrading is not recommended operational
practice.
Many existing MLS deployments already use (and operationally
StJohns Et Alia [Page 19]
Internet-Draft 04 JUL 08
need to use) more than one DOI concurrently. User feedback from
early drafts of this specification indicates that it is common
at present for a single of network link (i.e. IP subnetwork)
to carry traffic for both a particular "coalition" (or
joint-venture) activity and also for the government (or other
organisation) that owns and operates that particular network
link. On such a link, one CALIPSO DOI would typically be used
for the "coalition" traffic and some different CALIPSO DOI would
typically be used for non-coalition traffic (i.e. traffic that is
specific to the government that owns and operates that particular
network link). For example, a UK military network that is part
of a NATO deployment might have and use a UK MoD DOI for
information originating/terminating on another UK system, while
concurrently using a different NATO DOI for information
originating/terminating on a non-UK NATO system.
Additionally, operational experience with existing MLS systems
has shown that if a system only supports a single DOI at a given
time, then it is impossible for a deployment to migrate from
using one DOI value to a different DOI value in a smooth,
lossless, zero downtime, manner.
Therefore, a node that implements this specification MUST be
able to support at least 2 CALIPSO DOIs concurrently. Support
for more than 2 concurrent CALIPSO DOIs is encouraged. This
requirement to support at least 2 CALIPSO DOIs concurrently is
not necessarily an implementation constraint upon MLS operating
system internals that are unrelated to the network.
Indeed, use of multiple DOIs is also operationally useful in
deployments having a single administration that also have very
large numbers of compartments. For example, such a deployment
might have one set of related compartments in one CALIPSO DOI
and a different set of compartments in a different CALIPSO DOI.
Some compartments might be present in both DOIs, possibly at
different bit positions of the compartment bitmap in different
DOIs. While this might make some implementations more complex,
it might also be used to reduce the typical size of the IPv6
CALIPSO option in data packets.
Moving information between any two DOIs is permitted
-- if and only if -- the owners of the DOIs:
1) Agree to the exchange,
AND
2) Publish a document with a table of equivalencies that
StJohns Et Alia [Page 20]
Internet-Draft 04 JUL 08
maps the CALIPSO values of one DOI into the other
and make that document available to security
administrators of MLS systems within the deployment
scope of those two DOIs.
The owners of two DOIs may choose to permit the exchange on
or between any of their systems, or may restrict exchange to a
small subset of the systems they own/accredit. One way
agreements are permissible, as are agreements which are a subset
of the full table of equivalences. Actual administration of
inter-DOI agreements is outside the scope of this document.
When data leaves an end system it is "exported" to the
network, and marked with a particular DOI, Sensitivity Level,
and Compartment Set. (This triple is collectively termed a
Sensitivity Label.) This Sensitivity Label is derived from
the internal Sensitivity Label (the End System specific
implementation of a given Sensitivity Label), and the export DOI.
The export DOI is selected based on a range of parameters
described in detail later in this document.
When data arrives at an end system, it is "imported" from the
network to the End System. The data from the datagram takes on
an internal Sensitivity Label based on the Sensitivity Label
contained in the datagram. This assumes the datagram is marked
with a recognizable DOI, there is a corresponding internal
Sensitivity Label equivalent to the CALIPSO Sensitivity Label,
and the datagram is "within range" for the receiving logical
interface.
A node has one or more physical interfaces. Each physical
interface is associated with a physical network segment used
to connect the node, router, LAN, or WAN. Each physical
network 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 node also might have one or more logical network
interfaces.
A given logical network interface might be associated with more
than one physical interface. For example, a layer-3 switch/router
might have 2 Ethernet ports that are associated with the same VLAN
(i.e. where that one VLAN mapped to a single IPv6 subnetwork).
[IEEE 802.1Q]
A given physical network interface might have more than one
StJohns Et Alia [Page 21]
Internet-Draft 04 JUL 08
associated logical interface. For example, a node might have 2
logical network interfaces, each for a different IP subnetwork
("super-netting"), on a single physical network interface (e.g.
on a single Network Interface Card of a personal computer).
Alternatively, also as an example, a single Ethernet port might
have multiple Virtual LANs (VLANs) associated with it,
where each VLAN could be a separate logical network interface.
Each logical network interface has one or more Sensitivity
Label ranges associated with it. Sensitivity Label ranges from
multiple DOIs must be enumerated separately. Multiple ranges
from the same DOI are permissible. Each range associated with a
logical interface must fall within a range separately defined for
the corresponding physical interface.
There is specific user interest in having IPv6 routers that
can apply per-logical-interface mandatory access controls based
on the contents of the CALIPSO Sensitivity Labels in IPv6
packets. The authors note that since the early 1990s, and
continuing through today, some commercial IPv4 router products
provide MAC enforcement for the RFC-1108 IP Security Option.
In transit, a datagram is handled based on its CALIPSO
Sensitivity Label, and is usually neither imported to or exported
from the various intermediate systems it transits. There also is
the concept of "CALIPSO Gateways" which import data from one DOI
and export it to another DOI such that the effective Sensitivity
Label is NOT changed, but is merely represented using a different
DOI. In other words, such devices would be trustworthy, trusted,
and authorised to provide on-the-fly re-labeling of packets at
the boundaries between complete systems of hosts within a single
DOI. Typically, such systems require specific certification(s)
and accreditation(s) before deployment or use.
4. DEFAULTS
This Section describes the default behaviour of CALIPSO
compliant end nodes and intermediate systems. Implementers
MAY implement configuration knobs to vary from this behaviour,
provided that the default behaviour (i.e. if the system
administrator does not explicitly change the configured
behaviour of the device) is as described below. If implementers
choose to implement such configuration knobs, the configuration
parameters and the behaviours that they enable and disable
SHOULD be documented for the benefit of system administrators
of those devices.
Each Intermediate System or End System is responsible for
StJohns Et Alia [Page 22]
Internet-Draft 04 JUL 08
properly interpreting and enforcing the MLS Mandatory Access
Control policy. Practically, this means that each node must
evaluate the label on the inbound packet, ensure that this
Sensitivity Label is valid (i.e. within range) for the receiving
interface, and at a minimum only forward the packet to an
interface and node where the Sensitivity Label of the packet
falls within the assigned range of that node's receiving
interface.
Packets with an invalid (e.g. out of range) Sensitivity Label
for the receiving interface MUST be dropped upon receipt. A
Sensitivity Label is valid if and only if the Sensitivity Label
falls within the range assigned to the transmitting interface on
the sending system and within the range assigned to the receiving
interface on the receiving system. These rules also need
to be applied by intermediate systems on each hop that a
CALIPSO-labeled packet traverses, not merely at the end points
of a labeled IP session. As an example, it is a violation of the
default MLS MAC policy for a packet with a higher sensitivity
level (e.g. "MOST SECRET") to transit a link whose maximum
sensitivity level is less than that first sensitivity level
(e.g. "SECRET").
If an unlabeled packet is received from a node which is
not aware of CALIPSO Sensitivity Labels (i.e. unaware to assign
Sensitivity Labels itself) and the packet is destined for a node
which is sensitivity label aware, the receiving intermediate
system needs to insert a Sensitivity Label. This Sensitivity
Label will be equal to the maximum Sensitivity Label assigned
to the originating node if and only if that is known to the
receiving node. If this receiving intermediate system does not
know which Sensitivity Label is assigned to the originating node,
the maximum Sensitivity Label of the interface the packet was
received upon will be inserted.
[NOTE WELL: The procedure in the preceding paragraph is NOT
a label upgrade -- because it is not changing an existing
label; instead, it is simply inserting a Sensivity Label
that has the only "safe" value, given that no other
information is known to the receiving node. In large-scale
deployments, it is very unlikely that a given node will have
any authoritative a priori information about the security
configuration of any node that is NOT on a directly attached
link.]
If a packet is to be sent to a node which is
defined to not be Sensitivity Label aware, from a node
which is label aware, then the Sensitivity Label MAY be
StJohns Et Alia [Page 23]
Internet-Draft 04 JUL 08
removed upon transmission if and only if local security
policy explicitly permits this. The originating node is
still responsible for ensuring that the Sensitivity Label on
the packet falls within the Sensitivity Label range
associated with the receiving node. If the packet will
traverse more than one subnetwork between origin and
destination, and those subnetworks are labeled, then the
packet SHOULD normally contain a Sensitivity Label so that
the packet will be able to reach the destination and the
intermediate systems will be able to apply the requisite MAC
policy to the packet.
[NOTE WELL that in some IPv4 labeled network deployments
that exist as of this writing, the first hop router will
insert a Sensitivity Label into a received unlabeled packet
upon the receipt of that unlabeled packet, in the manner
described above. So sending a packet without a label across
a multiple subnetwork path to a destination does not
guarantee that the packet will arrive containing no
Sensitivity Label.]
5. FORMAT
This section describes the format of the CALIPSO option
for use with IPv6 datagrams. CALIPSO is an IPv6 hop-by-hop
option to ensure that a security gateway or router could
apply access controls to IPv6 packets based on the CALIPSO
label carried by the packet.
An IPv6 datagram normally contains at most one CALIPSO
label. In the special case where (1) a labeled IPv6 datagram
is tunnelled inside another labeled IPv6 datagram AND (2) IP
Security is NOT providing confidentiality protection for the
inner packet, the outer CALIPSO Sensivity Label must have the
same meaning as the inner CALIPSO Sensitivity Label. For
example, it would be invalid to encapsulate an unencrypted IPv6
packet with a Sensitivity Label of (SECRET, no compartments)
inside a packet with an outer Sensitivity Label of (TOP SECRET,
A B).
If the inner IPv6 packet is tunnelled inside the Encapsulating
Security Payload (ESP) and confidentiality is being provided to
that inner packet, then the outer packet MAY have a different
CALIPSO Sensitivity Label -- subject to local security policy.
This option's syntax has been 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
StJohns Et Alia [Page 24]
Internet-Draft 04 JUL 08
several acting as guards). Such a guard device needs to be able
to very rapidly parse the sensitivity label in each packet, apply
ingress interface MAC policy, forward the packet while aware of
the packet's Sensitivity Label, and then apply egress interface
MAC policy.
At least one prior IP Sensitivity Label option used a syntax
that was unduly complex to implement in IP routers, hence never
was implemented in an IP router. So there is a deliberate effort
to choose a streamlined option syntax that is easy to parse, to
encode, and to implement in more general terms.
5.1. Option Format
The CALIPSO option is an IPv6 Hop-by-Hop Option and is
designed to comply with IPv6 optional header rules. Following
the nomenclature of RFC-2460, Section 4.2, the Option Data field
of this option must have 4n alignment.[RFC-2460]
The CALIPSO Option Data MUST NOT change en-route, except when
(1) "DOI translation" is performed by a trusted intermediate
system, (2) a CALIPSO Option is inserted by a trusted
intermediate system upon receipt of an unlabeled IPv6 packet,
or (3) a CALIPSO Option is removed by a last-hop trusted
intermediate system immediately prior to forwarding the packet
to a destination node that does not implement support for
CALIPSO labels. The details of these 3 exceptions are
described elsewhere in this document.
If the option type is not recognised by a node examining the
packet, the option is ignored. However, all implementations
of this specification MUST be able to recognise this option
and therefore MUST NOT ignore this option if it is present
in an IPv6 packet.
This option is designed to comply with the IPv6 optional
header rules. [RFC-2460] The CALIPSO option is always carried
in a Hop-By-Hop Option Header, never in any other part of an
IPv6 packet. This rule exists because IPv6 routers need to be
able to see the CALIPSO label so that those routers are able
to apply MLS Mandatory Access Controls to those packets.
The diagram below shows the CALIPSO option along with
the required (first) 2 fields of the Hop-By-Hop Option Header
that envelopes the CALIPSO option. The design of the CALIPSO
option is arranged to avoid the need for 16 bits of padding
StJohns Et Alia [Page 25]
Internet-Draft 04 JUL 08
between the HDR EXT LEN field and the start of the CALIPSO
option. Also, the CALIPSO Domain of Interpretation field is
laid out so that it normally will be 32-bit aligned.
------------------------------------------------------------
| Next Header | Hdr Ext Len | Option Type | Option Length|
+-------------+---------------+-------------+--------------+
| CALIPSO Domain of Interpretation |
+-------------+---------------+-------------+--------------+
| Cmpt Length | Sens Level | Checksum (CRC-16) |
+-------------+---------------+-------------+--------------+
| Compartment Bitmap (Optional; variable length) |
+-------------+---------------+-------------+--------------+
5.1.1. OPTION TYPE field
This field contains an unsigned 8-bit value. Its value is
(TO BE ASSIGNED BY IANA; the high order bits of this option
need to be 000).
Nodes that do not recognise this option should ignore it.
In the event the IPv6 packet is fragmented, this option MUST be
copied on fragmentation. Virtually all users want the choice
of using the IP Authentication Header (a) to authenticate this
option and (b) to bind this option to the associated IPv6 packet.
5.1.2. OPTION LENGTH field
This field contains an unsigned integer 1 octet in
size. It has minimum value is 8 (e.g. when the Compartment
Bitmap field is absent). This field specifies the Length of
the option data field of this option in octets. The Option
Type and Option Length fields are not included in the length
calculation.
5.1.3 COMPARTMENT LENGTH field
This field contains an unsigned 8-bit integer. The field
specifies the size of the COMPARTMENT BITMAP field in 64-bit
words. The minimum value is zero, which is used only when the
information in this packet is not in any compartment. (In that
situation, the CALIPSO Sensitivity Label has no need for a
Compartment Bitmap).
Because this specification represents Releasabilities on the
wire as inverted Compartments, the size of the COMPARTMENT BITMAP
StJohns Et Alia [Page 26]
Internet-Draft 04 JUL 08
field needs to be large enough to hold not only the set of
logical Compartments, but instead to hold the sum of the set
of logical Compartments and the set of logical Releasabilities.
Recall that the overall length of this option MUST follow
IPv6 optional header rules, including the word alignment rules.
This has implications for the valid values for this field. In
some cases the length of the Compartment Bitmap field might need
to exceed the number of bits required to hold the sum of the
logical Compartments and the logical Releasabilities, in order
to comply with IPv6 alignment rules.
5.1.5 DOMAIN OF INTERPRETATION field
This field contains an unsigned 32-bit integer.
IANA maintains a registry with assignments of the DOI values
used in this field. The DOI identifies the rules under
which this datagram must be handled and protected. The NULL
DOI, in which this field is all zeros, MUST NOT appear in
any IPv6 packet on any network.
NOTE WELL: The DOMAIN OF INTERPRETATION where all 4 octets
contain zero is defined to be the NULL DOI. The NULL DOI has
no compartments and has a single level whose value and
CALIPSO representation are each zero. The NULL DOI MUST NOT
ever appear on the wire. If a packet is received containing
the NULL DOI, that packet MUST be dropped and the event
SHOULD be logged as a security fault. Also note that the
CALIPSO DOI is unrelated to the IP Security DOI.
5.1.6. SENSITIVITY LEVEL field
This contains an unsigned 8-bit value. This field
contains an opaque octet whose value indicates the relative
sensitivity of the data contained in this datagram in the
context of the indicated DOI. The values of this field MUST
be ordered, with 00000000 being the lowest sensitivity level
and 11111111 being the highest sensitivity level.
However, in a typical deployment, not all 256
Sensitivity Levels will be in use. So the set of valid
Sensitivity Level values depends upon the CALIPSO DOI in
use. This sensitivity ordering rule is necessary so that
intermediate systems (e.g. routers or MLS guards) will be
able to apply MAC policy with minimal per-packet computation
and minimal configuration.
StJohns Et Alia [Page 27]
Internet-Draft 04 JUL 08
5.1.7. 16-bit Checksum Field
This field contains an unsigned 16-bit integer holding the
16-bit checksum calculated over the entire CALIPSO option in this
packet. The checksum algorithm is the 16-bit checksum defined
in Appendix C of RFC-1662.[RFC-1662] For processing simplicity,
keeping the potential for a hardware implementation in mind,
this 16-bit checksum is always present, even when AH is used.
5.1.8. 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.
This specification represents a Releasability on the wire
as if it were an inverted Compartment. So the Compartment Bitmap
holds the sum of both logical Releasabilities and also logical
Compartments for a given DOI value. The encoding of the
Releasabilities in this field is described elsewhere in this
document. The Releasability encoding is designed to permit the
Compartment Bitmap evaluation to occur without the evaluator
necessarily knowing the human semantic associated with each bit
in the Compartment Bitmap. In turn, this facilitates the
implementation and configuration of Mandatory Access Controls
based on the Compartment Bitmap within IPv6 routers or guard
devices.
5.2. Packet Word Alignment considerations
The basic option is variable length, due to the variable
length Compartment Bitmap field.
Intermediate Systems that lack custom silicon processing
capabilities and most End Systems perform best when processing
fixed length, fixed location items. So the IPv6 base specification
levies certain requirements on all IPv6 optional headers. So the
Compartment Bitmap field must have length in quanta of 64-bit words
(e.g. 0 bits, 64 bits, 128 bits)
StJohns Et Alia [Page 28]
Internet-Draft 04 JUL 08
6. USAGE
This section describes specific protocol processing steps
required for systems that claim to implement or conform with this
specification.
6.1. Sensitivity Label Comparisons
This section describes how comparisons are made between
two Sensitivity Labels. Implementing this comparison correctly
is critical to the MLS system providing the intended Mandatory
Access Controls (MAC) to network traffic entering or leaving
the system.
A Sensitivity Label consists of a DOI, a Sensitivity Level,
and zero or more Compartments. The following notation will be
used:
A.DOI = the DOI portion of Sensitivity Label A
A.LEV = the Sensitivity Level portion of Sensitivity Label A
A.COMP = the Compartments portion of Sensitivity Label A
6.1.1. "Within Range"
A Sensitivity Label, "M", is "within range" for a
particular range "LO:HI" if and only if:
1. M, LO, and HI are members of the same DOI.
(M.DOI == LO.DOI == HI.DOI)
2. The range is a valid range. A given range LO:HI is
valid if and only if HI dominates LO.
((LO.LEV <= HI.LEV) && (LO.COMP <= HI.COMP))
3. The Sensitivity Level of M dominates the low-end (LO)
Sensitivity Level AND the Sensitivity Level of M is
dominated by the high-end (HI) Sensitivty Level.
(LO.LEV <= M.LEV <= HI.LEV)
AND
4. The Sensitivity Label M has a compartment set that
dominates the compartment set contained in the
Sensitivity Label from the low-end range (LO), and
which is dominated by the Compartment set contained
StJohns Et Alia [Page 29]
Internet-Draft 04 JUL 08
in the high-end Sensitivity Label (HI) from the range.
(LO.COMP <= M.COMP <= HI.COMP)
6.1.2. "Less Than" or "Below Range"
A Sensitivity Label "M" is "less than" some other
Sensitivity Label "LO" if and only if:
1. The DOI for the Sensitivity Label M is identical
to the DOI for both the low-end and high-end of
the range.
(M.DOI == LO.DOI == HI.DOI)
AND EITHER
2. The sensitivity level of M is less than the
sensitivity level of LO.
(M.LEV < LO.LEV)
OR
3. The compartment set of Sensitivity Label M is
dominated by the compartment set of Sensitivity
Label LO.
(M.COMP <= LO.COMP)
A Sensitivity Label "M" is "below range" for a Sensitivity Label
"LO:HI", if LO dominates M and LO is not equal to M.
6.1.3. "Greater Than" or "Above Range"
A Sensitivity Label, "M" is "greater than" some Sensitivity
Label "HI" if and only if:
1. Their DOI's are identical.
(M.DOI == HI.DOI)
AND EITHER
2A. M's sensitivity level is above HI's sensitivity level.
StJohns Et Alia [Page 30]
Internet-Draft 04 JUL 08
(M.LEV > HI.LEV)
OR
2B. M's compartment set is greater than HI's compartment set.
(M.COMP > HI.COMP)
A Sensitivity Label, "M", is "above range" for a Sensitivity Label,
"LO:HI", if M dominates HI and M is not equal to HI.
6.1.4. "Equal To"
A Sensitivity Label "A" is "equal to" another
Sensitivity Label "B" if and only if:
1. They have the exact same DOI.
(A.DOI == B.DOI)
2. They have identical sensitivity levels.
(A.LEV == B.LEV)
3. Their compartment sets are identical.
(A.COMP == B.COMP)
6.1.5. "Disjoint" or "Incomparable"
A Sensitivity Label "A" is disjoint from another
Sensitivity Label "B" if any of these conditions are true:
1. Their DOI's differ.
(A.DOI <> B.DOI)
2. B does not dominate A, A does not dominate B,
and A is not equal to B.
(^( (A < B) || (A > B) || (A == B) ))
3. Their compartment sets are disjoint from each
other; A's compartment set does not dominate B's
compartment set AND B's compartment set does not
StJohns Et Alia [Page 31]
Internet-Draft 04 JUL 08
dominate A's compartment set.
(^( (A.COMP >= B.COMP) || (A.COMP <= B.COMP) ))
6.2. End System Processing
This section describes CALIPSO-related processing for IPv6
packets imported or exported from an End System claiming to
implement or conform with this specification. This document
places no additional requirements on IPv6 nodes that do not
claim to implement or conform with this document.
6.2.1 Export
An end system which sends data to the network is said to
"export" it to the network. Before a datagram can leave an end
system and be transmitted over a network the following ordered
steps must occur:
1. Selection of the export DOI:
a) If the upper level protocol selects a DOI,
then that DOI is the one used.
b) 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.
c) elseIf there is a specific DOI associated with the
sending logical interface (i.e. IP address),
then that DOI is selected.
d) Else the default DOI for the system is selected.
NOTE WELL:
A connection-oriented transport-layer protocol session
(e.g. TCP session, SCTP session) MUST have the same DOI and
same Sensitivity Label for the life of that connection. The
DOI is selected at connection initiation and MUST NOT change
during the session.
A trusted multi-level application that possesses
appropriate privilege MAY use multiple connection-oriented
transport-layer protocol sessions with differing Sensitivity
Labels concurrently.
Some trusted UDP-based applications (e.g. remote
StJohns Et Alia [Page 32]
Internet-Draft 04 JUL 08
procedure call service) multiplex different transactions
having different sensitivity levels in different packets
for the same IP session (e.g. IP addresses and UDP ports
are constant for a given UDP session). In such cases,
the Trusted Computing Base MUST ensure that each packet
is labeled with the correct Sensitivity Label for the
information carried in that particular packet.
In the event the End System selects and uses a specific
DOI and that DOI is not recognised by the originating Node's
first-hop router, the packet MUST be dropped by the first-hop
router. In such a case, the networking API should indicate
the connection failure (e.g. with some appropriate error,
such as ENOTREACH). This fault represents either incorrect
configuration of either the Intermediate System or of the
End System -- xor correct operation for a node that is not
permitted to send IPv6 packets with that DOI through that
Intermediate System.
When an MLS End ystem is connected to an MLS LAN, it is
possible that there would be more than one first-hop
Intermediate System concurrently, with different
Intermediate Systems having different valid Sensitivity
Label ranges. Thoughtful use of the IEEE 802 Virtual
LAN (VLAN) standard (e.g. with different VLAN IDs
corresponding to different sensitivity ranges) might
ease proper system configuration in such deployments.
2. Export Labeling:
Once the DOI is selected, the CALIPSO Sensitivity
Label and values are determined based on the internal
sensitivity label and the DOI. In the event the internal
sensitivity level does not map to a valid CALIPSO
Sensitivity Label, then an error SHOULD be returned
to the upper level protocol and that error MAY be
logged. No further attempt to send this datagram
should be made.
3. Access Control:
Once the datagram is marked and the sending logical
interface is selected (by the routing code), the
datagram's Sensitivity Label is compared against the
Sensitivity Label range(s) associated with that logical
interface. For the datagram to be sent, the interface
StJohns Et Alia [Page 33]
Internet-Draft 04 JUL 08
MUST list the DOI of the datagram Sensitivity Label as
one of the permissible DOI's and the datagram Sensitivity
Label must be within range for the range associated with
that DOI. If the datagram fails this access test an
error SHOULD be returned to the upper level protocol
and MAY be logged. No further attempt to send this
datagram should be made.
6.2.2. Import
When a datagram arrives at an interface on an end system,
the receiving end system MUST:
1. Verify the CALIPSO checksum. Datagrams with
invalid checksums MUST be silently dropped.
Such a drop event SHOULD be logged as a security
fault with an indication of what happened.
2. Verify the CALIPSO has a known and valid DOI.
Datagrams with unrecognized or illegal DOIs MUST
be silently dropped. Such an event SHOULD be
logged as a security fault with an indication
of what happened.
3. Verify the DOI is a permitted one for the receiving
interface. Datagrams with prohibited DOI values
MUST be silently dropped. Such an event SHOULD
be logged as a security fault with an indication
of what happened.
4. Verify the CALIPSO Sensitivity Label is within
the permitted range for the receiving interface:
NOTE WELL:
EACH permitted DOI on an interface has a
separate table describing the permitted range
for that DOI.
A datagram which has a Sensitivity Label within
the permitted range is accepted for further
processing.
A datagram which has a Sensitivity Label disjoint
with the permitted range MUST be silently dropped.
Such an event SHOULD be logged as a security fault,
with an indication that the packet was dropped
because of a disjoint Sensitivity Label. An ICMP
error message MUST NOT be sent in this case.
StJohns Et Alia [Page 34]
Internet-Draft 04 JUL 08
A datagram which has a Sensitivity Label below
the permitted range MUST be dropped. This event
SHOULD be logged as a security fault with an
indication of what happened. An ICMP error
message MUST NOT be sent in this case.
A datagram with a Sensitivity Label above the
permitted range MUST be dropped. This event
SHOULD be logged with an indication of what
happened. An ICMP error message MUST NOT
be sent in this case.
5. Once the datagram has been accepted, the import
Sensitivity Label and DOI are used to associate
the appropriate internal Sensitivity Label with
the data contained in the datagram. This
information MUST be carried as part of the
information returned to the upper-layer protocol.
6.3. Intermediate System Processing
This section describes CALIPSO-related processing for IPv6
packets transiting an IPv6 Intermediate System that claims to
implement and comply with this specification. This document
places no additional requirements on IPv6 Intermediate Systems
that do not claim to comply or conform with this document.
The CALIPSO packet format has been designed so that one can
configure an intermediate system with the minimum sensitivity
level, maximum sensitivity level, minimum compartment bitmap,
and maximum compartment bitmap -- and then deploy that system
without forcing the system to know the detailed human meaning
of each sensitivity level or compartment bit value. Instead,
once the minimum and maximum labels have been configured, the
intermediate system can apply a simple algorithm to determine
whether or not a packet is within range for a given interface.
This design should be straight-forward to implement in ASIC or
FPGA hardware because the option format is simple and easy to
parse, and because only a single comparison algorithm (defined
in this RFC, hence known in advance) is needed.
6.3.1. Input
Intermediate Systems have slightly different rules for
processing marked datagrams than do end systems. Primarily,
Intermediate Systems do not IMPORT or EXPORT transit datagrams,
they just forward them. Also, in most deployments intermediate
systems are used to provide Mandatory Access Controls to packets
StJohns Et Alia [Page 35]
Internet-Draft 04 JUL 08
traversing more than one subnetwork.
The following checks MUST occur before any other
processing. Upon receiving a CALIPSO-labeled packet,
an intermediate system must:
1. Determine whether or not this datagram is destined
for (addressed to) this Intermediate System. If
so, then the Intermediate System becomes an End
System for the purposes of receiving this
particular datagram and the rules for IMPORTing
described above are followed.
2. Verify the CALIPSO checksum. Datagrams with
invalid checksums MUST be silently dropped. The
drop event SHOULD be logged as a security fault
with an indication of what happened and MAY
additionally be logged as a network fault.
NOTE WELL:
A checksum failure could indicate a general network
problem (e.g. noise on a radio link) that is
unrelated to the presence of a CALIPSO option, but
it also could indicate an attempt by an adversary
to tamper with the value of a CALIPSO label.
3. Verify the CALIPSO has a known and valid DOI.
Datagrams with unrecognized or illegal DOIs MUST
be silently dropped. Such an event SHOULD be
logged as a security fault with an indication of
what happened.
4. Verify the DOI is a permitted one for the receiving
interface. Datagrams with prohibited DOIs MUST be
silently dropped. Such a drop SHOULD be logged as
a security fault with an indication of what
happened.
5. Verify the Sensitivity Label within the CALIPSO
is within the permitted range for the receiving
interface:
NOTE WELL:
Each permitted DOI on an interface has a
separate table describing the permitted range
for that DOI.
StJohns Et Alia [Page 36]
Internet-Draft 04 JUL 08
A rejected datagram which has a Sensitivity Label
below or disjoint with the permitted range MUST be
silently dropped. Such an event SHOULD be logged
as a security fault with an indication of what
happened. An ICMP error message MUST NOT be sent
in this case.
A rejected datagram with a Sensitivity Label above
the permitted range MUST be dropped. The drop
event SHOULD be logged as a security fault with an
indication of what happened. An ICMP error
message MUST NOT be sent in this case.
If and only if all the above conditions are met is the
datagram accepted by the IPv6 Intermediate System for further
processing and forwarding.
At this point, the datagram is within the permitted range
for the Intermediate System, so appropriate ICMP error messages
MAY be created by the IP module back to the originating End
System regarding the forwarding of the datagram. These ICMP
messages MUST be created with the exact same Sensitivity Label
as the datagram causing the error. Standard rules about
generating ICMP error messages (e.g. never generate an ICMP error
message in response to a received ICMP error message) continue
to apply. Note that these locally-generated ICMP messages
must go through the same outbound checks (including MAC checks)
as any other forwarded datagram as described in the following
paragraphs.
6.3.2. Translation
It is at this point that TRANSLATION of the CALIPSO
takes place if at all. Please see Section 6.4 for a
discussion of the appropriate processing for Translation.
6.3.3. Output
Once the forwarding code has selected the interface
through which the datagram will be transmitted the following
takes place:
1. Verify the DOI is a permitted one for the sending
interface and that the datagram is within the
permitted range for the DOI and for the interface.
StJohns Et Alia [Page 37]
Internet-Draft 04 JUL 08
2. Datagrams with prohibited DOIs or with out of range
Sensitivity Labels MUST be dropped. Any drop event
SHOULD be logged as a security fault, including
appropriate details about which datagram was
dropped and why.
3. Datagrams with prohibited DOIs or out of range
Sensitivity Labels MAY result in an ICMP "Destination
Unreachable" error message, depending upon the
security configuration of the system.
If the cause of the dropped packet is that the
DOI is prohibited or unrecognised, then a reason
code of "No Route to Host" is used. If the dropped
packet's DOI is valid, but the Sensitivity Label
is out of range, then a reason code of
"Administratively Prohibited" is used. If an
unlabelled packet has been dropped because the
packet is required to be labelled, then a reason
code of "Administratively Prohibited" is used.
In all cases, if an ICMP Error Message is sent,
then it MUST be sent with the same Sensitivity
Label as the rejected datagram.
The choice of whether or not to send an ICMP
message, if sending an ICMP message for this case
is implemented, MUST be configurable, and SHOULD
default to OFF. Standard conditions about
generating ICMP error messages (e.g. never send
an ICMP error message about a received ICMP
error message) continue to apply.
6.4. Translation
A system which provides on-the-fly re-labeling is said
to "translate" from one DOI to another. There are basically
two ways a datagram can be relabeled:
EITHER the Sensitivity Label can be converted from a
CALIPSO Sensitivity Label, to an internal Sensitivity Label,
and then back to a new CALIPSO Sensitivity Label, XOR a
CALIPSO Sensitivity Label can be directly remapped into a
new CALIPSO Sensitivity Label.
The first of these methods is the functional
equivalent of "importing" the datagram then "exporting" it
and is covered in detail in the "Import" and "Export"
StJohns Et Alia [Page 38]
Internet-Draft 04 JUL 08
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 DOI
and input Sensitivity Label and (2) the output DOI. In the
event the input Sensitivity Label does not map to a valid
output Sensitivity Label for the output DOI, then the
datagram MUST be silently dropped and the drop event SHOULD
be logged as a security fault.
Once the datagram is re-labeled, the output
procedures under Section 5.3 "Intermediate Systems" are
followed, with the exception that any error that would cause
an ICMP error message to be generated back to the originating
End System instead MUST silently drop the datagram without
sending an ICMP error message. Such a drop SHOULD be logged
as a security fault.
7. IMPLEMENTATION CONSIDERATIONS
This section contains "implementation considerations";
it does not contain "requirements". Implementation experience
might eventually turn some of them into implementation
requirements in some future version of this specification.
StJohns Et Alia [Page 39]
Internet-Draft 04 JUL 08
7.1. Intermediate Systems
Performance is optimised if there is hardware
support for applying the Mandatory Access Controls based on
this label option. The label option syntax has been
designed so that it should be straight-forward to implement
support for this option and the associated Mandatory Access
Controls in custom logic (e.g. in Verilog or VHDL).
7.2. End Systems
It is possible for a system administrator to create
two DOIs with different overlapping compartment ranges. This
can be used to reduce the size of the IPv6 Sensitivity Label
option in some deployments.
7.3. Upper-Level Protocols
As CALIPSO is an IP option, this document focuses
upon the network-layer handling of IP packets containing
CALIPSO options. This section provides some discussion of
upper-layer protocol issues.
This section is not a complete specification for
how a MLS host handles information internally after the
decision has been made to accept a received IPv6 packet
containing a CALIPSO option. Implementers of MLS systems
might wish also to consult [TCSEC], [CMW], [CC],
[ISO-15408], and [DoD MLOS PP].
In a typical MLS host, the information received from
the network (i.e. information not dropped by the network-layer
as a result of the CALIPSO processing described in this document)
is assigned an internal Sensitivity Label while inside the
host operating system. The MLS host uses the Bell-LaPadula
Mandatory Access Control policy [BL73] to determine how that
information is processed, including to which transport-layer
sessions or to which applications the information is delivered.
Within this section, we use one additional notation,
in an attempt to be both clear and concise. Here, the
string "W:XY" defines a Sensitivity Label where the
sensitivity level is W and where X and Y are the only
compartments enabled, while the string "W::" defines a
Sensitivity Label where the Sensitivity Level is W and there
are no compartments enabled.
StJohns Et Alia [Page 40]
Internet-Draft 04 JUL 08
7.3.1. TCP-related issues
With respect to a network, each distinct Sensitivity Label
represents a separate virtual network which shares the same
physical network.
The above statement taken from section 3 has a
non-obvious, but critical, corollary. If there are separate
virtual networks then it is possible for a system which
exists in multiple virtual networks to have identical TCP
connections, each one existing in a different virtual
network.
TCP connections are normally identified by source
and destination port, and source and destination address.
If a system labels datagrams with the CALIPSO option (which
it must do if it exists in multiple virtual networks -
e.g. a "multi-level secure" system), then TCP connections
are identified by source and destination port, source and
destination address, and an internal Sensitivity Label
(optionally, a Sensitivity Label range).
7.3.2. UDP-related Issues
Unlike TCP or SCTP, UDP is a stateless protocol,
at least conceptually. However, many implementations of UDP
have some session state (e.g. Protocol Control Blocks in
4.4 BSD), although the UDP protocol specifications do not
require any state.
One consequence of this is that in widely used host
implementations of UDP and IPv6, a UDP listener might be
bound only to a particular UDP port on its host -- without
binding to a particular remote IP address or local IP
address.
UDP can be used with unicast or with multicast. Some
existing UDP host implementations permit a single UDP packet
to be delivered to more than one listener at the same time.
Except for the application of Mandatory Access Controls,
the behaviour of a given system should remain the same
(so that application behaviour does not change in some
unexpected way) with respect to delivery of UDP datagrams
to listeners.
For example, if a listener on UDP port X has a
Sensitivity Label range with a minimum of "S:AB" and a
maximum of "S:AB", then only datagrams with a destination
StJohns Et Alia [Page 41]
Internet-Draft 04 JUL 08
of UDP port X and a Sensitivity Label of "S:AB" will be
delivered to that listener.
For example, if a listener on UDP port Y has a
Sensitivity Label range with a minimum of "W::" and a
maximum of "X:ABC" (where X dominates W), then a datagram
addressed to UDP port Y with a Sensitivity Label of "W:A"
normally would be delivered to that listener.
7.3.3. SCTP-related Issues
With respect to a network, each distinct Sensitivity Label
represents a separate virtual network which shares the same
physical network.
The above statement taken from section 3 has a non-obvious,
but critical, corollary. If there are separate virtual networks
then it is possible for a system which exists in multiple virtual
networks to have identical SCTP connections, each one existing
in a different virtual network.
As with TCP, SCTP is a connection-oriented transport protocol
and has substantial session state. In single-level hosts, this
state includes the set of remote IP addresses, the set of local
IP addresses, the remote SCTP port number, and the local SCTP
port number. In MLS hosts, the SCTP session state also includes
the Sensitivity Label (or, optionally, the Sensitivity Label
range) for each SCTP session. Unlike TCP, SCTP has the ability
to shift an existing SCTP session from one endpoint IP address
to a different IP address that belongs to the same endpoint.
CALIPSO-labeled SCTP data that is received should be sent
to all SCTP listeners for that particular SCTP connection where
the Sensitivity Label of the received SCTP data is within range
for that listener's Sensitivity Label range.
Further, although a node might be multi-homed, it is
entirely possible that only one of those interfaces is reachable
for a given Sensitivity Label value. For example, one network
interface on a node might have a Sensitivity Label range from
"A::" to "B:XY" (where B dominates A), while a different network
interface on the same node might have a Sensitivity Label range
from "U::" "U::" (where A dominates U). In that example, if a
packet has a CALIPSO label of "A:X", then that packet will not be
able to use the "U"-only network interface. This might lead to
novel operational issues with SCTP sessions. Implementers ought
to give special attention to this SCTP-specific issue.
StJohns Et Alia [Page 42]
Internet-Draft 04 JUL 08
7.3.4. Security Logging
This option is recommended for deployment only in
well-protected private networks that are NOT connected to the
global Internet. By definition, such private networks are also
composed only of trusted systems that are believed to be
trustworthy. So the risk of a denial of service attack upon the
logging implementation is much lower in the intended deployment
environment than it would have been for general Internet
deployments.
8. SECURITY CONSIDERATIONS
This document describes a mechanism for adding explicit
Sensitivity Labels to IPv6 datagrams. The primary purpose of
these labels is to facilitate application of Mandatory Access
Controls (MAC) in End Systems or Intermediate Systems that
implement this specification. As such, correct implementation
of this mechanism is very critical to the overall security
of the systems and networks where this mechanisms is deployed.
Use of high-assurance development techniques is encouraged.
End users carefully should consider the assurance requirements
of their particular deployment, in the context of that
deployment's prospective threats.
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.
Because the IP Authentication Header will include the CALIPSO
option among the protected IPv6 header fields, modification of
a CALIPSO-labeled packet that also contains an IP Authentication
Header will cause the resulting packet to fail authentication
at the destination node for the AH security session. Therefore,
CALIPSO labels cannot be inserted, deleted, or translated for
IPv6 packets that contain an IP Authentication Header. In
situations where such a modification by an intermediate system
is required, but is not possible due to AH, then the packet
MUST be dropped instead. If the packet must be dropped for
this reason, then an ICMP Destination Unreachable error message
SHOULD be sent back to the originator of the dropped packet with
a reason code of "Administratively Prohibited". If the packet
can be forwarded properly without violating the MLS MAC policy
StJohns Et Alia [Page 43]
Internet-Draft 04 JUL 08
of the intermediate system, then (by definition) such a packet
modification is not required.
Note that in a number of error situations with labelled
networking, an ICMP error message MUST NOT be sent in order to
avoid creating security problems. In certain other error
situations, an ICMP error message might be sent. Even if an
ICMP error message is sent, it might be dropped along the way
before reaching its intended destination -- due to MAC rules,
DOI differences, or other configured security policies along
the way from the node creating the ICMP error message to the
intended destination node. In turn, this can mean operational
faults (e.g. fibre cut, misconfiguration) in a labelled network
deployment might be more difficult to identify and resolve.
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.
IP packets containing visible packet labels ought never
traverse the public Internet. Of course, subject to local
security policies, encrypted IP packets with CALIPSO labels
might well traverse the public Internet (e.g. through a
Tunnel-mode ESP VPN tunnel that connects two or more MLS
labelled network segments).
Accreditors of a given deployment should consider
not only personnel clearances and physical security issues,
but also electronic security (e.g. TEMPEST), network security
(NETSEC), communications security (COMSEC), and other issues.
9. IANA CONSIDERATIONS
IANA is requested to assign an IPv6 Hop-by-Hop
option number to the CALIPSO option described in this
specification. This option is immutable during transit.
(NOTE TO IANA: high-order bits of this option should be 000,
indicating that nodes should ignore this option if it is not
recognised by the node.)
Also, IANA is requested to create a registry for
CALIPSO DOI values. The initial values for this registry,
shown in dotted-quad format, are as follows:
DOI Value Organisation or Use
======================= ============================
StJohns Et Alia [Page 44]
Internet-Draft 04 JUL 08
0:0:0:0 Null DOI; MUST NOT be used
on any network at any time.
0:0:0:1 to 0:255:255:255 For private use among
consenting parties within
private networks; for reasons
of interoperability, these
DOI values MUST NOT ever
appear on the global public
Internet.
1:0:0:0 to 254:255:255:255 For assignment by IANA to
organisations following the
guidelines in the paragraph
below.
255:0:0:0 to 255:0:0:0 Reserved to the IETF for
future use by possible
revisions of this specification.
For the CALIPSO DOI values registry, IANA is requested to
issue a new DOI value to any organisation that requests it.
Any assignments made will be publicly available from the IANA
website.
DOI values beginning with decimcal 0:0:0 are reserved for
private use amongst consenting parties; values in this range
will not be allocated by IANA to any particular user or user
community. For reasons of interoperability, these DOI values
MUST NOT ever appear on the global public Internet.
A commercial organisation will normally only be assigned
at most two DOI values.
A single national government or multi-national treaty
organisation (e.g. NATO, UN) normally may be assigned up
to 10 CALIPSO DOI values, if that is requested. If a given
national government has NOT requested a set of national values,
then different government departments (e.g. Ministry of Defence,
Department of Energy, Department of Homeland Security) or
different states/provinces (e.g. Queensland, New South Wales)
within that given national government each normally may
independently request up to 2 different CALIPSO DOI values.
DOI values beginning with decimal 255 are reserved to
the IETF for use in future versions of this specification.
IESG approval is required for allocation of DOI values
within that range.
With respect to delegation in unclear circumstances, IANA
StJohns Et Alia [Page 45]
Internet-Draft 04 JUL 08
may ask the IESG to appoint "Designated Experts" to provide
advice.
(Editor's Note: Specific inputs from the IESG on what the
text in this section should say would be very helpful.)
ACKNOWLEDGEMENTS
This document is directly derived from an Internet-Draft
titled "Son of IPSO (SIPSO)" written by Mike StJohns circa 1992.
Packet format changes have been made since that draft, primarily
to comply with IPv6 syntax rules. The concepts, most definitions,
and nearly all of the processing rules here are identical to those
in that earlier document.
Steve Brenneman, L.C. Bruzenak, Alfred Hoenes, Jarrett Lu,
Dan McDonald, Paul Moore, Joe Nall, Dave Parker, and Bill
Sommerfeld (listed in alphabetical order) provided feedback on
earlier versions of this document. The editors also would like
to thank the several anonymous reviewers for their feedback,
and particularly for sharing their insights into operational
considerations with MLS networking.
INFORMATIVE REFERENCES
[BL73] Bell, D.E. & LaPadula, L.J., "Secure Computer
Systems: Mathematical Foundations and Model"
Technical Report M74-244, MITRE Corporation,
Bedford, MA, May 1973.
[CW87] D.D. Clark & D.R. Wilson, "A Comparison of
Commercial and Military Computer Security
Policies", in Proceedings of the IEEE Symposium
on Security & Privacy, pp. 184-194, IEEE
Computer Society, Oakland, CA, May 1987.
[CMW] US Defense Intelligence Agency,
"Compartmented Mode Workstation Evaluation
Criteria", Technical Report
DDS-2600-6243-91, Washington, DC,
November 1991.
[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",
StJohns Et Alia [Page 46]
Internet-Draft 04 JUL 08
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.
[RFC-2119] S. Bradner, "Key words for use in RFCs to
Indicate Requirement Levels", RFC-2119,
March 1997.
[IPSEC] S. Kent & K. Seo, "Security Architecture for the
StJohns Et Alia [Page 47]
Internet-Draft 04 JUL 08
Internet Protocol", RFC-4301, December 2005.
[AH] S. Kent, "IP Authentication Header", RFC-4302,
December 2005.
[ESP] S. Kent, "IP Encapsulating Security Payload",
RFC-4303, December 2005.
NORMATIVE REFERENCES
[RFC-2460] S. Deering & R. Hinden, "Internet Protocol
Version 6 Specification", RFC-2460,
December 1998.
[RFC-1662] W. Simpson, "PPP in HDLC-like Framing",
Appendix C, RFC-1662, July 1992.
AUTHORS:
M. StJohns
Germantown, MD
R. Atkinson
Extreme Networks
3585 Monroe Street
Santa Clara, CA
USA 95051
rja@extremenetworks.com
+1 (408)579-2800
G. Thomas
US Department of Defense
Washington, DC
USA
StJohns Et Alia [Page 48]
Internet-Draft 04 JUL 08
IETF IPR Clause
The IETF takes no position regarding the validity or scope
of any Intellectual Property Rights or other rights that
might be claimed to pertain to the implementation or use
of the technology described in this document or the extent
to which any license under such rights might or might not
be available; nor does it represent that it has made any
independent effort to identify any such rights.
Information on the procedures with respect to rights in
RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and
any assurances of licenses to be made available, or the
result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by
implementers or users of this specification can be
obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its
attention any copyrights, patents or patent applications,
or other proprietary rights that may cover technology
that may be required to implement this standard. Please
address the information to the IETF at ietf-ipr@ietf.org.
COPYRIGHT
Copyright (C) The IETF Trust (2008).
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.
Draft Expires: 04 JAN 2009
StJohns Et Alia [Page 49]
| PAFTECH AB 2003-2026 | 2026-04-23 20:38:15 |