RFC 5570

Common Architecture Label IPv6 Security Option (CALIPSO) 💖

Okay bestie, this is RFC 5570 🎀, and it's an Informational doc from July 2009. That means it's sharing knowledge with the internet community, not setting a standard. The authors are M. StJohns (Consultant), R. Atkinson (Extreme Networks), and G. Thomas (US Department of Defense). It doesn't obsolete or update any other RFCs. 🫶

Abstract ✨

Okay so this doc describes an optional way to slap explicit Sensitivity Labels onto IPv6 packets 🏷️. It's only meant for Multi-Level Secure (MLS) networking environments that are both trusted and trustworthy 🔒. Main character energy for locked-down networks only.

Status of This Memo 📚

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

IESG Note 🚨

Okay, this part is SO important, so read it carefully bestie 😭. This RFC specifies the use of an IPv6 hop-by-hop option. The IESG says that general deployment of protocols with hop-by-hop options is problematic, so developing those protocols is discouraged 💀. After careful review, the IETF decided a hop-by-hop option is an appropriate solution for this one specific limited environment and use case 🫠. Furthermore, the mechanism in this RFC only applies to closed IP networks. It's unsuitable for use and ineffective on the global public Internet. Do NOT take this to the open internet, periodt 🙅‍♀️.

Reminder: this mechanism is for closed networks only. It is unsuitable 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, as they stand on the date this document was published (http://trustee.ietf.org/license-info). Please read these carefully, because they spell out your rights and restrictions with respect to this document 📜.

This document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So unless you get an adequate license from whoever controls that copyright, 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. The exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌸.

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

1. Introduction ✨

Okay so the original IPv4 spec in RFC 791 included an option for labeling how sensitive IP packets are 🏷️. That option got revised by RFC 1038 and later by RFC 1108 [RFC791] [RFC1038] [RFC1108]. The IETF later deprecated RFC 1108, but that IPv4 option is still in active use across a bunch of closed Multi-Level Secure (MLS) IP networks 🔒.

One or another IP Sensitivity Label option has had limited deployment for about two decades, mostly in government or military internal networks 🫡. There are also some commercial deployments, where corporate security policies require Mandatory Access Controls on sensitive data. Some banks use MLS tech to restrict sensitive info, like details about mergers and acquisitions 🤫. This IPv6 option, just like its IPv4 predecessors, is only meant for private internetworks that are disconnected from the global Internet 🚫🌐. This document specifies the explicit packet labeling extensions for IPv6 packets 🎀.

1.1. History 🕰️

This document is a direct descendant of RFC 1038 and RFC 1108, and it's 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 had one very specific purpose: supporting the fielding of an IPv4 packet-encryption device called a BLACKER [RFC1038]. Because of that, the definitions and assumptions in those documents were 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, which are often made up of Compartmented Mode Workstations (CMWs) connected over a Local Area Network (LAN) 💻. So the mechanism defined here is more general than either RFC 1038 or RFC 1108 🌸.

Also, deploying Compartmented Mode Workstations ran into operational constraints. The space available for IPv4 options is limited, and relatively small 😩. This caused one non-IETF specification for IPv4 packet labeling to have a large number of sub-options. A very unfortunate side effect of sub-options inside an IPv4 label option was that it became much harder to implement Intermediate System support for Mandatory Access Controls (for example, in a router or MLS guard system) while still forwarding traffic at, or near, wire-speed 🥲.

In the last decade or so, typical Ethernet link speeds went 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 some servers. As of this writing, the IEEE is actively developing standards for both 40 Gbps Ethernet and 100 Gbps Ethernet ⚡. Forwarding at those speeds typically requires support from Application-Specific Integrated Circuits (ASICs), and supporting more complex packet formats usually takes significantly more gates than supporting simpler ones 🧠. So the pressure to have a single simple option format has only gone up over the past decade, and it's only going to keep going up 📈.

When IPv6 was first being developed, people expected that IP Security, in particular the Encapsulating Security Payload (ESP) and the IP Authentication Header (AH), would make explicit packet Sensitivity Labels unnecessary for IPv6 [RFC1825] [RFC4301] [RFC4302] [RFC4303] 🤔. For MLS IPv6 deployments where AH or ESP is practical, the use of AH and/or ESP is recommended 💅.

However, some applications (for example, distributed file systems, especially ones not designed for Compartmented Mode Workstations or other MLS computers) multiplex different transactions at different Sensitivity Levels and/or with different privileges over a single IP communications session, such as with the User Datagram Protocol 🫣. To keep data Sensitivity Labeling for those applications, to implement routing and Mandatory Access Control decisions in routers and guards on a per-IP-packet basis, and for other reasons, there's a real need for a mechanism that explicitly labels the sensitivity information for each IPv6 packet 🎯.

Existing Layer 3 Virtual Private Network (VPN) tech can't solve the issues this spec addresses, and there are several independent reasons why 🙅‍♀️. First, in a typical deployment, lots of labeled packets flow from an MLS End System through a set of networks to a receiving MLS End System. The receiving MLS End System uses the per-packet label to figure out which Sensitivity Label to associate with the user data in the packet. Existing Layer 3 VPN specs don't specify any way to carry a Sensitivity Label 🏷️. Second, existing Layer 3 VPN techs aren't implemented in any MLS End Systems, or in typical single-level End System operating systems. They're usually only implemented in routers. Adding a Layer 3 VPN implementation to an MLS End System's networking stack would be a lot more work than adding this IPv6 option to that same system 🛠️. Third, existing Layer 3 VPN specs don't support using Sensitivity Labels to pick which VPN to use for carrying a packet. That function is essential if you wanted to skip this IPv6 option entirely 😤. Using a Layer 3 VPN approach would need substantial new standards development, plus significant new implementation work in End Systems, before it could be used. Building those specs and then implementing them in MLS systems would take way more effort than just implementing this IPv6 label option in an MLS End System (or in a label-aware router) 💪. And honestly? Both the MLS user community and the MLS implementer community prefer the approach defined in this specification 👑.

🦋 (Part 1 of 11. More to come, so stay tuned bestie!)

1.2. Intent and Applicability ✨

Okay, first things first: nothing in this document applies to any system that doesn't claim to implement it. 💅

This doc describes a generic way of labeling IPv6 datagrams so everyone can see how sensitive they are 🔒. It makes room for separating data based on the domain of interpretation (like an agency, a country, an alliance, or a coalition 🌍), the relative sensitivity (aka Sensitivity Levels 📊), and need-to-know or formal access programs (aka compartments or categories 🗝️).

There's also a commonly used method of encoding Releasabilities as if they were Compartments, and that's described here too 🦋. Ngl, this usage doesn't have exactly the same semantics as some formal Releasability policies. BUT existing Multi-Level Secure operating systems don't have OS support for Releasabilities as a separate concept from compartments. The semantics of this encoding are close to the formal policies, and a bunch of different organizations have been deploying it for at least a decade now 🫶.

In particular, the authors believe 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 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 the consequences could be unusually severe (e.g., loss of life, loss of very large sums of money) if a packet labeled with this IPv6 Option escaped onto the global public Internet, organizations deploying this mechanism have unusually strong incentives to configure security controls so labeled packets never appear on the global public Internet 😭. Honestly, a primary purpose of this mechanism is to enable deployment of Mandatory Access Controls for IPv6 packets. 👑

However, to make sure both End Systems and Intermediate Systems play nicely within a labeled IPv6 deployment, it's essential to have an open specification for this option ✨.

This option is not designed to be an all-purpose label option, and it specifically does not include support for generic Domain Type Enforcement (DTE) mechanisms. If a DTE label option is wanted, it ought to be specified separately 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 the most common. First, in typical deployments, everyone with access to an unencrypted link is cleared for all the unencrypted information traveling over that link 🔐. Also, MLS system administrators have normally been cleared to see all the information processed or stored by that MLS system 👀. This specification doesn't try to eliminate every potential covert channel related to this IPv6 option. 🤷‍♀️

In the first scenario, all the connected nodes in a given private internetwork are trusted systems with Multi-Level Secure (MLS) operating systems, such as Compartmented Mode Workstations (CMWs), that support per-packet Sensitivity Labels [TCSEC] [TNI] [CMW] [MLOSPP] 💜. In this kind 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 packet they originate, and all End Systems apply Mandatory Access Controls to each packet they receive. 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) get 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 at only one Sensitivity Level, that's also 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.

