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.
In the last decade or so, typical Ethernet link speeds have changed from 10 Mbps half-duplex to 1 Gbps duplex. The 10 Gbps 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 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
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.
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
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.