diff options
Diffstat (limited to 'doc/rfc/rfc5570.txt')
| -rw-r--r-- | doc/rfc/rfc5570.txt | 2915 |
1 files changed, 2915 insertions, 0 deletions
diff --git a/doc/rfc/rfc5570.txt b/doc/rfc/rfc5570.txt new file mode 100644 index 0000000..863173a --- /dev/null +++ b/doc/rfc/rfc5570.txt @@ -0,0 +1,2915 @@ + + + + + + +Network Working Group M. StJohns +Request for Comments: 5570 Consultant +Category: Informational R. Atkinson + Extreme Networks + G. Thomas + US Department of Defense + July 2009 + + + Common Architecture Label IPv6 Security Option (CALIPSO) + +Abstract + + This document describes an optional method for encoding explicit + packet Sensitivity Labels on IPv6 packets. It is intended for use + only within Multi-Level Secure (MLS) networking environments that are + both trusted and trustworthy. + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +IESG Note + + This RFC specifies the use of an IPv6 hop-by-hop option. The IESG + notes that general deployment of protocols with hop-by-hop options + are problematic, and the development of such protocols is + consequently discouraged. After careful review, the IETF has + determined that a hop-by-hop option is an appropriate solution for + this specific limited environment and use case. Furthermore, the + mechanism specified in this RFC is only applicable to closed IP + networks. It is unsuitable for use and ineffective on the global + public Internet. + +Copyright Notice + + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents in effect on the date of + publication of this document (http://trustee.ietf.org/license-info). + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. + + + + + +StJohns, et al. Informational [Page 1] + +RFC 5570 CALIPSO July 2009 + + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +StJohns, et al. Informational [Page 2] + +RFC 5570 CALIPSO July 2009 + + +Table of Contents + + 1. Introduction ....................................................4 + 1.1. History ....................................................4 + 1.2. Intent and Applicability ...................................6 + 1.3. Deployment Examples ........................................7 + 2. Definitions .....................................................9 + 2.1. Domain of Interpretation ...................................9 + 2.2. Sensitivity Level .........................................10 + 2.3. Compartment ...............................................10 + 2.4. Releasability .............................................11 + 2.5. Sensitivity Label .........................................16 + 2.6. Import ....................................................17 + 2.7. Export ....................................................17 + 2.8. End System ................................................18 + 2.9. Intermediate System .......................................18 + 2.10. System Security Policy ...................................19 + 3. Architecture ...................................................19 + 4. Defaults .......................................................24 + 5. Format .........................................................26 + 5.1. Option Format .............................................27 + 5.2. Packet Word Alignment Considerations ......................30 + 6. Usage ..........................................................31 + 6.1. Sensitivity Label Comparisons .............................31 + 6.2. End System Processing .....................................34 + 6.3. Intermediate System Processing ............................37 + 6.4. Translation ...............................................40 + 7. Architectural and Implementation Considerations ................41 + 7.1. Intermediate Systems ......................................42 + 7.2. End Systems ...............................................43 + 7.3. Upper-Layer Protocols .....................................43 + 8. Security Considerations ........................................46 + 9. IANA Considerations ............................................48 + 9.1. IP Option Number ..........................................48 + 9.2. CALIPSO DOI Values Registry ...............................49 + 10. Acknowledgments ...............................................50 + 11. References ....................................................50 + 11.1. Normative References .....................................50 + 11.2. Informative References ...................................50 + + + + + + + + + + + + +StJohns, et al. Informational [Page 3] + +RFC 5570 CALIPSO July 2009 + + +1. Introduction + + The original IPv4 specification in RFC 791 includes an option for + labeling the sensitivity of IP packets. That option was revised by + RFC 1038 and later by RFC 1108 [RFC791] [RFC1038] [RFC1108]. + Although the IETF later deprecated RFC 1108, that IPv4 option + continues to be in active use within a number of closed Multi-Level + Secure (MLS) IP networks. + + One or another IP Sensitivity Label option has been in limited + deployment for about two decades, most usually in governmental or + military internal networks. There are also some commercial sector + deployments, where corporate security policies require Mandatory + Access Controls be applied to sensitive data. Some banks use MLS + technology to restrict sensitive information, for example information + about mergers and acquisitions. This IPv6 option, like its IPv4 + predecessors, is only intended for deployment within private + internetworks, disconnected from the global Internet. This document + specifies the explicit packet labeling extensions for IPv6 packets. + +1.1. History + + This document is a direct descendent of RFC 1038 and RFC 1108 and is + a close cousin to the work done in the Commercial IP Security Option + (CIPSO) Working Group of the Trusted Systems Interoperability Group + (TSIG) [FIPS-188]. The IP Security Option defined by RFC 1038 was + designed with one specific purpose in mind: to support the fielding + of an IPv4 packet-encryption device called a BLACKER [RFC1038]. + Because of this, the definitions and assumptions in those documents + were necessarily focused on the US Department of Defense and the + BLACKER device. Today, IP packet Sensitivity Labeling is most + commonly deployed within Multi-Level Secure (MLS) environments, often + composed of Compartmented Mode Workstations (CMWs) connected via a + Local Area Network (LAN). So the mechanism defined here is + accordingly more general than either RFC 1038 or RFC 1108 were. + + Also, the deployment of Compartmented Mode Workstations ran into + operational constraints caused by the limited, and relatively small, + space available for IPv4 options. This caused one non-IETF + specification for IPv4 packet labeling to have a large number of + sub-options. A very unfortunate side effect of having sub-options + within an IPv4 label option was that it became much more challenging + to implement Intermediate System support for Mandatory Access + Controls (e.g., in a router or MLS guard system) and still be able to + forward traffic at, or near, wire-speed. + + + + + + +StJohns, et al. Informational [Page 4] + +RFC 5570 CALIPSO July 2009 + + + In the last decade or so, typical Ethernet link speeds have changed + from 10 Mbps half-duplex to 1 Gbps full-duplex. The 10 Gbps full- + duplex Ethernet standard is widely available today in routers, + Ethernet switches, and even in some servers. The IEEE is actively + developing standards for both 40 Gbps Ethernet and 100 Gbps Ethernet + as of this writing. Forwarding at those speeds typically requires + support from Application-Specific Integrated Circuits (ASICs); + supporting more complex packet formats usually requires significantly + more gates than supporting simpler packet formats. So the pressure + to have a single simple option format has only increased in the past + decade, and is only going to increase in the future. + + When IPv6 was initially being developed, it was anticipated that the + availability of IP Security, in particular the Encapsulating Security + Payload (ESP) and the IP Authentication Header (AH), would obviate + the need for explicit packet Sensitivity Labels with IPv6 [RFC1825] + [RFC4301] [RFC4302] [RFC4303]. For MLS IPv6 deployments where the + use of AH or ESP is practical, the use of AH and/or ESP is + recommended. + + However, some applications (e.g., distributed file systems), most + often those not designed for use with Compartmented Mode Workstations + or other Multi-Level Secure (MLS) computers, multiplex different + transactions at different Sensitivity Levels and/or with different + privileges over a single IP communications session (e.g., with the + User Datagram Protocol). In order to maintain data Sensitivity + Labeling for such applications, to be able to implement routing and + Mandatory Access Control decisions in routers and guards on a per- + IP-packet basis, and for other reasons, there is a need to have a + mechanism for explicitly labeling the sensitivity information for + each IPv6 packet. + + Existing Layer 3 Virtual Private Network (VPN) technology can't solve + the set of issues addressed by this specification, for several + independent reasons. First, in a typical deployment, many labeled + packets will flow from an MLS End System through some set of networks + to a receiving MLS End System. The received per-packet label is used + by the receiving MLS End System to determine which Sensitivity Label + to associate with the user data carried in the packet. Existing + Layer 3 VPN specifications do not specify any mechanism to carry a + Sensitivity Label. Second, existing Layer 3 VPN technologies are not + implemented in any MLS End Systems, nor in typical single-level End + System operating systems, but instead typically are only implemented + in routers. Adding a Layer 3 VPN implementation to the networking + stack of an MLS End System would be a great deal more work than + adding this IPv6 option to that same MLS End System. Third, existing + Layer 3 VPN specifications do not support the use of Sensitivity + Labels to select a VPN to use in carrying a packet, which function is + + + +StJohns, et al. Informational [Page 5] + +RFC 5570 CALIPSO July 2009 + + + essential if one wanted to obviate this IPv6 option. Substantial new + standards development, along with significant new implementation work + in End Systems, would be required before a Layer 3 VPN approach to + these issues could be used. Developing such specifications, and then + implementing them in MLS systems, would need substantially greater + effort than simply implementing this IPv6 label option in an MLS End + System (or in a label-aware router). Further, both the MLS user + community and the MLS implementer community prefer the approach + defined in this specification. + +1.2. Intent and Applicability + + Nothing in this document applies to any system that does not claim to + implement this document. + + This document describes a generic way of labeling IPv6 datagrams to + reflect their particular sensitivity. Provision is made for + separating data based on domain of interpretation (e.g., an agency, a + country, an alliance, or a coalition), the relative sensitivity + (i.e., Sensitivity Levels), and need-to-know or formal access + programs (i.e., compartments or categories). + + A commonly used method of encoding Releasabilities as if they were + Compartments is also described. This usage does not have precisely + the same semantics as some formal Releasability policies, but + existing Multi-Level Secure operating systems do not contain + operating system support for Releasabilities as a separate concept + from compartments. The semantics for this sort of Releasability + encoding is close to the formal policies and has been deployed by a + number of different organizations for at least a decade now. + + In particular, the authors believe that this mechanism is suitable + for deployment in United Nations (UN) peace-keeping operations, in + North Atlantic Treaty Organisation (NATO) or other coalition + operations, in all current US Government MLS environments, and for + deployment in other similar commercial or governmental environments. + This option would not normally ever be visible in an IP packet on the + global public Internet. + + Because of the unusually severe adverse consequences (e.g., loss of + life, loss of very large sums of money) likely if a packet labeled + with this IPv6 Option were to escape onto the global public Internet, + organizations deploying this mechanism have unusually strong + incentives to configure security controls to prevent labeled packets + from ever appearing on the global public Internet. Indeed, a primary + purpose of this mechanism is to enable deployment of Mandatory Access + Controls for IPv6 packets. + + + + +StJohns, et al. Informational [Page 6] + +RFC 5570 CALIPSO July 2009 + + + However, to ensure interoperability of both End Systems and + Intermediate Systems within such a labeled deployment of IPv6, it is + essential to have an open specification for this option. + + This option is NOT designed to be an all-purpose label option and + specifically does not include support for generic Domain Type + Enforcement (DTE) mechanisms. If such a DTE label option is desired, + it ought to be separately specified and have its own (i.e., + different) IPv6 option number. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + +1.3. Deployment Examples + + Two deployment scenarios for IP packet Sensitivity Labels are most + common. We should first note that in typical deployments, all people + having access to an unencrypted link are cleared for all unencrypted + information traversing that link. Also, MLS system administrators + normally have previously been cleared to see all of the information + processed or stored by that MLS system. This specification does not + seek to eliminate all potential covert channels relating to this IPv6 + option. + + In the first scenario, all the connected nodes in a given private + internetwork are trusted systems that have Multi-Level Secure (MLS) + operating systems, such as Compartmented Mode Workstations (CMWs), + that support per-packet Sensitivity Labels [TCSEC] [TNI] [CMW] + [MLOSPP]. In this type of deployment, all IP packets carried within + the private internetwork are labeled, the IP routers apply mandatory + access controls (MAC) based on the packet labels and the sensitivity + ranges configured into the routers, all End Systems include packet + Sensitivity Labels in each originated packet, and all End Systems + apply Mandatory Access Controls to each received packet. Packets + received by a router or End System that have a Sensitivity Label + outside the permitted range for the receiving interface (or, in the + case of a router, outside the permitted range for either the incoming + or the outgoing interface) are dropped because they violate the MAC + policy. + + The second scenario is a variation of the first, where End Systems + with non-MLS operating systems are present on certain subnetworks of + the private internetwork. By definition, these non-MLS End Systems + operate in "system high" mode. In "system high" mode, all + information on the system is considered to have the sensitivity of + the most sensitive data on the system. If a system happens to + contain data only at one Sensitivity Level, this would also be an + + + +StJohns, et al. Informational [Page 7] + +RFC 5570 CALIPSO July 2009 + + + example of "system high" operation. In this scenario, each + subnetwork that contains any single-level End Systems has one single + "default" Sensitivity Label that applies to all single-level systems + on that IP subnetwork. Because those non-MLS End Systems are unable + to create packets containing Sensitivity Labels and are also unable + to apply MAC enforcement on received packets, security gateways + (which might, for example, be label-aware IP routers) connected to + such subnetworks need to insert sensitivity labels to packets + originated by the "system high" End Systems that are to be forwarded + off subnet. While the CALIPSO IPv6 option is marked as "ignore if + unrecognized", there are some deployed IPv6 End Systems with bugs. + Users can't fix these operating system bugs; some users need to be + able to integrate their existing IPv6 single-level End Systems to + have a useful overall MLS deployment. So, for packets destined for + IP subnetworks containing single-level End Systems, those last-hop + security gateways also apply Mandatory Access Controls (MAC) and then + either drop (if the packet is not permitted on that destination + subnet) exclusive-or remove Sensitivity Labels and forward packets + onto those "system high" subnetworks (if the packet is permitted on + that destination subnetwork). + + The authors are not aware of any existing MLS network deployments + that use a commercial Network Address Translation (NAT), Network + Address and Port Translation (NAPT), or any other commercial + "middlebox" device. For example, NAT boxes aren't used, unlike + practices in some segments of the public Internet. + + Similarly, the authors are not aware of any existing MLS network + deployments that use a commercial firewall. MLS networks normally + are both physically and electronically isolated from the global + Internet, so operators of MLS networks are not concerned about + external penetration (e.g., by worms, viruses, or the like). + Similarly, all users of the MLS network have been cleared using some + process specific to that organization, and hence are believe to be + trustworthy. In a typical deployment, all computers connected to the + MLS network are in a physically secure room or building (e.g., + protected by guards with guns). Electronic equipment that enters + such a space typically does not leave. Items such as USB memory + sticks are generally not permitted; in fact, often the USB ports on + MLS computers have been removed or otherwise made inoperable to + prevent people from adding or removing information. + + Also, for security reasons, content transformation in the middle of + an MLS network is widely considered undesirable, and so is not + typically undertaken. Hypothetically, if such content transformation + were undertaken, it would be performed by a certified MLS system that + has been suitably accredited for that particular purpose in that + particular deployment. + + + +StJohns, et al. Informational [Page 8] + +RFC 5570 CALIPSO July 2009 + + +2. Definitions + + This section defines several terms that are important to + understanding and correctly implementing this specification. Because + of historical variations in terminology in different user + communities, several terms have defined synonyms. + + The verb "dominate" is used in this document to describe comparison + of two Sensitivity Labels within a given Domain of Interpretation. + Sensitivity Label A dominates Sensitivity Label B if the Sensitivity + Level of A is greater than or equal to the Sensitivity Level of B AND + the Compartment Set of A is a superset (proper or improper) of the + Compartment Set of B. This term has been used in Multi-Level Secure + circles with this meaning for at least two decades. + +2.1. Domain of Interpretation + + A Domain of Interpretation (DOI) is a shorthand way of identifying + the use of a particular labeling, classification, and handling system + with respect to data, the computers and people who process it, and + the networks that carry it. The DOI policies, combined with a + particular Sensitivity Label (which is defined to have meaning within + that DOI) applied to a datum or collection of data, dictates which + systems, and ultimately which persons may receive that data. + + In other words, a label of "SECRET" by itself is not meaningful; one + also must know that the document or data belongs to some specific + organization (e.g., US Department of Defense (DoD), US Department of + Energy (DoE), UK Ministry of Defence (MoD), North Atlantic Treaty + Organisation (NATO), United Nations (UN), a specific commercial firm) + before one can decide on who is allowed to receive the data. + + A CALIPSO DOI is an opaque identifier that is used as a pointer to a + particular set of policies, which define the Sensitivity Levels and + Compartments present within the DOI, and by inference, to the "real- + world" (e.g., used on paper documents) equivalent labels (See + "Sensitivity Label" below). Registering or defining a set of real- + world security policies as a CALIPSO DOI results in a standard way of + labeling IP data originating from End Systems "accredited" or + "approved" to operate within that DOI and the constraints of those + security policies. For example, if one did this for the US + Department of Defense, one would list all the acceptable labels such + as "SECRET" and "TOP SECRET", and one would link the CALIPSO DOI to + the [DoD5200.28] and [DoD5200.1-R] documents, which define how to + mark and protect data with the US Department of Defense (DoD) + [DoD5200.28] [DoD5200.1-R]. + + + + + +StJohns, et al. Informational [Page 9] + +RFC 5570 CALIPSO July 2009 + + + The scope of the DOI is dependent on the organization creating it. + In some cases, the creator of the DOI might not be identical to a + given user of the DOI. For example, a multi-national organization + (e.g., NATO) might create a DOI, while a given member nation or + organization (e.g., UK MoD) might be using that multi-national DOI + (possibly along with other DOIs created by others) within its private + networks. To provide a different example, the United States might + establish a DOI with specific meanings, which correspond to the + normal way it labels classified documents and which would apply + primarily to the US DoD, but those specific meanings might also apply + to other associated agencies. A company or other organization also + might establish a DOI, which applies only to itself. + + NOTE WELL: A CALIPSO Domain of Interpretation is different from, and + is disjoint from, an Internet Security Association and Key Management + Protocol (ISAKMP) / Internet Key Exchange (IKE) Domain of + Interpretation. It is important not to confuse the two different + concepts, even though the terms might superficially appear to be + similar. + +2.2. Sensitivity Level + + A Sensitivity Level represents a mandatory separation of data based + on relative sensitivity. Sensitivity Levels ALWAYS have a specific + ordering within a DOI. Clearance to access a specific level of data + also implies access to all levels whose sensitivity is less than that + level. For example, if the A, B, and C are levels, and A is more + sensitive than B, which is in turn more sensitive than C (A > B > C), + access to data at the B level implies access to C as well. As an + example, common UK terms for a Sensitivity Level include (from low to + high) "UNCLASSIFIED", "RESTRICTED", "CONFIDENTIAL", "SECRET", and + "MOST SECRET". + + NOTE WELL: A Sensitivity Level is only one component of a Sensitivity + Label. It is important not to confuse the two terms. The term + "Sensitivity Level" has the same meaning as the term "Security + Level". + +2.3. Compartment + + A Compartment represents a mandatory segregation of data based on + formal information categories, formal information compartments, or + formal access programs for specific types of data. For example, a + small startup company creates "FINANCE" and "R&D" compartments to + protect data critical to its success -- only employees with a + specific need to know (e.g., the accountants and controller for + "FINANCE", specific engineers for "R&D") are given access to each + compartment. Each Compartment is separate and distinct. Access to + + + +StJohns, et al. Informational [Page 10] + +RFC 5570 CALIPSO July 2009 + + + one Compartment does not imply access to any other Compartment. Data + may be protected in multiple compartments (e.g., "FINANCE" data about + a new "R&D" project) at the same time, in which case access to ALL of + those compartments is required to access the data. Employees only + possessing clearance for a given Sensitivity Level (i.e., without + having clearance for any specific compartments at that Sensitivity + Level) do not have access to any data classified in any compartments + (e.g., "SECRET FINANCE" dominates "SECRET"). + + NOTE WELL: The term "category" has the same meaning as "compartment". + Some user communities have used the term "category", while other user + communities have used the term "compartment", but the terms have + identical meaning. + +2.4. Releasability + + A Releasability represents a mandatory segregation of data, based on + a formal decision to release information to others. + + Historically, most MLS deployments handled Releasability as if it + were an inverted Compartment. Strictly speaking, this provides + slightly different semantics and behavior than a paper marked with + the same Releasabilities would obtain, because the formal semantics + of Compartments are different from the formal semantics of + Releasability. The differences in behavior are discussed in more + detail later in this sub-section. + + In practice, for some years now some relatively large MLS deployments + have been encoding Releasabilities as if they were inverted + Compartments. The results have been tolerable and those deployments + are generally considered successful by their respective user + communities. This description is consistent with these MLS + deployments, so has significant operational experience behind it. + +2.4.1. Releasability Conceptual Example + + For example, two companies (ABC and XYZ) are engaging in a technical + alliance. ABC labels all information present within its enterprise + that is to be shared as part of the alliance as REL XYZ (e.g., + COMPANY CONFIDENTIAL REL XYZ). + + However, unlike the compartment example above, COMPANY CONFIDENTIAL + dominates COMPANY CONFIDENTIAL REL XYZ. This means that XYZ + employees granted a COMPANY CONFIDENTIAL REL XYZ clearance can only + access releasable material, while ABC employees with a COMPANY + CONFIDENTIAL clearance can access all information. + + + + + +StJohns, et al. Informational [Page 11] + +RFC 5570 CALIPSO July 2009 + + + If REL XYZ were managed as a compartment, then users granted a + COMPANY CONFIDENTIAL REL XYZ clearance would have access to all of + ABC's COMPANY CONFIDENTIAL material, which is undesirable. + + Releasabilities can be combined (e.g., COMPANY CONFIDENTIAL REL + XYZ/ABLE). In this case, users possessing a clearance of either + COMPANY CONFIDENTIAL, COMPANY CONFIDENTIAL REL XYZ, COMPANY + CONFIDENTIAL REL ABLE, or COMPANY CONFIDENTIAL REL XYZ/ABLE can + access this information. + +2.4.2. Releasability Encoding + + Individual bits in this option's Compartment Bitmap field MAY be used + to encode "releasability" information. The process for making this + work properly is described below. + + This scheme is carefully designed so that intermediate systems need + not know whether a given bit in the Compartment Bitmap field + represents a compartment or a Releasability. All that an + Intermediate System needs to do is apply the usual comparison + (described in Section 2.5.1 and 2.5.2) to determine whether or not a + packet's label is in-range for an interface. This simplifies both + the configuration and implementation of a label-aware Intermediate + System. + + Unlike bits that represent compartments, bits that represent a + Releasability are "active low". + + If a given Releasability bit in the Compartment Bitmap field is "0", + the information may be released to that community. If the + compartment bit is "1", the information may not be released to that + community. + + Only administrative interfaces used to present or construct binary + labels in human-readable form need to understand the distinction + between Releasability bits and non-Releasability bits. Implementers + are encouraged to describe Releasability encoding in the + documentation supplied to users of systems that implement this + specification. + +2.4.2. Releasability Encoding Examples + + For objects, such as IP packets, let bits 0-3 of the Compartment + Bitmap field be dedicated to controlling Releasability to the + communities A, B, C, and D, respectively. + + + + + + +StJohns, et al. Informational [Page 12] + +RFC 5570 CALIPSO July 2009 + + + Example 1: Not releasable to any community: + This is usually how handling restrictions + such as "No Foreigners (NO FORN)" are encoded. + ABCD == 1111 + + Example 2: Releasable only to community A and community C: + ABCD == 0101 + + Example 3: Releasable only to community B: + ABCD == 1011 + + Example 4: Releasable to communities A,B,C, & D: + ABCD == 0000 + + For subjects, such as clearances of users, the same bit encodings are + used for Releasabilities as are used for objects (see above). + + Example 1: Clearance not belonging to any community: + This user can see information belonging + to any Releasability community, since s/he + is not in any Releasability community. + ABCD = 1111 + + Example 2: Clearance belonging to community A and C: + This user can only see Releasable AC information, + and cannot see Releasable A information. + ABCD == 0101 + + Example 3: Clearance belonging to community B: + This user can only see Releasable B information. + ABCD == 1011 + + Example 4: Clearance belongs to communities A,B,C, and D: + This user can only see Releasable ABCD information, + and cannot (for example) see Releasable AB or + Releasable BD information. + ABCD == 0000 + + Now we consider example comparisons for an IP router that is + enforcing MAC by using CALIPSO labels on some interface: + + Let the MINIMUM label for that router interface be: + CONFIDENTIAL RELEASABLE AC + + Therefore, this interface has a minimum Releasability of 0101. + + Let the MAXIMUM label for that router interface be: + TOP SECRET NOT RELEASABLE + + + +StJohns, et al. Informational [Page 13] + +RFC 5570 CALIPSO July 2009 + + + Therefore, this interface has a maximum Releasability of 1111. + + For the range comparisons, the bit values for the current packet need + to be "greater than or equal to" the minimum value for the interface + AND also the bit values for the current packet need to be "less than + or equal to" the maximum value for the interface, just as with + compartment comparisons. The inverted encoding scheme outlined above + ensures that the proper results occur. + + Consider a packet with label CONFIDENTIAL RELEASABLE AC: + 1) Sensitivity Level comparison: + (CONFIDENTIAL <= CONFIDENTIAL <= TOP SECRET) + so the Sensitivity Level is "within range" for that + router interface. + 2) Compartment bitmap comparison: + The test is [(0101 >= 0101) AND (0101 <= 1111)], + so the Compartment bitmap is "within range" for + that router interface. + + Consider a packet with label CONFIDENTIAL RELEASABLE ABCD: + 1) Sensitivity Label comparison: + (CONFIDENTIAL <= CONFIDENTIAL <= TOP SECRET) + so the Sensitivity Level is "within range" for that + router interface. + 2) Compartment bitmap comparison: + The test is [(0000 >= 0101) AND (0000 <= 1111)], + so the Compartment Bitmap is NOT "within range" for + that router interface. + + Consider a packet with label SECRET NOT RELEASABLE: + 1) Sensitivity Label comparison: + (CONFIDENTIAL <= SECRET <= TOP SECRET) + so the Sensitivity Level is "within range" for that + router interface. + 2) Compartment bitmap comparison: + The test is [(1111 >= 0101) AND (1111 <= 1111)], + so the Compartment bitmap is "within range" for that + router interface. + +2.4.3. Limitations of This Releasability Approach + + For example, if one considers a person "Jane Doe" who is a member of + two Releasability communities (A and also B), she is permitted to see + a paper document that is marked "Releasable A", "Releasable B", or + "Releasable AB" -- provided that her Clearance and Compartments are + in-range for the Sensitivity Level and Compartments (respectively) of + the paper document. + + + + +StJohns, et al. Informational [Page 14] + +RFC 5570 CALIPSO July 2009 + + + Now, let us consider an equivalent electronic example implemented and + deployed as outlined above. In this, we consider two Releasability + communities (A and B). Those bits will be set to 00 for the + electronic user ID used by user "Jane Doe". + + However, the electronic Releasability approach above will ONLY permit + her to see information marked as "Releasable AB". The above + electronic approach will deny her the ability to read documents + marked "Releasable A" or "Releasable B". This is because "Releasable + A" is encoded as "01", "Releasable B" is encoded as "10", while + "Releasable AB" is encoded as "00". If one looks at the compartment + dominance computation, "00" dominates "00", but "00" does NOT + dominate "01", and "00" also does NOT dominate "10". + + Users report that the current situation is tolerable, but not ideal. + Users also report that various operational complexities can arise + from this approach. + + Several deployments work around this limitation by assigning an + electronic user several parallel clearances. Referring to the + (fictitious) example above, the user "Jane Doe" might have one + clearance without any Releasability, another separate clearance with + Releasability A, and a third separate clearance with Releasability B. + While this has implications (e.g., a need to be able to associate + multiple separate parallel clearances with a single user ID) for + implementers of MLS systems, this specification cannot (and does not) + levy any requirements that an implementation be able to associate + multiple clearances with each given user ID because that level of + detail is beyond the scope of an IP labeling option. + + Separating the Releasability bits into a separate bitmap within the + CALIPSO option was seriously considered. However, existing MLS + implementations lack operating system support for Releasability. So + even if CALIPSO had a separate bitmap field, those bits would have + been mapped to Compartment bits by the sending/receiving nodes, so + the operational results would not have been different than those + described here. + + Several MLS network deployments connect MLS End Systems both to a + labeled national network and also to a labeled coalition network + simultaneously. Depending on whether the data is labeled according + to national rules or according to coalition rules, the set of + Releasability marks will vary. Some choices are likely to lead to + more (or fewer) incorrect Releasability decisions (although the + results of the above Releasability encodings are believed to be + fail-safe). + + + + + +StJohns, et al. Informational [Page 15] + +RFC 5570 CALIPSO July 2009 + + +2.5. Sensitivity Label + + A Sensitivity Label is a quadruple consisting of a DOI, a Sensitivity + Level, a Compartment Set, and a Releasability Set. The Compartment + Set may be the empty set if and only if no compartments apply. A + Releasability Set may be the empty set if and only if no + Releasabilities apply. A DOI used within an End System may be + implicit or explicit depending on its use. CALIPSO Sensitivity + Labels always have an explicit DOI. A CALIPSO Sensitivity Label + consists of a Sensitivity Label in a particular format (defined + below). A CALIPSO Sensitivity Label ALWAYS contains an explicit DOI + value. In a CALIPSO Sensitivity Label, the Compartment Bitmap field + is used to encode both the logical Compartment Set and also the + logical Releasability Set. + + End Systems using operating systems with MLS capabilities that also + implement IPv6 normally will be able to include CALIPSO labels in + packets they originate and will be able to enforce MAC policy on the + CALIPSO labels in any packets they receive. + + End Systems using an operating system that lacks Multi-Level Secure + capabilities operate in "system high" mode. This means that all data + on the system is considered to have the Sensitivity Label of the most + sensitive data on the system. Such a system normally is neither + capable of including CALIPSO labels in packets that it originates nor + of enforcing CALIPSO labels in packets that it receives. + + NOTE WELL: The term "Security Marking" has the same meaning as + "Sensitivity Label". + +2.5.1. Sensitivity Label Comparison + + Two Sensitivity Labels (A and B) can be compared. Indeed, + Sensitivity Labels exist primarily so they can be compared as part of + a Mandatory Access Control decision. Comparison is critical to + determining if a subject (a person, network, etc.) operating at one + Sensitivity Label (A) should be allowed to access an object (file, + packet, route, etc.) classified at another Sensitivity Label (B). + The comparison of two labels (A and B) can return one (and only one) + of the following results: + + 1) A dominates B (e.g., A=SECRET, B=UNCLASSIFIED); + A can read B, + + 2) B dominates A (e.g., A=UNCLASSIFIED, B=SECRET); + A cannot access B, + + + + + +StJohns, et al. Informational [Page 16] + +RFC 5570 CALIPSO July 2009 + + + 3) A equals B (e.g., A=SECRET, B=SECRET); + A can read/write B, + + exclusive-or + + 4) A is incomparable to B (e.g., A=SECRET R&D, B=SECRET FINANCE); + A cannot access B, and also, B cannot access A. + + By definition, if A and B are members of different DOIs, the result + of comparison is always incomparable. It is possible to overcome + this if and only if A and/or B can be translated into some common + DOI, such that the labels are then interpretable. + +2.5.2. Sensitivity Label Range + + A range is a pair of Sensitivity Labels, which indicate both a + minimum and a maximum acceptable Sensitivity Label for objects + compared against it. A range is usually expressed as "<minimum> : + <maximum>" and always has the property that the maximum Sensitivity + Label dominates the minimum Sensitivity Label. In turn, this + requires that the two Sensitivity Labels MUST be comparable. + + A range where <minimum> equals <maximum> may be expressed simply as + "<minimum>"; in this case, the only acceptable Sensitivity Label is + <minimum>. + +2.6. Import + + The act of receiving a datagram and translating the CALIPSO + Sensitivity Label of that packet into the appropriate internal (i.e., + end-system-specific) Sensitivity Label. + +2.7. Export + + The act of selecting an appropriate DOI for an outbound datagram, + translating the internal (end-system-specific) label into an CALIPSO + Sensitivity Label based on that DOI, and sending the datagram. The + selection of the appropriate DOI may be based on many factors + including, but not necessarily limited to: + + + + + + + + + + + + +StJohns, et al. Informational [Page 17] + +RFC 5570 CALIPSO July 2009 + + + Source Port + Destination Port + Transport Protocol + Application Protocol + Application Information + End System + Subnetwork + Network + Sending Interface + System Implicit/Default DOI + + Regardless of the DOI selected, the Sensitivity Label of the outbound + datagram must be consistent with the security policy monitor of the + originating system and also with the DOI definition used by all other + devices cognizant of that DOI. + +2.8. End System + + An End System is a host or router from which a datagram originates or + to which a datagram is ultimately delivered. + + The IPv6 community has defined the term Node to include both + Intermediate Systems and End Systems [RFC2460]. + +2.9. Intermediate System + + An Intermediate System (IS) is a node that receives and transmits a + particular datagram without being either the source or destination of + that datagram. An Intermediate System might also be called a + "gateway", "guard", or "router" in some user communities. + + So an IPv6 router is one example of an Intermediate System. A + firewall or security guard device that applies security policies and + forwards IPv6 packets that comply with those security policies is + another example of an Intermediate System. + + An Intermediate System may handle ("forward") a datagram destined for + some other node without necessarily importing or exporting the + datagram to/from itself. + + NOTE WELL: Any given system can be both an End System and an + Intermediate System -- which role the system assumes at any given + time depends on the address(es) of the datagram being considered and + the address(es) associated with that system. + + + + + + + +StJohns, et al. Informational [Page 18] + +RFC 5570 CALIPSO July 2009 + + +2.10. System Security Policy + + A System Security Policy (SSP) consists of a Sensitivity Label and + the organizational security policies associated with content labeled + with a given security policy. The SSP acts as a bridge between how + the organization's Mandatory Access Control (MAC) policy is stated + and managed and how the network implements that policy. Typically, + the SSP is a document created by the Information Systems Security + Officer (ISSO) of the site or organization covered by that SSP. + +3. Architecture + + This document describes a convention for labeling an IPv6 datagram + within a particular system security policy. The labels are designed + for use within a Mandatory Access Control (MAC) system. A real-world + example is the security classification system in use within the UK + Government. Some data held by the government is "classified", and is + therefore restricted by law to those people who have the appropriate + "clearances". + + Commercial examples of information labeling schemes also exist + [CW87]. For example, one global electrical equipment company has a + formal security policy that defines six different Sensitivity Levels + for its internal data, ranging from "Class 1" to "Class 6" + information. Some financial institutions use multiple compartments + to restrict access to certain information (e.g., "mergers and + acquisitions", "trading") to those working directly on those projects + and to deny access to other groups within the company (e.g., equity + trading). A CALIPSO Sensitivity Label is the network instantiation + of a particular information security policy, and the policy's related + labels, classifications, compartments, and Releasabilities. + + Some years ago, the Mandatory Access Control (MAC) policy for US + Government classified information was specified formally in + mathematical notation [BL73]. As it happens, many other + organizations or governments have the same basic Mandatory Access + Control (MAC) policy for information with differing ("vertical") + Sensitivity Levels. This document builds upon the formal definitions + of Bell-LaPadula [BL73]. There are two basic principles: "no write + down" and "no read up". + + The first rule means that an entity having minimum Sensitivity Level + X must not be able to write information that is marked with a + Sensitivity Level below X. The second rule means that an entity + having maximum Sensitivity Level X must not be able to read + information having a Sensitivity Level above X. In a normal + deployment, information downgrading ("write down") must not occur + automatically, and is permitted if and only if a person with + + + +StJohns, et al. Informational [Page 19] + +RFC 5570 CALIPSO July 2009 + + + appropriate "downgrade" privilege manually verifies the information + is permitted to be downgraded before s/he manually relabels (i.e., + "downgrades") the information. Subsequent to the original work by + Bell and LaPadula in this area, this formal model was extended to + also support ("horizontal") Compartments of information. + + This document extends Bell-LaPadula to accommodate the notion of + separate Domains of Interpretation (DOI) [BL73]. Each DOI + constitutes a single comparable domain of Sensitivity Labels as + stated by Bell-LaPadula. Sensitivity Labels from different domains + cannot be directly compared using Bell-LaPadula semantics. + + This document is focused on providing specifications for (1) encoding + Sensitivity Labels in packets, and (2) how such Sensitivity Labels + are to be interpreted and enforced at the IP layer. This document + recognizes that there are several kinds of application processing + that occur above the IP layer that significantly impact end-to-end + system security policy enforcement, but are out of scope for this + document. In particular, how the network labeling policy is enforced + within processing in an End System is critical, but is beyond the + scope of a network (IP) layer Sensitivity Label encoding standard. + Other specifications exist, which discuss such details [TCSEC] [TNI] + [CMW] [ISO-15408] [CC] [MLOSPP]. + + This specification does not preclude an End System capable of + providing labeled packets across some range of Sensitivity Labels. A + Compartmented Mode Workstation (CMW) is an example of such an End + System [CMW]. This is useful if the End System is capable of, and + accredited to, separate processing across some range of Sensitivity + Labels. Such a node would have a range associated with it within the + network interface connecting the node to the network. As an example, + an End System has the range "SECRET: TOP SECRET" associated with it + in the Intermediate System to which the node is attached. SECRET + processing on the node is allowed to traverse the network to other + "SECRET : SECRET" segments of the network, ultimately to a "SECRET : + SECRET" node. Likewise, TOP SECRET processing on the node is allowed + to traverse a network through "TOP SECRET: TOP SECRET" segments, + ultimately to some "TOP SECRET: TOP SECRET" node. The node in this + case can allow a user on this node to access SECRET and TOP SECRET + resources, provided the user holds the appropriate clearances and has + been correctly configured. + + With respect to a given network, each distinct Sensitivity Label + represents a separate virtual network, which shares the same physical + network. There are rules for moving information between the various + virtual networks. The model we use within this document is based on + + + + + +StJohns, et al. Informational [Page 20] + +RFC 5570 CALIPSO July 2009 + + + the Bell-LaPadula model, but is extended to cover the concept of + differing Domains of Interpretation. Nodes that implement this + protocol MUST enforce this mandatory separation of data. + + CALIPSO provides for both horizontal ("Compartment") and vertical + ("Sensitivity Level") separation of information, as well as + separation based on DOI. The basic rule is that data MUST NOT be + delivered to a user or system that is not approved to receive it. + + NOTE WELL: Wherever we say "not approved", we also mean "not + cleared", "not certified", and/or "not accredited" as applicable in + one's operational community. + + This specification does not enable AUTOMATIC relabeling of + information, within a DOI or to a different DOI. That is, neither + automatic "upgrading" nor automatic "downgrading" of information are + enabled by this specification. Local security policies might allow + some limited downgrading, but this normally requires the intervention + of some human entity and is usually done within an End System with + respect to the internal Sensitivity Label, rather than on a network + or in an intermediate-system (e.g., router, guard). Automatic + downgrading is not suggested operational practice; further discussion + of downgrading is outside the scope of this protocol specification. + + Implementers of this specification MUST NOT permit automatic + upgrading or downgrading of information in the default configuration + of their implementation. Implementers MAY add a configuration knob + that would permit a System Security Officer holding appropriate + privilege to enable automatic upgrading or downgrading of + information. If an implementation supports such a knob, the + existence of the configuration knob must be clearly documented and + the default knob setting MUST be that automatic upgrading or + downgrading is DISABLED. Automatic information upgrading and + downgrading is not recommended operational practice. + + Many existing MLS deployments already use (and operationally need to + use) more than one DOI concurrently. User feedback from early + versions of this specification indicates that it is common at present + for a single network link (i.e., IP subnetwork) to carry traffic for + both a particular coalition (or joint-venture) activity and also for + the government (or other organization) that owns and operates that + particular network link. On such a link, one CALIPSO DOI would + typically be used for the coalition traffic and some different + CALIPSO DOI would typically be used for non-coalition traffic (i.e., + traffic that is specific to the government that owns and operates + that particular network link). For example, a UK military network + that is part of a NATO deployment might have and use a UK MoD DOI for + + + + +StJohns, et al. Informational [Page 21] + +RFC 5570 CALIPSO July 2009 + + + information originating/terminating on another UK system, while + concurrently using a different NATO DOI for information + originating/terminating on a non-UK NATO system. + + Additionally, operational experience with existing MLS systems has + shown that if a system only supports a single DOI at a given time, + then it is impossible for a deployment to migrate from using one DOI + value to a different DOI value in a smooth, lossless, zero downtime, + manner. + + Therefore, a node that implements this specification MUST be able to + support at least two CALIPSO DOIs concurrently. Support for more + than two concurrent CALIPSO DOIs is encouraged. This requirement to + support at least two CALIPSO DOIs concurrently is not necessarily an + implementation constraint upon MLS operating system internals that + are unrelated to the network. + + Indeed, use of multiple DOIs is also operationally useful in + deployments having a single administration that also have very large + numbers of compartments. For example, such a deployment might have + one set of related compartments in one CALIPSO DOI and a different + set of compartments in a different CALIPSO DOI. Some compartments + might be present in both DOIs, possibly at different bit positions of + the compartment bitmap in different DOIs. While this might make some + implementations more complex, it might also be used to reduce the + typical size of the IPv6 CALIPSO option in data packets. + + Moving information between any two DOIs is permitted -- if and only + if -- the owners of the DOIs: + + 1) Agree to the exchange, + + AND + + 2) Publish a document with a table of equivalencies that + maps the CALIPSO values of one DOI into the other + and make that document available to security + administrators of MLS systems within the deployment + scope of those two DOIs. + + The owners of two DOIs may choose to permit the exchange on or + between any of their systems, or may restrict exchange to a small + subset of the systems they own/accredit. One-way agreements are + permissible, as are agreements that are a subset of the full table of + equivalences. Actual administration of inter-DOI agreements is + outside the scope of this document. + + + + + +StJohns, et al. Informational [Page 22] + +RFC 5570 CALIPSO July 2009 + + + When data leaves an End System it is exported to the network, and + marked with a particular DOI, Sensitivity Level, and Compartment Set. + (This triple is collectively termed a Sensitivity Label.) This + Sensitivity Label is derived from the internal Sensitivity Label (the + end-system-specific implementation of a given Sensitivity Label), and + the Export DOI. Selection of the Export DOI is described in detail + in Section 6.2.1. + + When data arrives at an End System, it is imported from the network + to the End System. The data from the datagram takes on an internal + Sensitivity Label based on the Sensitivity Label contained in the + datagram. This assumes the datagram is marked with a recognizable + DOI, there is a corresponding internal Sensitivity Label equivalent + to the CALIPSO Sensitivity Label, and the datagram is "within range" + for the receiving logical interface. + + A node has one or more physical interfaces. Each physical interface + is associated with a physical network segment used to connect the + node, router, LAN, or WAN. One or more Sensitivity Label ranges are + associated with each physical network interface. Sensitivity Label + ranges from multiple DOIs must be enumerated separately. Multiple + ranges from the same DOI are permissible. + + Each node also might have one or more logical network interfaces. + + A given logical network interface might be associated with more than + one physical interface. For example, a switch/router might have two + separate Ethernet ports that are associated with the same Virtual + Local Area Network (VLAN), where that one VLAN mapped to a single + IPv6 subnetwork [IEEE802.1Q]. + + A given physical network interface might have more than one + associated logical interface. For example, a node might have 2 + logical network interfaces, each for a different IP subnetwork + ("super-netting"), on a single physical network interface (e.g., on a + single Network Interface Card of a personal computer). + Alternatively, also as an example, a single Ethernet port might have + multiple Virtual LANs (VLANs) associated with it, where each VLAN + could be a separate logical network interface. + + One or more Sensitivity Label ranges are associated with each logical + network interface. Sensitivity Label ranges from multiple DOIs must + be enumerated separately. Multiple ranges from the same DOI are + permissible. Each range associated with a logical interface must + fall within a range separately defined for the corresponding physical + interface. + + + + + +StJohns, et al. Informational [Page 23] + +RFC 5570 CALIPSO July 2009 + + + There is specific user interest in having IPv6 routers that can apply + per-logical-interface mandatory access controls based on the contents + of the CALIPSO Sensitivity Labels in IPv6 packets. The authors note + that since the early 1990s, and continuing through today, some + commercial IPv4 router products provide MAC enforcement for the RFC + 1108 IP Security Option. + + In transit, a datagram is handled based on its CALIPSO Sensitivity + Label, and is usually neither imported to or exported from the + various Intermediate Systems it transits. There also is the concept + of "CALIPSO Gateways", which import data from one DOI and export it + to another DOI such that the effective Sensitivity Label is NOT + changed, but is merely represented using a different DOI. In other + words, such devices would be trustworthy, trusted, and authorized to + provide on-the-fly relabeling of packets at the boundaries between + complete systems of End Systems within a single DOI. Typically, such + systems require specific certification(s) and accreditation(s) before + deployment or use. + +4. Defaults + + This Section describes the default behavior of CALIPSO-compliant End + Systems and Intermediate Systems. Implementers MAY implement + configuration knobs to vary from this behavior, provided that the + default behavior (i.e., if the system administrator does not + explicitly change the configured behavior of the device) is as + described below. If implementers choose to implement such + configuration knobs, the configuration parameters and the behaviors + that they enable and disable SHOULD be documented for the benefit of + system administrators of those devices. + + Each Intermediate System or End System is responsible for properly + interpreting and enforcing the MLS Mandatory Access Control policy. + Practically, this means that each node must evaluate the label on the + inbound packet, ensure that this Sensitivity Label is valid (i.e., + within range) for the receiving interface, and at a minimum only + forward the packet to an interface and node where the Sensitivity + Label of the packet falls within the assigned range of that node's + receiving interface. + + Packets with an invalid (e.g., out-of-range) Sensitivity Label for + the receiving interface MUST be dropped upon receipt. A Sensitivity + Label is valid if and only if the Sensitivity Label falls within the + range assigned to the transmitting interface on the sending system + and within the range assigned to the receiving interface on the + receiving system. These rules also need to be applied by + Intermediate Systems on each hop that a CALIPSO-labeled packet + traverses, not merely at the end points of a labeled IP session. As + + + +StJohns, et al. Informational [Page 24] + +RFC 5570 CALIPSO July 2009 + + + an example, it is a violation of the default MLS MAC policy for a + packet with a higher Sensitivity Level (e.g., "MOST SECRET") to + transit a link whose maximum Sensitivity Level is less than that + first Sensitivity Level (e.g., "SECRET"). + + If an unlabeled packet is received from a node that does not support + CALIPSO Sensitivity Labels (i.e., unable to assign Sensitivity Labels + itself) and the packet is destined for a node that supports CALIPSO + Sensitivity Labels, then the receiving intermediate system needs to + insert a Sensitivity Label. This Sensitivity Label MUST be equal to + the maximum Sensitivity Label assigned to the originating node if and + only if that is known to the receiving node. If this receiving + Intermediate System does not know which Sensitivity Label is assigned + to the originating node, then the maximum Sensitivity Label of the + interface that received the unlabeled packet MUST be inserted. + + NOTE WELL: The procedure in the preceding paragraph is NOT a label + upgrade -- because it is not changing an existing label; instead, it + is simply inserting a Sensitivity Label that has the only "safe" + value, given that no other information is known to the receiving + node. In large-scale deployments, it is very unlikely that a given + node will have any authoritative a priori information about the + security configuration of any node that is NOT on a directly attached + link. + + If a packet is to be sent to a node that is defined to not be + Sensitivity Label aware, from a node that is label aware, then the + Sensitivity Label MAY be removed upon transmission if and only if + local security policy explicitly permits this. The originating node + is still responsible for ensuring that the Sensitivity Label on the + packet falls within the Sensitivity Label range associated with the + receiving node. If the packet will traverse more than one subnetwork + between origin and destination, and those subnetworks are labeled, + then the packet SHOULD normally contain a Sensitivity Label so that + the packet will be able to reach the destination and the Intermediate + Systems will be able to apply the requisite MAC policy to the packet. + + NOTE WELL: In some IPv4 MLS network deployments that exist as of the + publication date, if a first-hop router receives an unlabeled IPv4 + packet, the router inserts an appropriate Sensitivity Label into that + IPv4 packet, in the manner described above. So sending a packet + without a label across a multiple subnetwork path to a destination + does not guarantee that the packet will arrive containing no + Sensitivity Label. + + + + + + + +StJohns, et al. Informational [Page 25] + +RFC 5570 CALIPSO July 2009 + + +5. Format + + This section describes the format of the CALIPSO option for use with + IPv6 datagrams. CALIPSO is an IPv6 Hop-By-Hop Option, rather than an + IPv6 Destination Option, to ensure that a security gateway or router + can apply access controls to IPv6 packets based on the CALIPSO label + carried by the packet. + + An IPv6 datagram that has not been tunneled contains at most one + CALIPSO label. In the special case where (1) a labeled IPv6 datagram + is tunneled inside another labeled IPv6 datagram AND (2) IP Security + is NOT providing confidentiality protection for the inner packet, the + outer CALIPSO Sensitivity Label must have the same meaning as the + inner CALIPSO Sensitivity Label. For example, it would be invalid to + encapsulate an unencrypted IPv6 packet with a Sensitivity Label of + (SECRET, no compartments) inside a packet with an outer Sensitivity + Label of (UNCLASSIFIED). + + If the inner IPv6 packet is tunneled inside the Encapsulating + Security Payload (ESP) and confidentiality is being provided to that + inner packet, then the outer packet MAY have a different CALIPSO + Sensitivity Label -- subject to local security policy. + + As a general principle, the meaning of the Sensitivity Labels must be + identical when one has a labeled cleartext IP packet that has been + encapsulated (tunneled) inside another labeled IP packet. This is + true whether one has IPv6 tunneled in IPv6, IPv4 tunneled in IPv6, or + IPv6 tunneled in IPv4. This is essential to maintaining proper + Mandatory Access Controls. + + This option's syntax has been designed with intermediate systems in + mind. It is now common for an MLS network deployment to contain an + Intermediate Systems acting as a guard (sometimes several acting as + guards). Such a guard device needs to be able to very rapidly parse + the Sensitivity Label in each packet, apply ingress interface MAC + policy, forward the packet while aware of the packet's Sensitivity + Label, and then apply egress interface MAC policy. + + At least one prior IP Sensitivity Label option [FIPS-188] used a + syntax that was unduly complex to parse in IP routers, hence that + option never was implemented in an IP router. So there is a + deliberate effort here to choose a streamlined option syntax that is + easy to parse, encode, and implement in more general terms. + + + + + + + + +StJohns, et al. Informational [Page 26] + +RFC 5570 CALIPSO July 2009 + + +5.1. Option Format + + The CALIPSO option is an IPv6 Hop-by-Hop Option and is designed to + comply with IPv6 optional header rules. Following the nomenclature + of Section 4.2 of RFC 2460, the Option Type field of this option must + have 4n+2 alignment [RFC2460]. + + The CALIPSO Option Data MUST NOT change en route, except when (1) + "DOI translation" is performed by a trusted Intermediate System, (2) + a CALIPSO Option is inserted by a trusted Intermediate System upon + receipt of an unlabeled IPv6 packet, or (3) a CALIPSO Option is + removed by a last-hop trusted Intermediate System immediately prior + to forwarding the packet to a destination node that does not + implement support for CALIPSO labels. The details of these three + exceptions are described elsewhere in this document. + + If the option type is not recognized by a node examining the packet, + the option is ignored. However, all implementations of this + specification MUST be able to recognize this option and therefore + MUST NOT ignore this option if it is present in an IPv6 packet. + + This option is designed to comply with the IPv6 optional header rules + [RFC2460]. The CALIPSO option is always carried in a Hop-By-Hop + Option Header, never in any other part of an IPv6 packet. This rule + exists because IPv6 routers need to be able to see the CALIPSO label + so that those routers are able to apply MLS Mandatory Access Controls + to those packets. + + The diagram below shows the CALIPSO option along with the required + (first) two fields of the Hop-By-Hop Option Header that envelops the + CALIPSO option. The design of the CALIPSO option is arranged to + avoid the need for 16 bits of padding between the HDR EXT LEN field + and the start of the CALIPSO option. Also, the CALIPSO Domain of + Interpretation field is laid out so that it normally will be 32-bit + aligned. + + ------------------------------------------------------------ + | Next Header | Hdr Ext Len | Option Type | Option Length| + +-------------+---------------+-------------+--------------+ + | CALIPSO Domain of Interpretation | + +-------------+---------------+-------------+--------------+ + | Cmpt Length | Sens Level | Checksum (CRC-16) | + +-------------+---------------+-------------+--------------+ + | Compartment Bitmap (Optional; variable length) | + +-------------+---------------+-------------+--------------+ + + + + + + +StJohns, et al. Informational [Page 27] + +RFC 5570 CALIPSO July 2009 + + +5.1.1. Option Type Field + + This field contains an unsigned 8-bit value. Its value is 00000111 + (binary). + + Nodes that do not recognize this option should ignore it. In many + cases, not all routers in a given MLS deployment will contain support + for this CALIPSO option. For interoperability reasons, it is + important that routers that do not support the CALIPSO forward this + packet normally, even though those routers do not recognize the + CALIPSO option. + + In the event the IPv6 packet is fragmented, this option MUST be + copied on fragmentation. Virtually all users want the choice of + using the IP Authentication Header (a) to authenticate this option + and (b) to bind this option to the associated IPv6 packet. + +5.1.2. Option Length Field + + This field contains an unsigned integer one octet in size. Its + minimum value is eight (e.g., when the Compartment Bitmap field is + absent). This field specifies the Length of the option data field of + this option in octets. The Option Type and Option Length fields are + not included in the length calculation. + +5.1.3. Compartment Length Field + + This field contains an unsigned 8-bit integer. The field specifies + the size of the Compartment Bitmap field in 32-bit words. The + minimum value is zero, which is used only when the information in + this packet is not in any compartment. (In that situation, the + CALIPSO Sensitivity Label has no need for a Compartment Bitmap). + Note that measuring the Compartment Bitmap field length in 32-bit + words permits the header to be 64-bit aligned, following IPv6 + guidelines, without wasting 32 bits. Using 64-bit words for the size + of the Compartment Bitmap field length would force 32 bits of padding + with every option in order to maintain 64-bit alignment; wasting + those bits in every CALIPSO option is undesirable. + + Because this specification represents Releasabilities on the wire as + inverted Compartments, the size of the Compartment Bitmap field needs + to be large enough to hold not only the set of logical Compartments, + but instead to hold both the set of logical Compartments and the set + of logical Releasabilities. + + Recall that the overall length of this option MUST follow IPv6 + optional header rules, including the word alignment rules. This has + implications for the valid values for this field. In some cases, the + + + +StJohns, et al. Informational [Page 28] + +RFC 5570 CALIPSO July 2009 + + + length of the Compartment Bitmap field might need to exceed the + number of bits required to hold the sum of the logical Compartments + and the logical Releasabilities, in order to comply with IPv6 + alignment rules. + +5.1.5. Domain of Interpretation Field + + This field contains an unsigned 32-bit integer. IANA maintains a + registry with assignments of the DOI values used in this field. The + DOI identifies the rules under which this datagram must be handled + and protected. The NULL DOI, in which this field is all zeros, MUST + NOT appear in any IPv6 packet on any network. + + NOTE WELL: The Domain Of Interpretation value where all 4 octets + contain zero is defined to be the NULL DOI. The NULL DOI has no + compartments and has a single level whose value and CALIPSO + representation are each zero. The NULL DOI MUST NOT ever appear on + the wire. If a packet is received containing the NULL DOI, that + packet MUST be dropped and the event SHOULD be logged as a security + fault. + +5.1.6. Sensitivity Level Field + + This contains an unsigned 8-bit value. This field contains an opaque + octet whose value indicates the relative sensitivity of the data + contained in this datagram in the context of the indicated DOI. The + values of this field MUST be ordered, with 00000000 being the lowest + Sensitivity Level and 11111111 being the highest Sensitivity Level. + + However, in a typical deployment, not all 256 Sensitivity Levels will + be in use. So the set of valid Sensitivity Level values depends upon + the CALIPSO DOI in use. This sensitivity ordering rule is necessary + so that Intermediate Systems (e.g., routers or MLS guards) will be + able to apply MAC policy with minimal per-packet computation and + minimal configuration. + +5.1.7. 16-Bit Checksum Field + + This 16-bit field contains the a CRC-16 checksum as defined in + Appendix C of RFC 1662 [RFC1662]. The checksum is calculated over + the entire CALIPSO option in this packet, including option header, + zeroed-out checksum field, option contents, and any required padding + zero bits. + + The checksum MUST always be computed on transmission and MUST always + be verified on reception. This checksum only provides protection + against accidental corruption of the CALIPSO option in cases where + + + + +StJohns, et al. Informational [Page 29] + +RFC 5570 CALIPSO July 2009 + + + neither the underlying medium nor other mechanisms, such as the IP + Authentication Header (AH), are available to protect the integrity of + this option. + + Note that the checksum field is always required, even when other + integrity protection mechanisms (e.g., AH) are used. This method is + chosen for its reliability and simplicity in both hardware and + software implementations, and because many implementations already + support this checksum due to its existing use in various IETF + specifications. + +5.1.8. Compartment Bitmap Field + + This contains a variable number of 64-bit words. Each bit represents + one compartment within the DOI. Each "1" bit within an octet in the + Compartment Bitmap field represents a separate compartment under + whose rules the data in this packet must be protected. Hence, each + "0" bit indicates that the compartment corresponding with that bit is + not applicable to the data in this packet. The assignment of + identity to individual bits within a Compartment Bitmap for a given + DOI is left to the owner of that DOI. + + This specification represents a Releasability on the wire as if it + were an inverted Compartment. So the Compartment Bitmap holds the + sum of both logical Releasabilities and also logical Compartments for + a given DOI value. The encoding of the Releasabilities in this field + is described elsewhere in this document. The Releasability encoding + is designed to permit the Compartment Bitmap evaluation to occur + without the evaluator necessarily knowing the human semantic + associated with each bit in the Compartment Bitmap. In turn, this + facilitates the implementation and configuration of Mandatory Access + Controls based on the Compartment Bitmap within IPv6 routers or guard + devices. + +5.2. Packet Word Alignment Considerations + + The basic option is variable length, due to the variable length + Compartment Bitmap field. + + Intermediate Systems that lack custom silicon processing capabilities + and most End Systems perform best when processing fixed-length, + fixed-location items. So the IPv6 base specification levies certain + requirements on all IPv6 optional headers. + + + + + + + + +StJohns, et al. Informational [Page 30] + +RFC 5570 CALIPSO July 2009 + + + The CALIPSO option must maintain this IPv6 64-bit alignment rule for + the option overall. Please note that the Compartment Bitmap field + has a length in quanta of 32-bit words (e.g., 0 bits, 32 bits, 64 + bits, 96 bits), which permits the overall CALIPSO option length to be + 64-bit aligned -- without requiring 32 bits of NULL padding with + every CALIPSO option. + +6. Usage + + This section describes specific protocol processing steps required + for systems that claim to implement or conform with this + specification. + +6.1. Sensitivity Label Comparisons + + This section describes how comparisons are made between two + Sensitivity Labels. Implementing this comparison correctly is + critical to the MLS system providing the intended Mandatory Access + Controls (MACs) to network traffic entering or leaving the system. + + A Sensitivity Label consists of a DOI, a Sensitivity Level, and zero + or more Compartments. The following notation will be used: + + A.DOI = the DOI portion of Sensitivity Label A + A.LEV = the Sensitivity Level portion of Sensitivity Label A + A.COMP = the Compartments portion of Sensitivity Label A + +6.1.1. "Within Range" + + A Sensitivity Label "M" is "within range" for a particular range + "LO:HI" if and only if: + + 1. M, LO, and HI are members of the same DOI. + + (M.DOI == LO.DOI == HI.DOI) + + 2. The range is a valid range. A given range LO:HI is + valid if and only if HI dominates LO. + + ((LO.LEV <= HI.LEV) && (LO.COMP <= HI.COMP)) + + 3. The Sensitivity Level of M dominates the low-end (LO) + Sensitivity Level AND the Sensitivity Level of M is + dominated by the high-end (HI) Sensitivity Level. + + (LO.LEV <= M.LEV <= HI.LEV) + + AND + + + +StJohns, et al. Informational [Page 31] + +RFC 5570 CALIPSO July 2009 + + + 4. The Sensitivity Label M has a Compartment Set that + dominates the Compartment Set contained in the + Sensitivity Label from the low-end range (LO), and + that is dominated by the Compartment Set contained + in the high-end Sensitivity Label (HI) from the range. + + (LO.COMP <= M.COMP <= HI.COMP) + +6.1.2. "Less Than" or "Below Range" + + A Sensitivity Label "M" is "less than" some other Sensitivity Label + "LO" if and only if: + + 1. The DOI for the Sensitivity Label M is identical + to the DOI for both the low-end and high-end of + the range. + + (M.DOI == LO.DOI == HI.DOI) + + AND EITHER + + 2. The Sensitivity Level of M is less than the + Sensitivity Level of LO. + + (M.LEV < LO.LEV) + + OR + + 3. The Compartment Set of Sensitivity Label M is + dominated by the Compartment Set of Sensitivity + Label LO. + + (M.COMP <= LO.COMP) + + A Sensitivity Label "M" is "below range" for a Sensitivity Label + "LO:HI", if LO dominates M and LO is not equal to M. + +6.1.3. "Greater Than" or "Above Range" + + A Sensitivity Label "M" is "greater than" some Sensitivity Label "HI" + if and only if: + + 1. Their DOI's are identical. + + (M.DOI == HI.DOI) + + AND EITHER + + + + +StJohns, et al. Informational [Page 32] + +RFC 5570 CALIPSO July 2009 + + + 2A. M's Sensitivity Level is above HI's Sensitivity Level. + + (M.LEV > HI.LEV) + + OR + + 2B. M's Compartment Set is greater than HI's Compartment Set. + + (M.COMP > HI.COMP) + + A Sensitivity Label "M" is "above range" for a Sensitivity Label, + "LO:HI", if M dominates HI and M is not equal to HI. + +6.1.4. "Equal To" + + A Sensitivity Label "A" is "equal to" another Sensitivity Label "B" + if and only if: + + 1. They have the exact same DOI. + + (A.DOI == B.DOI) + + 2. They have identical Sensitivity Levels. + + (A.LEV == B.LEV) + + 3. Their Compartment Sets are identical. + + (A.COMP == B.COMP) + +6.1.5. "Disjoint" or "Incomparable" + + A Sensitivity Label "A" is disjoint from another Sensitivity Label + "B" if any of these conditions are true: + + 1. Their DOI's differ. + + (A.DOI <> B.DOI) + + 2. B does not dominate A, A does not dominate B, + and A is not equal to B. + + (^( (A < B) || (A > B) || (A == B) )) + + + + + + + + +StJohns, et al. Informational [Page 33] + +RFC 5570 CALIPSO July 2009 + + + 3. Their Compartment Sets are disjoint from each other; + A's Compartment Set does not dominate B's Compartment + Set AND B's Compartment Set does not dominate A's + Compartment Set. + + (^( (A.COMP >= B.COMP) || (A.COMP <= B.COMP) )) + +6.2. End System Processing + + This section describes CALIPSO-related processing for IPv6 packets + imported or exported from an End System claiming to implement or + conform with this specification. This document places no additional + requirements on IPv6 nodes that do not claim to implement or conform + with this document. + +6.2.1. Export + + An End System that sends data to the network is said to "export" it + to the network. Before a datagram can leave an end system and be + transmitted over a network, the following ordered steps must occur: + + 1. Selection of the export DOI: + + a) If the upper-level protocol selects a DOI, + then that DOI is selected. + + b) Else, if there are tables defining a specific default + DOI for the specific destination End System address + or for the network address, then that DOI is selected. + + c) Else, if there is a specific DOI associated with the + sending logical interface (i.e., IP address), then that + DOI is selected. + + d) Else the default DOI for the system is selected. + + NOTE WELL: A connection-oriented transport-layer protocol session + (e.g., Transmission Control Protocol (TCP) session, Stream Control + Transmission Protocol (SCTP) session) MUST have the same DOI and same + Sensitivity Label for the life of that connection. The DOI is + selected at connection initiation and MUST NOT change during the + session. + + A trusted multi-level application that possesses appropriate + privilege MAY use multiple connection-oriented transport-layer + protocol sessions with differing Sensitivity Labels concurrently. + + + + + +StJohns, et al. Informational [Page 34] + +RFC 5570 CALIPSO July 2009 + + + Some trusted UDP-based applications (e.g., remote procedure call + service) multiplex different transactions having different + Sensitivity Levels in different packets for the same IP session + (e.g., IP addresses and UDP ports are constant for a given UDP + session). In such cases, the Trusted Computing Base MUST ensure that + each packet is labeled with the correct Sensitivity Label for the + information carried in that particular packet. + + In the event the End System selects and uses a specific DOI and that + DOI is not recognized by the originating node's first-hop router, the + packet MUST be dropped by the first-hop router. In such a case, the + networking API should indicate the connection failure (e.g., with + some appropriate error, such as ENOTREACH). This fault represents + (1) incorrect configuration of either the Intermediate System or of + the End System or (2) correct operation for a node that is not + permitted to send IPv6 packets with that DOI through that + Intermediate System. + + When an MLS End System is connected to an MLS LAN, it is possible + that there would be more than one first-hop Intermediate System + concurrently, with different Intermediate Systems having different + valid Sensitivity Label ranges. Thoughtful use of the IEEE 802 + Virtual LAN (VLAN) standard (e.g., with different VLAN IDs + corresponding to different sensitivity ranges) might ease proper + system configuration in such deployments. + + 2. Export Labeling: + + Once the DOI is selected, the CALIPSO Sensitivity + Label and values are determined based on the internal + Sensitivity Label and the DOI. In the event the internal + Sensitivity Level does not map to a valid CALIPSO + Sensitivity Label, then an error SHOULD be returned + to the upper-level protocol and that error MAY be + logged. No further attempt to send this datagram + should be made. + + 3. Access Control: + + Once the datagram is marked and the sending logical + interface is selected (by the routing code), the + datagram's Sensitivity Label is compared against the + Sensitivity Label range(s) associated with that logical + interface. For the datagram to be sent, the interface + MUST list the DOI of the datagram Sensitivity Label as + one of the permissible DOI's and the datagram Sensitivity + Label must be within range for the range associated with + that DOI. If the datagram fails this access test, then + + + +StJohns, et al. Informational [Page 35] + +RFC 5570 CALIPSO July 2009 + + + an error SHOULD be returned to the upper-level protocol + and MAY be logged. No further attempt to send this + datagram should be made. + +6.2.2. Import + + When a datagram arrives at an interface on an End System, the + receiving End System MUST: + + 1. Verify the CALIPSO checksum. Datagrams with + invalid checksums MUST be silently dropped. + Such a drop event SHOULD be logged as a security + fault with an indication of what happened. + + 2. Verify the CALIPSO has a known and valid DOI. + Datagrams with unrecognized or illegal DOIs MUST + be silently dropped. Such an event SHOULD be + logged as a security fault with an indication + of what happened. + + 3. Verify the DOI is a permitted one for the receiving + interface. Datagrams with prohibited DOI values + MUST be silently dropped. Such an event SHOULD + be logged as a security fault with an indication + of what happened. + + 4. Verify the CALIPSO Sensitivity Label is within + the permitted range for the receiving interface: + + NOTE WELL: EACH permitted DOI on an interface has + a separate table describing the permitted range + for that DOI. + + A datagram with a Sensitivity Label within the + permitted range is accepted for further processing. + + A datagram with a Sensitivity Label disjoint with + the permitted range MUST be silently dropped. + Such an event SHOULD be logged as a security fault, + with an indication that the packet was dropped + because of a disjoint Sensitivity Label. An ICMP + error message MUST NOT be sent in this case. + + A datagram with a Sensitivity Label below the + permitted range MUST be dropped. This event + SHOULD be logged as a security fault, with an + indication that the packet was below range. + An ICMP error message MUST NOT be sent in this case. + + + +StJohns, et al. Informational [Page 36] + +RFC 5570 CALIPSO July 2009 + + + A datagram with a Sensitivity Label above the + permitted range MUST be dropped. This event + SHOULD be logged as a security fault, with an + indication that the packet was above range. + An ICMP error message MUST NOT be sent in this case. + + 5. Once the datagram has been accepted, the receiving + system MUST use the import Sensitivity Label and DOI + to associate the appropriate internal Sensitivity Label + with the data in the received datagram. This label + information MUST be carried as part of the information + returned to the upper-layer protocol. + +6.3. Intermediate System Processing + + This section describes CALIPSO-related processing for IPv6 packets + transiting an IPv6 Intermediate System that claims to implement and + comply with this specification. This document places no additional + requirements on IPv6 Intermediate Systems that do not claim to comply + or conform with this document. + + The CALIPSO packet format has been designed so that one can configure + an Intermediate System with the minimum sensitivity level, maximum + Sensitivity Level, minimum compartment bitmap, and maximum + compartment bitmap -- and then deploy that system without forcing the + system to know the detailed human meaning of each Sensitivity Level + or compartment bit value. Instead, once the minimum and maximum + labels have been configured, the Intermediate System can apply a + simple algorithm to determine whether or not a packet is within range + for a given interface. This design should be straight-forward to + implement in Application-Specific Integrated Circuit (ASIC) or Field + Programmable Gate Array (FPGA) hardware, because the option format is + simple and easy to parse, and because only a single comparison + algorithm (defined in this RFC, hence known in advance) is needed. + +6.3.1. Input + + Intermediate Systems have slightly different rules for processing + marked datagrams than do End Systems. Primarily, Intermediate + Systems do not IMPORT or EXPORT transit datagrams, they just forward + them. Also, in most deployments intermediate systems are used to + provide Mandatory Access Controls to packets traversing more than one + subnetwork. + + The following checks MUST occur before any other processing. Upon + receiving a CALIPSO-labeled packet, an Intermediate System must: + + + + + +StJohns, et al. Informational [Page 37] + +RFC 5570 CALIPSO July 2009 + + + 1. Determine whether or not this datagram is destined + for (addressed to) this Intermediate System. If + so, then the Intermediate System becomes an End + System for the purposes of receiving this + particular datagram and the rules for IMPORTing + described above are followed. + + 2. Verify the CALIPSO checksum. Datagrams with + invalid checksums MUST be silently dropped. The + drop event SHOULD be logged as a security fault + with an indication of what happened and MAY + additionally be logged as a network fault. + + NOTE WELL: + A checksum failure could indicate a general network + problem (e.g., noise on a radio link) that is + unrelated to the presence of a CALIPSO option, but + it also could indicate an attempt by an adversary + to tamper with the value of a CALIPSO label. + + 3. Verify the CALIPSO has a known and valid DOI. + Datagrams with unrecognized or illegal DOIs MUST + be silently dropped. Such an event SHOULD be + logged as a security fault with an indication of + what happened. + + 4. Verify the DOI is a permitted one for the receiving + interface. Datagrams with prohibited DOIs MUST be + silently dropped. Such a drop SHOULD be logged as + a security fault with an indication of what + happened. + + 5. Verify the Sensitivity Label within the CALIPSO + is within the permitted range for the receiving + interface: + + NOTE WELL: + Each permitted DOI on an interface has a separate + table describing the permitted range for that DOI. + + A rejected datagram with a Sensitivity Label below + or disjoint with the permitted range MUST be + silently dropped. Such an event SHOULD be logged + as a security fault with an indication of what + happened. An ICMP error message MUST NOT be sent + in this case. + + + + + +StJohns, et al. Informational [Page 38] + +RFC 5570 CALIPSO July 2009 + + + A rejected datagram with a Sensitivity Label above + the permitted range MUST be dropped. The drop + event SHOULD be logged as a security fault with an + indication of what happened. An ICMP error message + MUST NOT be sent in this case. + + If and only if all the above conditions are met is the datagram + accepted by the IPv6 Intermediate System for further processing and + forwarding. + + At this point, the datagram is within the permitted range for the + Intermediate System, so appropriate ICMP error messages MAY be + created by the IP module back to the originating End System regarding + the forwarding of the datagram. These ICMP messages MUST be created + with the exact same Sensitivity Label as the datagram causing the + error. Standard rules about generating ICMP error messages (e.g., + never generate an ICMP error message in response to a received ICMP + error message) continue to apply. Note that these locally generated + ICMP messages must go through the same outbound checks (including MAC + checks) as any other forwarded datagram as described in the following + paragraphs. + +6.3.2. Translation by Intermediate Systems + + It is at this point, after input processing and before output + processing, that translation of the CALIPSO from one DOI to another + DOI takes place in an Intermediate System, if at all. Section 6.4 + describes the two possible approaches to translation. + +6.3.3. Output + + Once the forwarding code has selected the interface through which the + datagram will be transmitted, the following takes place: + + 1. If the output interface requires that all packets + contain a CALIPSO label, then verify that the packet + contains a CALIPSO label. + + 2. Verify the DOI is a permitted one for the sending + interface and that the datagram is within the + permitted range for the DOI and for the interface. + + 3. Datagrams with prohibited DOIs or with out-of-range + Sensitivity Labels MUST be dropped. Any drop event + SHOULD be logged as a security fault, including + appropriate details about which datagram was + dropped and why. + + + + +StJohns, et al. Informational [Page 39] + +RFC 5570 CALIPSO July 2009 + + + 4. Datagrams with prohibited DOIs or out-of-range + Sensitivity Labels MAY result in an ICMP "Destination + Unreachable" error message, depending upon the + security configuration of the system. + + If the cause of the dropped packet is that the + DOI is prohibited or unrecognized, then a reason + code of "No Route to Host" is used. If the dropped + packet's DOI is valid, but the Sensitivity Label + is out of range, then a reason code of + "Administratively Prohibited" is used. If an + unlabeled packet has been dropped because the + packet is required to be labeled, then a reason + code of "Administratively Prohibited" is used. + + In all cases, if an ICMP Error Message is sent, + then it MUST be sent with the same Sensitivity + Label as the rejected datagram. + + The choice of whether or not to send an ICMP + message, if sending an ICMP message for this case + is implemented, MUST be configurable, and SHOULD + default to not sending an ICMP message. Standard + conditions about generating ICMP error messages + (e.g., never send an ICMP error message about a + received ICMP error message) continue to apply. + +6.4. Translation + + A system that provides on-the-fly relabeling is said to "translate" + from one DOI to another. There are basically two ways a datagram can + be relabeled: + + Either the Sensitivity Label can be converted from a CALIPSO + Sensitivity Label, to an internal Sensitivity Label, and then back to + a new CALIPSO Sensitivity Label, exclusive-or a CALIPSO Sensitivity + Label can be directly remapped into a new CALIPSO Sensitivity Label. + + The first of these methods is the functional equivalent of + "importing" the datagram then "exporting" it and is covered in detail + in the "Import" (Section 6.2.2) and "Export" (Section 6.2.1) sections + above. + + The remainder of this section describes the second method, which is + direct relabeling. The choice of which method to use for relabeling + is an implementation decision outside the scope of this document. + + + + + +StJohns, et al. Informational [Page 40] + +RFC 5570 CALIPSO July 2009 + + + A system that provides on-the-fly relabeling without importing or + exporting is basically a special case of the Intermediate System + rules listed above. Translation or relabeling takes place AFTER all + input checks take place, but before any output checks are done. + + Once a datagram has passed the Intermediate System input processing + and input validation described in Section 6.3.1, and has been + accepted as valid, the CALIPSO in that datagram may be relabeled. To + determine the new Sensitivity Label, first determine the new output + DOI. + + The selection of the output DOI may be based on any of Incoming DOI, + Incoming Sensitivity Label, Destination End System, Destination + Network, Destination Subnetwork, Sending Interface, or Receiving + Interface, or combinations thereof. Exact details on how the output + DOI is selected are implementation dependent, with the caveat that it + should be consistent and reversible. If a datagram from End System A + to End System B with DOI X maps into DOI Y, then a datagram from B to + A with DOI Y should map into DOI X. + + Once the output DOI is selected, the output Sensitivity Label is + determined based on (1) the input DOI and input Sensitivity Label and + (2) the output DOI. In the event the input Sensitivity Label does + not map to a valid output Sensitivity Label for the output DOI, then + the datagram MUST be silently dropped and the drop event SHOULD be + logged as a security fault. + + Once the datagram has been relabeled, the Intermediate System output + procedures described in Section 6.3.3 are followed, with the + exception that any error that would cause an ICMP error message to be + generated back to the originating End System instead MUST silently + drop the datagram without sending an ICMP error message. Such a drop + SHOULD be logged as a security fault. + +7. Architectural and 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. + + This IPv6 option specification is only a small part of an overall + distributed Multi-Level Secure (MLS) deployment. Detailed + instructions on how to build a Multi-Level Secure (MLS) device are + well beyond the scope of this specification. Additional information + on implementing a Multi-Level Secure operating system, for example + implementing an MLS End System, is available from a range of sources + [TCSEC] [TNI] [CMW] [CC] [ISO-15408] [MLOSPP]. + + + +StJohns, et al. Informational [Page 41] + +RFC 5570 CALIPSO July 2009 + + + Because the usual 5-tuple (i.e., Source IP address, Destination IP + address, Transport protocol, Source Port, and Destination Port) do + not necessarily uniquely identify a flow within a labeled MLS network + deployment, some applications or services might be impacted by + multiple flows mapping to a single 5-tuple. This might have + unexpected impacts in a labeled MLS network deployment using such + application protocols. For example, Resource Reservation Protocol + (RSVP), Session Initiation Protocol (SIP), and Session Description + Protocol (SDP) might be impacted by this. + + A number of Commercial-Off-The-Shelf (COTS) applications (e.g., + Remote Access Dial-In User Service (RADIUS), Hyper-Text Transfer + Protocol (HTTP), and Transport-Layer Security (TLS) web content + access) have been included in MLS network deployments for about two + decades, without operational difficulties or a need for special + modifications. The ability to use these common applications + demonstrates that the basic Internet architecture remains unchanged + in an MLS deployment, although certain details (e.g., adding labels + to IP datagrams) do change. + +7.1. Intermediate Systems + + Historically, RFC 1108 was supported by one commercial label-aware IP + router. Neither RFC 1038 nor FIPS-188 were supported in any + commercial IP router, so far as the authors are aware. A label-aware + router does not necessarily use an MLS operating system. Instead, a + label-aware router might use a conventional router operating system, + adding extensions to permit application of per-logical-interface + label-oriented Access Control Lists (ACLs) to IP packets entering and + leaving that router's network interface(s). + + This proposal does not change IP routing in any way. Existing + label-aware routers do not use Sensitivity Labels in path + calculations, Routing Information Base (RIB) or Forwarding + Information Base (FIB) calculations, their routing protocols, or + their packet forwarding decisions. + + Similarly, existing MLS network deployments use many protocols or + specifications, for example, Differentiated Services, without + modification. For Differentiated Services, this might mean that + multiple IP flows (i.e., flows differing only in their CALIPSO label + value) would be categorized and handled by Intermediate Systems as if + they were a single flow. + + Router performance is optimized if there is hardware support for + applying the Mandatory Access Controls based on this label option. + An issue with CIPSO is that the option syntax is remarkably complex + [FIPS-188]. So this label option uses a simplified syntax. This + + + +StJohns, et al. Informational [Page 42] + +RFC 5570 CALIPSO July 2009 + + + should make it more practical to create custom logic (e.g., in + Verilog) with support for this option and the associated Mandatory + Access Controls. + +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-Layer 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 some upper-layer protocol issues. + + This section is not a complete specification for how an MLS End + System 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], + [TNI], [CMW], [CC], [ISO-15408], and [MLOSPP]. + + In a typical MLS End System, 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 End System + operating system. The MLS End System 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. + +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 that exists in multiple virtual networks to + have identical TCP connections, each one existing in a different + virtual network. + + + +StJohns, et al. Informational [Page 43] + +RFC 5570 CALIPSO July 2009 + + + 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). This corrects a technical + error in RFC 793, and is consistent with all known MLS operating + system implementations [TNI] [RFC793]. There are no known currently + deployed TCP instances that actually comply with this specific detail + of RFC 793. + +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 End System + implementations of UDP and IPv6, a UDP listener might be bound only + to a particular UDP port on its End System -- without binding to a + particular remote IP address or local IP address. + + UDP can be used with unicast or with multicast. Some existing UDP + End System 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 behavior of a given + system should remain the same (so that application behavior 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 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. + + + + +StJohns, et al. Informational [Page 44] + +RFC 5570 CALIPSO July 2009 + + + 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 that 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. Unlike TCP, SCTP can support session- + endpoint migration among IP addresses at the same end node(s), and + SCTP can also support both one-to-one and one-to-many communication + sessions. + + In single-level End Systems, in the one-to-one mode, the SCTP session + state for a single local SCTP session includes the set of remote IP + addresses for the single remote SCTP instance, the set of local IP + addresses, the remote SCTP port number, and the local SCTP port + number. + + In single-level End Systems, in the one-to-many mode, the SCTP + session state for a single local SCTP instance can have multiple + concurrent connections to several different remote SCTP peers. There + cannot be more than one connection from a single SCTP instance to any + given remote SCTP instance. Thus, in single-level End Systems, in + the one-to-many mode, the local SCTP session state includes the set + of remote IP addresses, the set of local IP addresses, the remote + SCTP port number for each remote SCTP instance, and the (single) + local SCTP port number. + + In MLS End Systems, for either SCTP mode, the SCTP session state + additionally includes the Sensitivity Label for each SCTP session. A + single SCTP session, whether in the one-to-one mode or in the one- + to-many mode, MUST have a single Sensitivity Label, rather than a + Sensitivity Label range. + + 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, when one or more endpoints have multiple IP + addresses. If such shifting occurs within an MLS deployment, it is + important that it only move to an IP address with a Sensitivity Label + range that includes that SCTP session's own Sensitivity Label. + + 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 + + + +StJohns, et al. Informational [Page 45] + +RFC 5570 CALIPSO July 2009 + + + "A:X", then that packet will not be able to use the "U"-only network + interface. Hence, an SCTP implementation needs to consider the + Sensitivity Label of each SCTP instance on the local system when + deciding which of its own IP addresses to communicate to the remote + SCTP instance(s) for that SCTP instance. This issue might lead to + novel operational issues with SCTP sessions. Implementers ought to + give special attention to this SCTP-specific issue. + +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 should carefully 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 (AH). + Implementations MUST permit the system administrator to configure + whether or not AH is used. + + ESP with null encryption mechanism can only protect the payload of an + IPv6 packet, not any Hop-by-Hop Options. By contrast, AH protects + all invariant headers and data of an IPv6 packet, including the + CALIPSO Hop-by-Hop Option. The CALIPSO option defined in this + document is always an IPv6 Hop-by-Hop Option, because the CALIPSO + option needs to be visible to, and parsable by, IPv6 routers and + security gateways so that they can apply MAC policy to packets. + + + +StJohns, et al. Informational [Page 46] + +RFC 5570 CALIPSO July 2009 + + + It is anticipated that if AH is being used with a symmetric + authentication algorithm, then not only the recipient End System, but + also one or more security gateways along the path, will have + knowledge of the symmetric key -- so that AH can be used to + authenticate the packet, including the CALIPSO label. In this case, + all devices knowing that symmetric authentication key would need to + be trusted. Alternatively, AH may be used with an asymmetric + authentication algorithm, so that the recipient and any security + gateways with knowledge of the authentication key can authenticate + the packet, including the CALIPSO label. + + If AH or ESP are employed to provide "labeled IP Security" within + some CALIPSO deployment, then the Sensitivity Label of the IP + Security Association used for a given packet MUST have the same + meaning as the Sensitivity Label carried in the CALIPSO option of + that packet, in order that MAC policy can and will be correctly + applied. + + 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. + + NOTE WELL: The "not modified during transit" bit for IPv6 option + types was really created to be the "include in AH calculations" + signal. There was no other reason to define that bit in IPv6. + + In situations where a modification by an Intermediate System is + required by policy, 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 of the + Intermediate System, then (by definition) such a packet modification + is not required. + + Note that in a number of error situations with labeled 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. Such ICMP handling details have been + described earlier in this document. 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 + + + +StJohns, et al. Informational [Page 47] + +RFC 5570 CALIPSO July 2009 + + + message to the intended destination node. In turn, this can mean + operational faults (e.g., fibre cut, misconfiguration) in a labeled + 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. + + This specification does not seek to eliminate all possible covert + channels. The TCP specification clarification in Section 7.3.1 + happens to reduce the bandwidth of a particular known covert channel, + but is present primarily to clarify how networked MLS systems have + always been implemented [TNI] [MLOSPP]. + + Of course, subject to local security policies, encrypted IPv6 packets + with CALIPSO labels might well traverse the public Internet after + receiving suitable cryptographic protection. For example, a + CALIPSO-labeled packet might travel either through a Tunnel-mode ESP + (with encryption) VPN tunnel that connects two or more MLS-labeled + network segments. Alternatively, a CALIPSO-labeled IPv6 packet might + travel over some external link that has been protected by the + deployment of evaluated, certified, and accredited bulk encryptors + that would encrypt the labeled packet before transmission onto the + link and decrypt the labeled packet after reception from the link. + + Accreditors of a given CALIPSO 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. This + specification is only a small component of an overall MLS network + deployment. + +9. IANA Considerations + +9.1. IP Option Number + + An IPv6 Option Number [RFC2460] has been registered for CALIPSO. + + HEX BINARY + act chg rest + --- --- --- ----- + 7 00 0 00111 CALIPSO + + + + + + +StJohns, et al. Informational [Page 48] + +RFC 5570 CALIPSO July 2009 + + + For the IPv6 Option Number, the first two bits indicate that the IPv6 + node skip over this option and continue processing the header if it + does not recognize the option type. The third bit indicates that the + Option Data must not change en route. + + This document is listed as the reference document. + +9.2. CALIPSO DOI Values Registry + + IANA has created a registry for CALIPSO DOI values. The initial + values for the CALIPSO DOI registry, shown in colon-separated quad + format, are as follows: + + DOI Value Organization or Use + ======================= ============================ + 0:0:0:0 NULL DOI. This ought not + be used on any network. + + 0:0:0:1 to 0:255:255:255 For private use among + consenting parties within + private networks. + + 1:0:0:0 to 254:255:255:255 For assignment by IANA to + organizations following the + Expert Review procedure + [RFC5226]. + + 255:0:0:0 to 255:255:255:255 Reserved to the IETF for + future use by possible + revisions of this specification. + + The CALIPSO DOI value 0:0:0:0 is the NULL DOI and is not to be used + on any network or in any deployment. + + All other CALIPSO DOI values beginning with decimal 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 the CALIPSO DOI values 1:0:0:0 through 254:255:255:255 + (inclusive), IANA should follow the Expert Review procedure when DOI + Allocation requests are received. + + CALIPSO DOI values beginning with decimal 255 are reserved to the + IETF for potential future use in revisions of this specification. + IESG approval is required for allocation of DOI values within that + range. + + + + + +StJohns, et al. Informational [Page 49] + +RFC 5570 CALIPSO July 2009 + + +10. Acknowledgments + + This document is directly derived from an Internet-Draft titled "Son + of IPSO (SIPSO)" written by Mike StJohns circa 1992. Various changes + have been made since then, primarily to support IPv6 instead of IPv4. + 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, James Carlson, Pasi Eronen, Michael + Fidler, Bob Hinden, Alfred Hoenes, Russ Housley, Suresh Krishnan, + Jarrett Lu, Dan McDonald, Paul Moore, Joe Nall, Dave Parker, Tim + Polk, Ken Powell, Randall Stewart, Bill Sommerfeld, and Joe Touch + (listed in alphabetical order by family name) provided specific + feedback on earlier versions of this document. + + The authors also would like to thank the several anonymous reviewers + for their feedback, and particularly for sharing their insights into + operational considerations with MLS networking. + + The authors would like to thank the IESG as a whole for providing + feedback on earlier versions of this document. + +11. References + +11.1. Normative References + + [RFC1662] Simpson, W., Ed., "PPP in HDLC-like Framing", STD 51, + RFC 1662, July 1994. + + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version + 6 (IPv6) Specification", RFC 2460, December 1998. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing + an IANA Considerations Section in RFCs", BCP 26, RFC + 5226, May 2008. + +11.2. Informative References + + [BL73] Bell, D.E. and LaPadula, L.J., "Secure Computer Systems: + Mathematical Foundations and Model", Technical Report + M74-244, MITRE Corporation, Bedford, MA, May 1973. + + [CW87] D.D. Clark and D.R. Wilson, "A Comparison of Commercial + and Military Computer Security Policies", in + Proceedings of the IEEE Symposium on Security and + Privacy, pp. 184-194, IEEE Computer Society, Oakland, + CA, May 1987. + + + + +StJohns, et al. Informational [Page 50] + +RFC 5570 CALIPSO July 2009 + + + [CMW] US Defense Intelligence Agency, "Compartmented Mode + Workstation Evaluation Criteria", Technical Report + DDS-2600-6243-91, Washington, DC, November 1991. + + [DoD5200.1-R] + US Department of Defense, "Information Security Program + Regulation", DoD 5200.1-R, 17 January 1997. + + [DoD5200.28] US Department of Defense, "Security Requirements for + Automated Information Systems," Directive 5200.28, 21 + March 1988. + + [MLOSPP] 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 Standards 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. + + [TNI] (US) National Computer Security Center, "Trusted + Network Interpretation (TNI) of the Trusted Computer + System Evaluation Criteria", NCSC-TG-005, Version 1, 31 + July 1987. + + [FIPS-188] US National Institute of Standards and Technology, + "Standard Security Labels for Information Transfer", + Federal Information Processing Standard (FIPS) 188, + September 1994. + + [IEEE802.1Q] IEEE, "Virtual Bridged Local Area Networks", IEEE + Standard for Local and metropolitan area networks, + 802.1Q - 2005, ISBN 0-7381-4876-6, IEEE, New York, NY, + USA, 19 May 2006. + + [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, + September 1981. + + [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC + 793, September 1981. + + + + +StJohns, et al. Informational [Page 51] + +RFC 5570 CALIPSO July 2009 + + + [RFC1038] St. Johns, M., "Draft revised IP security option", RFC + 1038, January 1988. + + [RFC1108] Kent, S., "U.S. Department of Defense Security Options + for the Internet Protocol", RFC 1108, November 1991. + + [RFC1825] Atkinson, R., "Security Architecture for the Internet + Protocol", RFC 1825, August 1995. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC4301] Kent, S. and K. Seo, "Security Architecture for the + Internet Protocol", RFC 4301, December 2005. + + [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, + December 2005. + + [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", + RFC 4303, December 2005. + +Authors' Addresses + + Michael StJohns + Germantown, MD + USA + + EMail: mstjohns@comcast.net + + + Randall Atkinson + Extreme Networks + 3585 Monroe Street + Santa Clara, CA + USA 95051 + + EMail: rja@extremenetworks.com + Phone: +1 (408)579-2800 + + + Georg Thomas + US Department of Defense + Washington, DC + USA + + + + + + + +StJohns, et al. Informational [Page 52] + |