Here's the tricky part 😤: because those non-MLS End Systems can't create packets containing Sensitivity Labels and also can't 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 into packets originated by the "system high" End Systems that are to be forwarded off the subnet. While the CALIPSO IPv6 option is marked as "ignore if unrecognized," some deployed IPv6 End Systems have bugs. Users can't fix these operating system bugs, but some users still need 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 the packet (if it isn't permitted on that destination subnet) or exclusive-or remove the Sensitivity Labels and forward the packet onto those "system high" subnetworks (if it is permitted on that destination subnetwork) 🎀.

The authors aren't 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 in some segments of the public Internet 🙅‍♀️.

Similarly, the authors aren't 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 aren't worried about external penetration (e.g., by worms, viruses, or the like) 🛡️. Also, all users of the MLS network have been cleared through some process specific to that organization, and hence are believed to be trustworthy. In a typical deployment, every computer connected to the MLS network sits in a physically secure room or building (e.g., protected by guards with guns) 🔫. Electronic equipment that enters such a space typically doesn't leave. Items like USB memory sticks are generally not permitted. In fact, the USB ports on MLS computers have often 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, so it's 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 🍓.

---

2. Definitions 📖

This section defines several terms that are important for understanding and correctly implementing this specification. Because of historical variations in terminology across different user communities, several terms have defined synonyms 🦋.

The verb "dominate" is used in this document to describe the 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, dictate which systems, and ultimately which persons, may receive that data 🗝️.

In other words, a label of "SECRET" by itself isn't meaningful. You also have to 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 you can decide who is allowed to receive it 🤔.

A CALIPSO DOI is an opaque identifier used as a pointer to a particular set of policies. Those policies define the Sensitivity Levels and Compartments present within the DOI and, by inference, 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 gives you a standard way of labeling IP data originating from End Systems "accredited" or "approved" to operate within that DOI and within the constraints of those security policies ✨. For example, if someone did this for the US Department of Defense, they would list all the acceptable labels, such as "SECRET" and "TOP SECRET," and link the CALIPSO DOI to the [DoD5200.28] and [DoD5200.1-R] documents, which define how to mark and protect data within the US Department of Defense (DoD) [DoD5200.28] [DoD5200.1-R] 🫡.

The scope of the DOI depends on the organization creating it. Sometimes the creator of the DOI isn't 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) uses that multi-national DOI (possibly along with other DOIs created by others) within its private networks 🌐. To give a different example, the United States might establish a DOI with specific meanings that correspond to the normal way it labels classified documents, and which would apply primarily to the US DoD, though those meanings might also apply to other associated agencies 🇺🇸. A company or other organization might also establish a DOI that applies only to itself 🏢.

NOTE WELL: A CALIPSO Domain of Interpretation is different from, and disjoint from, an Internet Security Association and Key Management Protocol (ISAKMP) / Internet Key Exchange (IKE) Domain of Interpretation. It's important not to confuse the two concepts, even though the terms might superficially appear to be similar 🚨.

2.2. Sensitivity Level 🦋

okay so a Sensitivity Level is basically a mandatory separation of data based on how sensitive it is 🔒 Sensitivity Levels ALWAYS have a specific ordering within a DOI, no exceptions, bestie. Clearance for one level also gets you access to every level that's less sensitive. Say A, B, and C are levels and A is more sensitive than B, which is more sensitive than C (A > B > C). Having access to B means you can see C too. The UK uses terms like "UNCLASSIFIED", "RESTRICTED", "CONFIDENTIAL", "SECRET", and "MOST SECRET" (ordered from low to high) 🫶

NOTE WELL: a Sensitivity Level is only one part of a Sensitivity Label, so don't mix the two up 💀 Also, "Sensitivity Level" means the exact same thing as "Security Level" 💅

2.3. Compartment 🎀

A Compartment is a mandatory segregation of data based on formal information categories, formal information compartments, or formal access programs for specific kinds of data. Picture a small startup making "FINANCE" and "R&D" compartments to guard the stuff that keeps it alive. Only people with a real need to know get in: the accountants and controller for "FINANCE", and specific engineers for "R&D" 👑 Each Compartment is separate and distinct, so getting into one does not get you into any other one. Data can sit in several compartments at once (like "FINANCE" data about a new "R&D" project), and then you need access to ALL of them to see it. Anyone who only has a Sensitivity Level clearance, with no specific compartments, can't see anything that's tagged with compartments. So "SECRET FINANCE" dominates "SECRET", and that's the whole tea ☕

NOTE WELL: "category" and "compartment" mean the exact same thing. Some user communities say "category" and others say "compartment", but they're identical 🌈

2.4. Releasability 🌸

A Releasability is 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 that gives slightly different semantics and behavior than a paper marked with the same Releasabilities would get, because the formal semantics of Compartments and Releasability are not the same. We'll get into those differences later in this subsection 🧚

These days, some pretty big MLS deployments have been encoding Releasabilities as if they were inverted Compartments for years now. The results have been tolerable, and those deployments are generally seen as successful by their user communities ✨ This description matches those deployments, so it has real operational experience behind it 💜

2.4.1. Releasability Conceptual Example 🍓

Let's say two companies, ABC and XYZ, are doing a technical alliance 🤝 ABC labels everything inside its enterprise that's going to be shared with the alliance as REL XYZ, like COMPANY CONFIDENTIAL REL XYZ.

But unlike the compartment example above, COMPANY CONFIDENTIAL dominates COMPANY CONFIDENTIAL REL XYZ. This means XYZ employees with a COMPANY CONFIDENTIAL REL XYZ clearance can only access releasable material, while ABC employees with a COMPANY CONFIDENTIAL clearance can access everything 😭

If REL XYZ were managed as a compartment, anyone with a COMPANY CONFIDENTIAL REL XYZ clearance would be able to see all of ABC's COMPANY CONFIDENTIAL material, and that is absolutely NOT the vibe 🙈

Releasabilities can be combined too, like COMPANY CONFIDENTIAL REL XYZ/ABLE. In that case, users holding any of 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. Here's how to make that work properly, explained below 💅

This scheme is carefully designed so intermediate systems don't need to know whether a given bit in the Compartment Bitmap field stands for a compartment or a Releasability. All an Intermediate System has to do is apply the usual comparison (the one in Section 2.5.1 and 2.5.2) to figure out whether a packet's label is in-range for an interface. That makes both configuring and implementing a label-aware Intermediate System way simpler 🫶

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 bit is "1", the information may NOT be released to that community 💀

Only administrative interfaces that present or build binary labels in human-readable form need to understand the difference between Releasability bits and non-Releasability bits. Implementers are encouraged to describe Releasability encoding in the documentation they give users of systems that implement this specification ✨

2.4.2. Releasability Encoding Examples 🧚

For objects, like IP packets, bits 0-3 of the Compartment Bitmap field control Releasability to communities A, B, C, and D, in that order 🍓

Example 1: Not releasable to any community. This is usually how handling restrictions like "No Foreigners (NO FORN)" get 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, and D.

ABCD == 0000

For subjects, like user clearances, the same bit encodings get used for Releasabilities as for objects (see above) 👑

Example 1: Clearance not belonging to any community. This user can see information belonging to any Releasability community, since they aren't 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 belonging 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 let's look at some example comparisons for an IP router enforcing MAC with CALIPSO labels on some interface 🎀

Say the MINIMUM label for that router interface is CONFIDENTIAL RELEASABLE AC. So this interface has a minimum Releasability of 0101.

Say the MAXIMUM label for that router interface is TOP SECRET NOT RELEASABLE. So this interface has a maximum Releasability of 1111.

For range comparisons, the bit values for the current packet need to be "greater than or equal to" the interface's minimum value AND also "less than or equal to" the interface's maximum value, just like with compartment comparisons. The inverted encoding scheme above is what makes the right results happen 🔥

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 🙈

Okay, bestie, let's say we have a person named "Jane Doe" who belongs to two Releasability communities, A and B. 💅 She's allowed to see a paper document marked "Releasable A", "Releasable B", or "Releasable AB", as long as her Clearance and Compartments are in-range for the Sensitivity Level and Compartments of that paper document (respectively). 📄✨

Now the electronic version, which works the way we outlined above. We're still looking at two Releasability communities (A and B), and the bits get set to 00 for the electronic user ID belonging to "Jane Doe". 🎀

Here's the tea 🫖: the electronic Releasability approach above will only let her see information marked "Releasable AB". It will deny her access to documents marked "Releasable A" or "Releasable B", and that's giving a lot of restriction 😭. The reason is that "Releasable A" is encoded as 01, "Releasable B" is encoded as 10, and "Releasable AB" is encoded as 00. If you check the compartment dominance computation, 00 dominates 00, but 00 does not dominate 01, and 00 also does not dominate 10. Yikes. 💀

Users say the current situation is tolerable, but not ideal. They also say various operational complexities can come up with this approach. 🥲

Several deployments work around this by giving an electronic user several parallel clearances. Using the (fictitious) example from before, "Jane Doe" might have one clearance with no Releasability at all, a second separate clearance with Releasability A, and a third separate clearance with Releasability B. 🧚 This does have implications, like needing to associate multiple separate parallel clearances with a single user ID, for implementers of MLS systems. Still, this specification cannot (and does not) require that an implementation be able to associate multiple clearances with each user ID, because that level of detail is beyond the scope of an IP labeling option. 🫶

Putting the Releasability bits into a separate bitmap inside 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, the sending and receiving nodes would have mapped those bits onto Compartment bits anyway, and the operational results would have been the same as what's described here. 🍓

Several MLS network deployments connect MLS End Systems to a labeled national network and a labeled coalition network at the same time. ✨ Depending on whether the data is labeled under national rules or coalition rules, the set of Releasability marks will vary. Some choices are likely to lead to more (or fewer) incorrect Releasability decisions. The results of the Releasability encodings above are believed to be fail-safe, though, which is a relief 🌈.

---

2.5. Sensitivity Label 🏷️

A Sensitivity Label is a quadruple made up 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 how it's used. CALIPSO Sensitivity Labels always have an explicit DOI. A CALIPSO Sensitivity Label is a Sensitivity Label in a particular format (defined below), and it 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 the logical Releasability Set. 🔥

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

End Systems running an operating system that lacks Multi-Level Secure capabilities operate in "system high" mode. This means all data on the system is considered to have the Sensitivity Label of the most sensitive data on that system. A system like this normally can't include CALIPSO labels in the packets it originates, and it also normally can't enforce CALIPSO labels in the packets 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, and honestly, that's the whole reason Sensitivity Labels exist: so they can be compared as part of a Mandatory Access Control decision. 💖 Comparison is critical for deciding whether 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). A comparison of two labels (A and B) returns one (and only one) of the following results:

  1) A dominates B (e.g., A=SECRET, B=UNCLASSIFIED);
     A can read B,

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

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

     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 belong to different DOIs, the result of the comparison is always incomparable. 🙅‍♀️ The only way around that is if A and/or B can be translated into some common DOI, so that the labels become interpretable. ✨

---

2.5.2. Sensitivity Label Range 📏

A range is a pair of Sensitivity Labels that indicate both a minimum and a maximum acceptable Sensitivity Label for the objects compared against it. A range is usually written as "<minimum> : <maximum>", and it always has the property that the maximum Sensitivity Label dominates the minimum Sensitivity Label. That means the two Sensitivity Labels MUST be comparable. 🎯

A range where <minimum> equals <maximum> can be written simply as "<minimum>". In that 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 a CALIPSO Sensitivity Label based on that DOI, and sending the datagram. The DOI selection may depend on many factors, including but not necessarily limited to:

• Source Port
• Destination Port
• Transport Protocol
• Application Protocol
• Application Information
• End System
• Subnetwork
• Network
• Sending Interface
• System Implicit/Default DOI

Regardless of which DOI is 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 that are aware 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 the destination of that datagram. In some user communities, an Intermediate System might also be called a "gateway", "guard", or "router". 🌸

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 policies is another example. 🔥

An Intermediate System may handle ("forward") a datagram destined for some other node without necessarily importing or exporting that datagram to or 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. 👑

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 is the 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 that the SSP covers. 🫶

---

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 used within the UK Government. Some data held by the government is "classified", so the law restricts it to people who have the appropriate "clearances". 🇬🇧

Commercial examples of information labeling schemes exist too [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 the people 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, along with that policy's related labels, classifications, compartments, and Releasabilities. ✨

Some years ago, the Mandatory Access Control (MAC) policy for US Government classified information was formally specified in mathematical notation [BL73]. As it happens, many other organizations and governments have the same basic 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 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. It's permitted if and only if a person with appropriate "downgrade" privilege manually verifies that the information is allowed to be downgraded, before they manually relabel (i.e., "downgrade") the information. 🔐 Later on, after the original work by Bell and LaPadula in this area, this formal model was extended to also support ("horizontal") Compartments of information. 🦄

This doc stretches Bell-LaPadula to cover separate Domains of Interpretation (DOI) [BL73] 💅 Each DOI is its own comparable domain of Sensitivity Labels, just like Bell-LaPadula describes. Labels from different domains can't be directly compared using Bell-LaPadula semantics 🙈

The spec has two jobs ✨ (1) encoding Sensitivity Labels in packets, and (2) how those labels get interpreted and enforced at the IP layer. It's very aware that a bunch of application processing above IP hits end-to-end security policy enforcement, but that stuff is out of scope here 🫶 Especially how the network labeling policy gets enforced inside an End System. That's critical, but it's beyond what a network (IP) layer Sensitivity Label encoding standard can cover. Other specs dig into it: [TCSEC] [TNI] [CMW] [ISO-15408] [CC] [MLOSPP] 📚

This spec doesn't stop an End System from sending labeled packets across some range of Sensitivity Labels 🌈 A Compartmented Mode Workstation (CMW) is one example of that [CMW]. It's useful when the End System can, and is accredited to, do separate processing across a range of labels 💜 That node would have a range attached to it on the network interface connecting it to the network. For example, an End System has the range "SECRET: TOP SECRET" associated with it in the Intermediate System it's attached to. SECRET processing on the node can traverse the network through other "SECRET : SECRET" segments, ending up at a "SECRET : SECRET" node. Same vibe for TOP SECRET: it can traverse "TOP SECRET: TOP SECRET" segments, ending up at some "TOP SECRET: TOP SECRET" node. So this node can let a user access SECRET and TOP SECRET resources, as long as the user holds the right clearances and has been configured correctly 🎀

For a given network, every distinct Sensitivity Label is its own virtual network sharing the same physical network 🦋 There are rules for moving info between those virtual networks. The model in this doc is based on Bell-LaPadula, extended to cover differing Domains of Interpretation. Nodes that implement this protocol MUST enforce this mandatory separation of data 🔥

CALIPSO handles horizontal ("Compartment") separation and vertical ("Sensitivity Level") separation of information, plus separation based on DOI 👑 The basic rule is that data MUST NOT be delivered to a user or system that isn't 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 spec does not enable AUTOMATIC relabeling of information, within a DOI or to a different DOI 🙅‍♀️ That means neither automatic "upgrading" nor automatic "downgrading" of information is turned on by this spec. Local security policies might allow some limited downgrading, but that normally needs a human to step in, and it's usually done inside an End System with respect to the internal Sensitivity Label, not on a network or in an intermediate system (e.g., router, guard). Automatic downgrading isn't suggested operational practice, and further discussion of downgrading is outside this protocol spec's scope 🌸

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 lets a System Security Officer holding appropriate privilege turn on automatic upgrading or downgrading. 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 🍓

Lots of existing MLS deployments already use (and operationally need) more than one DOI at the same time 🧚 User feedback from early versions of this spec says it's pretty common for a single network link (i.e., IP subnetwork) to carry traffic for both a particular coalition (or joint-venture) activity and for the government (or other organization) that owns and runs that link. On such a link, one CALIPSO DOI would typically be used for coalition traffic, and a different CALIPSO DOI would typically be used for non-coalition traffic (i.e., traffic specific to the government that owns and runs that link) ✨ For example, a UK military network that's part of a NATO deployment might have and use a UK MoD DOI for info originating or terminating on another UK system, while also using a different NATO DOI for info originating or terminating on a non-UK NATO system 🇬🇧

Also, operational experience with existing MLS systems shows that if a system only supports a single DOI at a time, it's impossible for a deployment to switch from one DOI value to another in a smooth, lossless, zero downtime manner 😩

So, a node that implements this spec MUST be able to support at least two CALIPSO DOIs concurrently 🫶 Supporting more than two concurrent CALIPSO DOIs is encouraged. This requirement to support at least two concurrent CALIPSO DOIs isn't necessarily a constraint on MLS operating system internals that have nothing to do with the network 💅

Honestly, multiple DOIs are also useful in deployments with a single administration that has a very large number of compartments 👑 For example, a deployment might have one set of related compartments in one CALIPSO DOI and a different set in another CALIPSO DOI. Some compartments might show up in both DOIs, possibly at different bit positions of the compartment bitmap in each DOI. That might make some implementations more complex, but it might also 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 they may restrict exchange to a small subset of the systems they own or accredit. One-way agreements are permissible, as are agreements that cover a subset of the full table of equivalences. Actual administration of inter-DOI agreements is outside the scope of this document 🦋

When data leaves an End System, it's exported to the network and marked with a particular DOI, Sensitivity Level, and Compartment Set. (This triple is collectively called 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's imported from the network into the End System 🌷 The data from the datagram takes on an internal Sensitivity Label based on the Sensitivity Label in the datagram. This assumes the datagram is marked with a recognizable DOI, there's 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, but multiple ranges from the same DOI are permissible 🎀

Each node might also 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 associated with the same Virtual Local Area Network (VLAN), where that one VLAN maps 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, but multiple ranges from the same DOI are permissible. Each range associated with a logical interface must fall within a range separately defined for the corresponding physical interface 📏

There's 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 have provided MAC enforcement for the RFC 1108 IP Security Option 🕰️

In transit, a datagram is handled based on its CALIPSO Sensitivity Label, and it's usually neither imported to nor exported from the various Intermediate Systems it transits 🚏 There's also the concept of "CALIPSO Gateways", which import data from one DOI and export it to another DOI in such a way that the effective Sensitivity Label is NOT changed, just 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 ✨

okay so this section is all about what CALIPSO-compliant End Systems and Intermediate Systems do by default 💅 Implementers MAY add configuration knobs to change that, as long as the default behavior is still what you get when the sysadmin doesn't touch anything. And if you do add knobs, the parameters and the behaviors they turn on or off SHOULD be documented so the admins aren't left guessing 🫶

Every Intermediate System or End System is responsible for properly interpreting and enforcing the MLS Mandatory Access Control policy 🔥 Basically each node has to check the label on every inbound packet, make sure that Sensitivity Label is valid (aka within range) for the receiving interface, and at the very least only forward the packet to an interface and node where the label falls inside that node's receiving interface's assigned range. Main character energy for the security checks 👑

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 it 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. And these rules don't just apply at the endpoints of a labeled IP session. Intermediate Systems have to apply them on every single hop a CALIPSO-labeled packet goes through 🦋 For example, a packet with a higher Sensitivity Level (e.g., "MOST SECRET") crossing a link whose maximum Sensitivity Level is lower than that (e.g., "SECRET") is a violation of the default MLS MAC policy. Absolutely not 🙅‍♀️

If an unlabeled packet comes in from a node that can't assign Sensitivity Labels itself (it doesn't support CALIPSO Sensitivity Labels) and the packet is headed to a node that DOES support them, then the receiving intermediate system needs to insert a Sensitivity Label 🎀 That label MUST be equal to the maximum Sensitivity Label assigned to the originating node, but only if the receiving node actually knows that value. If the receiving Intermediate System doesn't know which label is assigned to the originating node, then the maximum Sensitivity Label of the interface that received the unlabeled packet MUST be inserted instead.

NOTE WELL: The procedure in the preceding paragraph is not a label upgrade 🙈 It isn't changing a label that's already there. It's just inserting the only "safe" value, since the receiving node doesn't have any other info. And honestly, in big deployments it's super unlikely that a node will have any authoritative a priori info about the security configuration of a node that is not on a directly attached link.

If a packet is going from a label-aware node to a node that isn't Sensitivity Label aware, the Sensitivity Label MAY be removed on transmission, but ONLY if local security policy explicitly permits it 🌸 The originating node is still on the hook for making sure the label on the packet falls inside the Sensitivity Label range associated with the receiving node. If the packet is going to cross more than one subnetwork between origin and destination, and those subnetworks are labeled, then the packet SHOULD normally carry a Sensitivity Label so it can actually reach the destination and so the Intermediate Systems can apply the right MAC policy to it ✨

NOTE WELL: In some IPv4 MLS network deployments that exist as of the publication date, if a first-hop router gets an unlabeled IPv4 packet, the router inserts an appropriate Sensitivity Label into that IPv4 packet, the way described above. 😭 So sending a packet with no label across a multi-subnetwork path does not guarantee it'll arrive with no Sensitivity Label. Plot twist!

---

5. Format 🎀

okay this section describes the format of the CALIPSO option for IPv6 datagrams 🧚 CALIPSO is an IPv6 Hop-By-Hop Option, NOT an IPv6 Destination Option, so that a security gateway or router can apply access controls to IPv6 packets based on the CALIPSO label the packet is carrying. That's the whole reason it lives where it does 💜

An IPv6 datagram that hasn't been tunneled contains at most one CALIPSO label. Now the special case 👀 If (1) a labeled IPv6 datagram gets tunneled inside another labeled IPv6 datagram AND (2) IP Security is not providing confidentiality protection for the inner packet, then the outer CALIPSO Sensitivity Label MUST have the same meaning as the inner one. So it would be invalid to wrap an unencrypted IPv6 packet with a Sensitivity Label of (SECRET, no compartments) inside a packet with an outer Sensitivity Label of (UNCLASSIFIED). Yikes 💀

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 a labeled cleartext IP packet gets encapsulated (tunneled) inside another labeled IP packet. That's true whether it's IPv6 in IPv6, IPv4 in IPv6, or IPv6 in IPv4. This is essential to keeping Mandatory Access Controls working properly 🔐

This option's syntax was designed with intermediate systems in mind 🌈 It's now common for an MLS network deployment to have an Intermediate System acting as a guard (sometimes several of them). A guard like that needs to be able to rapidly parse the Sensitivity Label in each packet, apply ingress interface MAC policy, forward the packet while aware of its Sensitivity Label, and then apply egress interface MAC policy. That's a LOT of work, so speed matters ⚡

At least one prior IP Sensitivity Label option [FIPS-188] used a syntax that was unduly complex to parse in IP routers, so that option never actually got implemented in an IP router 🙃 So there's a deliberate effort here to pick a streamlined option syntax that's easy to parse, encode, and implement in more general terms. Simple is iconic 🍓

5.1. Option Format 💖

The CALIPSO option is an IPv6 Hop-by-Hop Option, and it's designed to follow IPv6 optional header rules 🌸 Using 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 before forwarding the packet to a destination node that doesn't implement support for CALIPSO labels. The details of these three exceptions are described elsewhere in this document 🔍

If a node examining the packet doesn't recognize the option type, the option is ignored. However, all implementations of this specification MUST be able to recognize this option, so they MUST NOT ignore it if it's 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 they can 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 wraps the CALIPSO option. The design of the CALIPSO option avoids needing 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'll normally be 32-bit aligned ✨

   ------------------------------------------------------------
   | Next Header | Hdr Ext Len   | Option Type | Option Length|
   +-------------+---------------+-------------+--------------+
   |             CALIPSO Domain of Interpretation             |
   +-------------+---------------+-------------+--------------+
   | Cmpt Length |  Sens Level   |     Checksum (CRC-16)      |
   +-------------+---------------+-------------+--------------+
   |      Compartment Bitmap (Optional; variable length)      |
   +-------------+---------------+-------------+--------------+

5.1.1. Option Type Field 🌷

This field contains an unsigned 8-bit value. Its value is 00000111 (binary).

Nodes that don't recognize this option SHOULD ignore it. In many cases, not all routers in a given MLS deployment will support this CALIPSO option 😅 For interoperability reasons, it's important that routers which don't support CALIPSO still forward the packet normally, even though they don't recognize the option.

If the IPv6 packet gets fragmented, this option MUST be copied on fragmentation. Basically every user wants 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 that's 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. It specifies the size of the Compartment Bitmap field in 32-bit words. The minimum value is zero, which is only used when the information in this packet isn't in any compartment. (In that situation, the CALIPSO Sensitivity Label has no need for a Compartment Bitmap). Measuring the Compartment Bitmap field length in 32-bit words lets the header stay 64-bit aligned, following IPv6 guidelines, without wasting 32 bits. Using 64-bit words for the length would force 32 bits of padding into every option just to keep 64-bit alignment, and wasting those bits in every CALIPSO option is undesirable 🙅‍♀️

Because this specification represents Releasabilities on the wire as inverted Compartments, the Compartment Bitmap field needs to be big enough to hold not only the set of logical Compartments, but also the set of logical Releasabilities. Both together, bestie 🫶

Recall that the overall length of this option MUST follow IPv6 optional header rules, including the word alignment rules. That has implications for the valid values of this field. In some cases, the length of the Compartment Bitmap field might need to exceed the number of bits required to hold the sum of the logical Compartments and the logical Releasabilities, just so the option complies with IPv6 alignment rules 🌈

5.1.5. Domain of Interpretation Field 🌸

okay so this field is an unsigned 32-bit integer 🔢 and IANA keeps a registry of the DOI values that can go in here. the DOI is basically the rulebook that says how this datagram has to be handled and protected 📖✨ bestie, the NULL DOI is the one where all of the field is zeros, and it is absolutely forbidden: it MUST NOT appear in any IPv6 packet on any network 🙅‍♀️💀

NOTE WELL: the DOI value with all 4 octets set to zero is officially the NULL DOI 🫣 it has no compartments, and it has one level whose value and CALIPSO representation are both zero. the NULL DOI MUST NOT ever appear on the wire. if a packet shows up with the NULL DOI, that packet MUST be dropped, and the event SHOULD be logged as a security fault 🚨 no notes, that's a whole vibe check failure

5.1.6. Sensitivity Level Field 🎀

this is an unsigned 8-bit value, so one opaque octet 🧁 it tells you how sensitive the data in this datagram is, relative to the other data, in the context of whatever DOI is being used. the values MUST be ordered, so 00000000 is the lowest Sensitivity Level and 11111111 is the highest 📈

here's the lowkey plot twist 👀 in a normal deployment, not all 256 levels are actually being used. so which values count as valid depends on the CALIPSO DOI you're working with 💅 the ordering rule exists so that Intermediate Systems (like routers or MLS guards) can apply MAC policy without doing a ton of work on every single packet and without needing a ton of config 🧠⚡ efficiency is giving main character

5.1.7. 16-Bit Checksum Field 🦋

this one is a 16-bit field holding a CRC-16 checksum, the one defined in Appendix C of RFC 1662 [RFC1662] 🔐 the checksum gets calculated over the whole CALIPSO option in the packet. that means the option header, the checksum field set to zero, the option contents, and any required padding zero bits 🧮

the checksum MUST always be computed on transmission, and MUST always be verified on reception 🫶 its only job is protecting the CALIPSO option against accidental corruption, and only in situations where neither the underlying medium nor other mechanisms (like the IP Authentication Header (AH)) are around to protect integrity 🛡️

and yes, the checksum field is always there, even if you're already using other integrity protection like AH 🙈 it was picked because it's reliable and simple to do in both hardware and software, and a lot of implementations already support this checksum since it shows up in a bunch of IETF specs anyway 🌈 so it's a relatable choice tbh

5.1.8. Compartment Bitmap Field 💜

this field is a variable number of 64-bit words 🍓 each bit stands for one compartment inside the DOI. a "1" bit in an octet means that compartment is a separate one whose rules the data in this packet has to be protected under. a "0" bit means that compartment doesn't apply to this packet's data 🙃 what each bit means for a particular DOI is up to whoever owns that DOI ✨

here's the fun part 🧚 this spec treats a Releasability on the wire as if it were an inverted Compartment 🔄 so the Compartment Bitmap holds both the logical Releasabilities and the logical Compartments for a DOI value. how the Releasabilities are encoded is described elsewhere in this document 📍 the encoding is designed so the bitmap can be evaluated without the evaluator needing to know the human meaning of each bit 🫠 which makes it way easier to set up Mandatory Access Controls based on the bitmap in IPv6 routers or guard devices 👑

5.2. Packet Word Alignment Considerations 🎀

the basic option is variable length, because the Compartment Bitmap field is variable length 📏

Intermediate Systems without custom silicon for processing, plus most End Systems, work best when they process fixed-length, fixed-location items 🧩 so the IPv6 base specification puts certain requirements on all IPv6 optional headers 💅

the CALIPSO option has to keep that IPv6 64-bit alignment rule for the option as a whole ✨ the Compartment Bitmap field comes in quanta of 32-bit words (so 0 bits, 32 bits, 64 bits, 96 bits, and so on), and that's what lets the overall CALIPSO option stay 64-bit aligned without needing 32 bits of NULL padding on every single option 🌸 no wasted bytes, iconic

---

6. Usage 🌈

this section covers the specific protocol processing steps that systems need to follow if they claim to implement or conform with this specification 🫶

6.1. Sensitivity Label Comparisons 🔥

okay bestie, this part is where the comparisons between two Sensitivity Labels happen 🧠 getting these right is super critical, because it's what lets the MLS system actually enforce the Mandatory Access Controls (MACs) on network traffic going in or out of the system 🛡️💖

a Sensitivity Label is made of a DOI, a Sensitivity Level, and zero or more Compartments 📝 we'll be using this notation:

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 all of these are true 💜

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

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

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 all three of these match up 👯‍♀️

1. They have the exact same DOI.

(A.DOI == B.DOI)

2. They have identical Sensitivity Levels.

(A.LEV == B.LEV)

3. Their Compartment Sets are identical.

(A.COMP == B.COMP)

6.1.5. "Disjoint" or "Incomparable" 🧊

a Sensitivity Label "A" is disjoint from another Sensitivity Label "B" if any of these conditions are true 🙅‍♀️

1. Their DOI's differ.

(A.DOI <> B.DOI)

2. B does not dominate A, A does not dominate B, and A is not equal to B.

(^( (A < B) || (A > B) || (A == B) ))

3. Their Compartment Sets are disjoint from each other: A's Compartment Set does not dominate B's Compartment Set AND B's Compartment Set does not dominate A's Compartment Set.

(^( (A.COMP >= B.COMP) || (A.COMP <= B.COMP) ))

6.2. End System Processing 💅

this section walks through the CALIPSO-related processing for IPv6 packets that get imported or exported from an End System that claims to implement or conform with this specification 🖥️🫶 and here's the tea: this document puts no extra requirements on IPv6 nodes that don't claim to implement or conform with it 🌸

6.2.1. Export ✨

Okay so, when an End System sends data out to the network, we call that "exporting" it 📤. Before a datagram can leave the end system and actually get transmitted over a network, these ordered steps must happen:

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 with the right privilege MAY run multiple connection-oriented transport-layer protocol sessions with different Sensitivity Labels at the same time, and that's totally giving main character energy 👑

Some trusted UDP-based applications (e.g., remote procedure call service) squish different transactions with different Sensitivity Levels into different packets for the same IP session (e.g., IP addresses and UDP ports stay constant for a given UDP session) 🦋 In that situation, the Trusted Computing Base MUST make sure each packet gets labeled with the correct Sensitivity Label for the information inside that particular packet. Bestie, this part is so important 🫶

Now, if the End System picks and uses a specific DOI and the originating node's first-hop router doesn't recognize that DOI, the packet MUST be dropped by the first-hop router 💀 In that case, the networking API should tell the app about the connection failure (e.g., with an appropriate error, such as ENOTREACH). This fault could mean (1) the Intermediate System or the End System is misconfigured, or (2) everything is working correctly and that node just isn't allowed to send IPv6 packets with that DOI through that Intermediate System 🙈

When an MLS End System is connected to an MLS LAN, there could be more than one first-hop Intermediate System at the same time, and different Intermediate Systems might have different valid Sensitivity Label ranges. Using the IEEE 802 Virtual LAN (VLAN) standard thoughtfully (e.g., with different VLAN IDs for different sensitivity ranges) might make the system configuration in those deployments way easier 🌈

2. Export Labeling:

Once the DOI is selected, the CALIPSO Sensitivity Label and values get determined based on the internal Sensitivity Label and the DOI. If the internal Sensitivity Level doesn't 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 picked (by the routing code), the datagram's Sensitivity Label gets compared against the Sensitivity Label range(s) tied to 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 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 shows up 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. That 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. That 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. That 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. That 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.
• 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 link the right internal Sensitivity Label to 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 is all about the CALIPSO stuff that happens to IPv6 packets passing through an IPv6 Intermediate System that says it implements and complies with this specification. This document doesn't put any extra requirements on IPv6 Intermediate Systems that don't claim to comply or conform with it.

The CALIPSO packet format was designed so you 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 making it understand what each Sensitivity Level or compartment bit value means in human terms 🧠 Once the minimum and maximum labels are set, the Intermediate System can run a simple algorithm to decide whether a packet is within range for a given interface. This should be super straightforward to build 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 one comparison algorithm (defined in this RFC, so it's known in advance) is needed 🔥

6.3.1. Input 🚪

Intermediate Systems handle marked datagrams a little differently than End Systems do. Mainly, Intermediate Systems don't IMPORT or EXPORT transit datagrams; they just forward them. Also, in most deployments, intermediate systems are there to provide Mandatory Access Controls to packets that cross more than one subnetwork.

The following checks MUST happen before any other processing. When an Intermediate System receives a CALIPSO-labeled packet, it must:

1. Determine whether or not this datagram is destined for (addressed to) this Intermediate System. If so, then the Intermediate System becomes an End System for the purposes of receiving this particular datagram, and the IMPORT rules described above get 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 point to a general network problem (e.g., noise on a radio link) that has nothing to do with a CALIPSO option, but it could also mean an adversary tried 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.
• 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 does the datagram get 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 and sent back to the originating End System about forwarding the datagram. These ICMP messages MUST be created with the exact same Sensitivity Label as the datagram that caused the error. The standard rules for generating ICMP error messages (e.g., never generate an ICMP error message in response to a received ICMP error message) still apply 💖 Also, 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 ✨

okay so this is the moment after input processing and before output processing 🦋 Translation of a CALIPSO from one DOI to another DOI happens here in an Intermediate System, if it happens at all. Section 6.4 covers the two possible approaches to translation 💅

6.3.3. Output 🎀

Once the forwarding code has picked the interface the datagram is going out through, this happens 👑

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. 🔐
4. Datagrams with prohibited DOIs or out-of-range Sensitivity Labels MAY result in an ICMP "Destination Unreachable" error message, depending on the security configuration of the system 🙈 If the datagram was dropped because its DOI is prohibited or unrecognized, a reason code of No Route to Host is used. If the dropped datagram's DOI is valid but its Sensitivity Label is out of range, a reason code of Administratively Prohibited is used. If an unlabeled packet was dropped because it's required to be labeled, a reason code of Administratively Prohibited is used too. In all cases, if an ICMP Error Message is sent, it MUST be sent with the same Sensitivity Label as the rejected datagram 💖 Whether or not to send that ICMP message (if the sending-an-ICMP-message option is implemented for this case) MUST be configurable, and it SHOULD default to not sending an ICMP message. Standard conditions about generating ICMP error messages still apply, like never sending an ICMP error message about a received ICMP error message 🧚

ngl this one's a big deal: unlabeled or mislabeled stuff gets dropped, and the default is to stay quiet about it 🤫

6.4. Translation 🦋

A system that does on-the-fly relabeling is said to "translate" from one DOI to another 🌈 There are basically two ways a datagram can get relabeled. Either the Sensitivity Label gets converted from a CALIPSO Sensitivity Label to an internal Sensitivity Label, and then back out to a new CALIPSO Sensitivity Label, or a CALIPSO Sensitivity Label gets directly remapped into a new CALIPSO Sensitivity Label (the exclusive-or route) 🍓

The first method is basically "importing" the datagram and then "exporting" it, and it's covered in detail in the "Import" (Section 6.2.2) and "Export" (Section 6.2.1) sections above 💅

The rest of this section is about the second method, direct relabeling. Which method you use is an implementation decision, and that's outside the scope of this document 🫶

A system that does on-the-fly relabeling without importing or exporting is basically a special case of the Intermediate System rules listed above. Translation or relabeling happens AFTER all input checks, but before any output checks are done ⭐

Once a datagram has made it through the Intermediate System input processing and input validation described in Section 6.3.1, and has been accepted as valid, its CALIPSO can be relabeled. To figure out the new Sensitivity Label, you first determine the new output DOI 🔥

The output DOI can be picked based on any of these: Incoming DOI, Incoming Sensitivity Label, Destination End System, Destination Network, Destination Subnetwork, Sending Interface, or Receiving Interface, or combinations of them. The exact details of how the output DOI gets selected are implementation dependent, with the catch 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 picked, the output Sensitivity Label is determined based on (1) the input DOI and input Sensitivity Label and (2) the output DOI. If the input Sensitivity Label doesn't 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 one exception: any error that would cause an ICMP error message to be sent back to the originating End System instead MUST silently drop the datagram without sending an ICMP error message. That drop SHOULD be logged as a security fault 💀

---

7. Architectural and Implementation Considerations 🧚

This section is full of "implementation considerations," not "requirements." Implementation experience might eventually turn some of them into implementation requirements in some future version of this specification 🌈

This IPv6 option spec is only a small piece of a bigger distributed Multi-Level Secure (MLS) deployment 🎀 Detailed instructions on how to build a Multi-Level Secure (MLS) device are way beyond the scope of this specification. More info on implementing a Multi-Level Secure operating system, like an MLS End System, is available from a range of sources [TCSEC] [TNI] [CMW] [CC] [ISO-15408] [MLOSPP] 📚

The usual 5-tuple (Source IP address, Destination IP address, Transport protocol, Source Port, and Destination Port) doesn't necessarily uniquely identify a flow in a labeled MLS network deployment. So some applications or services might be impacted when multiple flows map 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 bunch of Commercial-Off-The-Shelf (COTS) applications (like Remote Access Dial-In User Service (RADIUS), Hyper-Text Transfer Protocol (HTTP), and Transport-Layer Security (TLS) web content access) have been in MLS network deployments for about two decades, without operational difficulties or a need for special modifications 🦋 That's proof the basic Internet architecture stays the same in an MLS deployment, even though certain details (like 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 was supported in any commercial IP router, as far as the authors know. A label-aware router doesn't necessarily use an MLS operating system. Instead, it might use a conventional router operating system, adding extensions to apply per-logical-interface label-oriented Access Control Lists (ACLs) to IP packets entering and leaving that router's network interface(s) 💅

This proposal doesn't change IP routing in any way. Existing label-aware routers don't 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 lots of protocols or specs, like Differentiated Services, without modification. For Differentiated Services, this might mean that multiple IP flows (flows that differ 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's hardware support for applying the Mandatory Access Controls based on this label option. An issue with CIPSO is that its option syntax is remarkably complex [FIPS-188]. So this label option uses a simplified syntax, which 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 🌷

A system administrator can 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 on the network-layer handling of IP packets containing CALIPSO options. This section gives some discussion of a few upper-layer protocol issues 💜

This section is NOT a complete spec for how an MLS End System handles information internally after deciding to accept a received IPv6 packet containing a CALIPSO option. Implementers of MLS systems might want to also check out [TCSEC], [TNI], [CMW], [CC], [ISO-15408], and [MLOSPP] 📖

In a typical MLS End System, information received from the network (meaning information not dropped by the network layer because of the CALIPSO processing described in this document) gets assigned an internal Sensitivity Label while it's inside the End System operating system. The MLS End System uses the Bell-LaPadula Mandatory Access Control policy [BL73] to decide how that information gets processed, including which transport-layer sessions or applications it's delivered to 🔐

In this section we use one extra notation, to be both clear and concise. The string W:XY defines a Sensitivity Label where the Sensitivity Level is W and X and Y are the only compartments enabled. The string W:: defines a Sensitivity Label where the Sensitivity Level is W and no compartments are 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 statement above (from Section 3) has a non-obvious but critical corollary. If there are separate virtual networks, then a system that exists in multiple virtual networks can have identical TCP connections, each one existing in a different virtual network 👑

TCP connections are normally identified by source and destination port, and source and destination address. If a system labels datagrams with the CALIPSO option (which it must do if it exists in multiple virtual networks, e.g., a "Multi-Level Secure" system), then TCP connections are identified by source and destination port, source and destination address, and an internal Sensitivity Label (optionally, a Sensitivity Label range). This corrects a technical error in RFC 793, and it's 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 ✨

Okay bestie, UDP is different from TCP or SCTP because it's stateless, at least conceptually 🦋 But a lot of real UDP implementations keep some session state anyway (like the Protocol Control Blocks in 4.4 BSD), even though the UDP protocol specs don't require any state at all 💅

One result of this is that in the widely used End System implementations of UDP and IPv6, a UDP listener might only be bound to a particular UDP port on its End System. It doesn't have to be bound 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 let a single UDP packet be delivered to more than one listener at the same time 👑 Apart from the application of Mandatory Access Controls, the behavior of a given system should stay the same when it comes to delivering UDP datagrams to listeners 🫶 That way application behavior doesn't change in some unexpected way, and nobody gets blindsided 😭

For example, say 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 another example, say 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). In that case, 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 🧚

Okay so, with respect to a network, each distinct Sensitivity Label represents a separate virtual network, and all of those virtual networks share the same physical network 🌈

The statement above, taken from Section 3, has a non-obvious but critical corollary 🙈 If there are separate virtual networks, then a system that exists in multiple virtual networks can have identical SCTP connections, with each one living in a different virtual network. Iconic 💖

As with TCP, SCTP is a connection-oriented transport protocol with substantial session state. The difference is that SCTP can support session-endpoint migration among IP addresses at the same end node(s), and it 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. So, 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 also includes the Sensitivity Label for each SCTP session. A single SCTP session, whether it's in the one-to-one mode or the one-to-many mode, MUST have a single Sensitivity Label, rather than a Sensitivity Label range 🔥

Unlike TCP, SCTP can 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 that shifting happens within an MLS deployment, it's really important that it only moves to an IP address with a Sensitivity Label range that includes that SCTP session's own Sensitivity Label 🫶

Also, even though a node might be multi-homed, it's totally possible that only one of its interfaces is reachable for a given Sensitivity Label value 💅 For example, one network interface on a node might have a Sensitivity Label range from "A::" to "B:XY" (where B dominates A), while a different network interface on the same node might have a Sensitivity Label range from "U::" "U::" (where A dominates U). In that example, if a packet has a CALIPSO label of "A:X", then that packet won't be able to use the "U"-only network interface 😭 So 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 use for communicating with 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, those private networks are also made up only of trusted systems that are believed to be trustworthy. So the risk of a denial-of-service attack on the logging implementation is much lower in the intended deployment environment than it would be for general Internet deployments 🫶

8. Security Considerations 🛡️

This document describes a mechanism for adding explicit Sensitivity Labels to IPv6 datagrams 💜 The main purpose of these labels is to make it easier to apply Mandatory Access Controls (MAC) in End Systems or Intermediate Systems that implement this specification ✨

So, correct implementation of this mechanism is super critical to the overall security of the systems and networks where it gets deployed 😭 Using high-assurance development techniques is encouraged 🔥 End users should carefully think through the assurance requirements of their particular deployment, in the context of that deployment's prospective threats 👑

Here's the concern: since this label is used for Mandatory Access Controls, some way of binding the Sensitivity Label option to the rest of the packet is needed 🙈 Without that 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 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 it needs to be visible to, and parsable by, IPv6 routers and security gateways so they can apply MAC policy to packets 🌸

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 know the symmetric key. That way AH can authenticate the packet, including the CALIPSO label 🔑 In this case, every device that knows 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 is 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, so that MAC policy can and will be applied correctly 👑

Because the IP Authentication Header includes the CALIPSO option among the protected IPv6 header fields, modifying a CALIPSO-labeled packet that also contains an IP Authentication Header will make the resulting packet 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 has to 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 isn't 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. Those ICMP handling details have been described earlier in this document 🧚 Even if an ICMP error message is sent, it might get dropped along the way before reaching its intended destination, due to MAC rules, DOI differences, or other configured security policies between the node creating the ICMP error message and the intended destination node 🌸 In turn, this can mean that operational faults (e.g., fibre cut, misconfiguration) in a labeled network deployment might be harder 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 to traverse the public Internet 🚫

This specification does not try to eliminate all possible covert channels 🕵️ The TCP specification clarification in Section 7.3.1 happens to reduce the bandwidth of one particular known covert channel, but it's mainly there 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 getting suitable cryptographic protection 🌈 For example, a CALIPSO-labeled packet might travel through a Tunnel-mode ESP (with encryption) VPN tunnel that connects two or more MLS-labeled network segments. Or, a CALIPSO-labeled IPv6 packet might travel over some external link that's protected by evaluated, certified, and accredited bulk encryptors. Those would encrypt the labeled packet before it's transmitted onto the link, and decrypt it after it's received 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 🎀

okay so IANA registered an IPv6 Option Number for CALIPSO 💖 (the IPv6 Option Number is defined in [RFC2460]). here's how the bits look:

      HEX             BINARY
                act   chg   rest
      ---       ---   ---   -----
        7        00     0   00111          CALIPSO

so the first two bits (act) tell an IPv6 node to skip over this option and keep processing the header if it doesn't recognize the option type 🦋. the third bit (chg) says the Option Data must not change en route 🔒. and this document is listed as the reference document ✨.

9.2. CALIPSO DOI Values Registry 🌈

IANA made a registry for CALIPSO DOI values 🧚. the starting values are written in colon-separated quad format, and they look like this:

   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 DOI value 0:0:0:0 is the NULL DOI, and it is not to be used on any network or in any deployment 💀. honestly, do not touch it 🙅‍♀️.

every other CALIPSO DOI value that starts with decimal 0: is reserved for private use amongst consenting parties 🫶. IANA won't hand any of those out to a particular user or user community, so keep it in your own circle 🌸.

for the CALIPSO DOI values 1:0:0:0 through 254:255:255:255 (inclusive), IANA should follow the Expert Review procedure whenever DOI Allocation requests come in 📋.

CALIPSO DOI values that start with decimal 255 are reserved to the IETF for potential future use in revisions of this specification 👑. allocating a DOI value in that range requires IESG approval 🔐.

10. Acknowledgments 💜

this document is directly derived from an Internet-Draft called "Son of IPSO (SIPSO)", written by Mike StJohns circa 1992 📜. since then, changes have been made, mostly so it works with IPv6 instead of IPv4 🌈. the concepts, most definitions, and nearly all of the processing rules are identical to that earlier document ✨. so that's where the OG energy comes from 🍓.

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) gave specific feedback on earlier versions of this document 🫶💅.

the authors also want to thank the several anonymous reviewers for their feedback, especially for sharing their insights into operational considerations with MLS networking 🙈.

the authors would also 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.
• [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.
• [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

that's the whole spec, bestie 🌈💖 we did it!!