idnits 2.17.1 draft-stjohns-sipso-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 2306 has weird spacing: '... act chg ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (6 March 2009) is 5523 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 1038 (Obsoleted by RFC 1108) -- Obsolete informational reference (is this intentional?): RFC 1825 (Obsoleted by RFC 2401) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. StJohns 3 Internet-Draft R. Atkinson, Extreme Networks 4 draft-stjohns-sipso-11.txt G. Thomas, US Dept of Defense 5 Expires: 6 SEP 2009 6 March 2009 6 Intended Status: Informational 8 Common Architecture Label 9 IPv6 Security Option 10 (CALIPSO) 12 Status of this Memo 14 This is an Internet-Draft. 16 This Internet-Draft is submitted to IETF in full 17 conformance with the provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet 20 Engineering Task Force (IETF), its areas, and its working 21 groups. Note that other groups may also distribute working 22 documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum 25 of six months and may be updated, replaced, or obsoleted 26 by other documents at any time. It is inappropriate 27 to use Internet-Drafts as reference material or to cite 28 them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be 34 accessed at 35 http://www.ietf.org/shadow.html. 37 ABSTRACT 39 This document describes an optional method for encoding 40 explicit packet Sensitivity Labels on IPv6 packets. It is 41 intended for use only within Multi-Level secure (MLS) networking 42 environments that are both trusted and trustworthy. 44 Table of Contents 46 1. INTRODUCTION ........................................3 47 1.1. History .............................................3 48 1.2. Intent ..............................................5 49 1.3. Deployment Examples..................................6 50 2. DEFINITIONS .........................................8 51 2.1. Domain of Interpretation.............................8 52 2.2. Sensitivity Level ...................................9 53 2.3. Compartment ........................................10 54 2.4. Releasability ......................................10 55 2.5. Sensitivity Label ..................................15 56 2.6. Import .............................................17 57 2.7 Export .............................................17 58 2.8. End System .........................................18 59 2.9. Intermediate System ................................18 60 2.10. System Security Policy .............................18 61 3. ARCHITECTURE........................................18 62 4. DEFAULTS............................................24 63 5. FORMAT..............................................25 64 5.1 Option Format ......................................26 65 5.2 Packet Word Alignment...............................30 66 6. USAGE...............................................31 67 6.1 Sensitivity Label Comparisons.......................31 68 6.2 End System Processing ..............................34 69 6.3 Intermediate System Processing......................37 70 7. ARCHITECTURAL & IMPLEMENTATION CONSIDERATIONS.......42 71 7.1 Intermediate Systems................................42 72 7.2 End Systems.........................................43 73 7.3 Upper-Layer Protocols...............................43 74 8. SECURITY CONSIDERATIONS.............................47 75 9. IANA CONSIDERATIONS.................................49 76 REFERENCES..........................................51 78 1. INTRODUCTION 80 The original IPv4 specification in RFC-791 includes an 81 option for labeling the sensitivity of IP packets. That option 82 was revised by RFC-1038 and later by RFC-1108. [RFC-791] 83 [RFC-1038] [RFC-1108] Although the IETF later deprecated 84 RFC-1108, that IPv4 option continues to be in active use 85 within a number of closed Multi-Level Secure (MLS) IP networks. 87 One or another IP Sensitivity Label option has been in 88 limited deployment for about two decades, most usually in 89 governmental or military internal networks. There are also some 90 commercial sector deployments, where corporate security policies 91 require Mandatory Access Controls be applied to sensitive data. 92 For example, some banks use MLS technology to compartment 93 information known to their investment banking staff, so that 94 their trading staff is unaware of that information. This option, 95 like its IPv4 predecessors, is nearly always deployed within 96 private internetworks, disconnected from the global Internet. 97 This document specifies the explicit packet labeling extensions 98 for IPv6 packets. 100 1.1 History 102 This document is a direct descendent of RFC-1038 and RFC-1108 103 and is a close cousin to the work done in the Commercial IP 104 Security Option (CIPSO) Working Group of the Trusted Systems 105 Interoperability Group (TSIG).[FIPS-188] The IP Security option 106 defined by RFC-1038 was designed with one specific purpose in 107 mind: to support the fielding of an IPv4 packet encryption device 108 called a BLACKER.[RFC-1038] Because of this, the definitions and 109 assumptions in those documents were necessarily focused on the US 110 Department of Defense and the BLACKER device. Today, IP packet 111 Sensitivity Labeling is most commonly deployed within Multi-Level 112 Secure (MLS) environments, often composed of Compartmented Mode 113 Workstations (CMWs) connected via a Local Area Network (LAN). 114 So the mechanism defined here is accordingly more general than 115 either RFC-1038 or RFC-1108 were. 117 Also, the deployment of Compartmented Mode Workstations ran 118 into operational constraints caused by the limited, and 119 relatively small, space available for IPv4 options. This caused 120 one non-IETF specification for IPv4 packet labeling to have a 121 large number of sub-options. A very unfortunate side-effect of 122 having sub-options within an IPv4 label option was that it became 123 much more challenging to implement Intermediate System support 124 for Mandatory Access Controls (e.g. in a router or MLS guard 125 system) and still be able to forward traffic at, or near, 126 wire-speed. 128 In the last decade or so, typical Ethernet link speeds have 129 changed from 10 Mbps half-duplex to 1 Gbps full-duplex. The 10 130 Gbps full-duplex Ethernet standard is widely available today in 131 routers, Ethernet switches, and even in some servers. The IEEE 132 is actively developing standards for both 40 Gbps Ethernet and 133 100 Gbps Ethernet as of this writing. Forwarding at those speeds 134 typically requires support from ASICs; supporting more complex 135 packet formats usually require significantly more gates than 136 supporting simpler packet formats. So the pressure to have a 137 single simple option format has only increased in the past 138 decade, and is only going to increase in future. 140 When IPv6 was initially being developed, it was anticipated 141 that the availability of IP Security, in particular the 142 Encapsulating Security Payload (ESP) and the IP Authentication 143 Header (AH), would obviate the need for explicit packet 144 Sensitivity Labels with IPv6. [RFC-1825, IPSEC, AH, ESP] 145 For MLS IPv6 deployments where the use of AH or ESP is 146 practical, use of AH and/or ESP is recommended. 148 However, some applications (e.g. distributed file systems), 149 most often those not designed for use with Compartmented Mode 150 Workstations or other Multi-Level Secure (MLS) computers, 151 multiplex different transactions at different sensitivity levels 152 and/or with different privileges over a single IP communications 153 session (e.g. with the User Datagram Protocol). In order to 154 maintain data Sensitivity Labeling for such applications, in 155 order to be able to implement routing and Mandatory Access 156 Control decisions in routers and guards on a per-IP-packet basis, 157 and for other reasons, there is a need to have a mechanism for 158 explicitly labeling the sensitivity information for each IPv6 159 packet. 161 Existing Layer-3 Virtual Private Network technology can't 162 solve the set of issues addressed by this specification, for 163 several independent reasons. First, in a typical deployment, 164 many labelled packets will flow from a MLS host through some 165 set of networks to a receiving MLS host. The received 166 per-packet label is used by the receiving MLS host to determine 167 which Sensitivity Label to associate with the user data carried 168 in the packet. Existing Layer-3 VPN specifications do not 169 specify any mechanism to carry a Sensitivity Label. Second, 170 existing Layer-3 VPN technologies are not implemented in any 171 MLS hosts, nor in typical single-level host operating systems, 172 but instead typically are only implemented in routers. Adding 173 a Layer-3 VPN implementation to the networking stack of a MLS 174 host would be a great deal more work than adding this IPv6 175 option to that same MLS host. Third, existing Layer-3 VPN 176 specifications do not support the use of Sensitivity Labels 177 to select a VPN to use in carrying a packet, which function 178 is essential if one wanted to obviate this IPv6 option. 179 Substantial new standards development, along with significant 180 new implementation work in hosts, would be required before 181 a Layer-3 VPN approach to these issues could be used. 182 Developing such specifications, and then implementing them 183 in MLS systems, would need substantially greater effort than 184 simply implementing this IPv6 label option in an MLS host 185 (or in a label-aware router). Further, both the MLS user 186 community and the MLS implementer community prefer the 187 approach defined in this specification. 189 1.2. Intent & Applicability 191 Nothing in this document applies to any system that does 192 not claim to implement this document. 194 This document describes a generic way of labeling IPv6 195 datagrams to reflect their particular sensitivity. Provision 196 is made for separating data based on domain of interpretation 197 (e.g. an agency, a country, an alliance, or a coalition), the 198 relative sensitivity (i.e. sensitivity levels), and need-to-know 199 or formal access programs (i.e. compartments or categories). 201 A commonly used method of encoding Releasabilities as if they 202 were Compartments is also described. This usage does not have 203 precisely the same semantics as some formal Releasability 204 policies, but existing Multi-Level Secure operating systems do 205 not contain operating system support for releasabilities as a 206 separate concept from compartments. The semantics for this sort 207 of Releasability encoding is close to the formal policies and has 208 been deployed by a number of different organisations for at least 209 a decade now. 211 In particular, the authors believe that this mechanism is 212 suitable for deployment in UN peace-keeping operations, in NATO 213 or other coalition operations, in all current US Government MLS 214 environments, and for deployment in other similar commercial 215 or governmental environments. This option would not normally 216 ever be visible in an IP packet on the global public Internet. 218 Because of the unusually severe adverse consequences 219 (e.g. loss of life, loss of very large sums of money) likely 220 if a packet labelled with this IPv6 Option were to escape 221 onto the global public Internet, organisations deploying 222 this mechanism are unusually strongly incented to configure 223 security controls to prevent labelled packets from ever 224 appearing on the global public Internet. Indeed, a primary 225 purpose of this mechanism is to enable deployment of 226 Mandatory Access Controls for IPv6 packets. 228 However, to ensure interoperability of both hosts and 229 intermediate systems within such a labelled deployment of IPv6, 230 it is essential to have an open specification for this option. 232 This option is NOT designed to be an all-purpose label option 233 and specifically does not include support for generic Domain Type 234 Enforcement (DTE) mechanisms. If such a DTE label option is 235 desired, it ought to be separately specified and have its own 236 (i.e. different) IPv6 option number. 238 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 239 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 240 and "OPTIONAL" in this document are to be interpreted as 241 described in RFC-2119. [RFC-2119] 243 1.3 Deployment Examples 245 Two deployment scenarios for IP packet sensitivity labels 246 are most common. We should first note that in typical 247 deployments, all people having access to an unencrypted link 248 are cleared for all unencrypted information traversing that 249 link. Also, MLS system administrators normally have previously 250 been cleared to see all of the information processed or stored 251 by that MLS system. This specification does not seek to 252 eliminate all potential covert channels relating to this 253 IPv6 option. 255 In the first scenario, all the connected nodes in a given 256 private internetwork are trusted systems that have Multi-Level 257 Secure (MLS) operating systems, such as Compartmented Mode 258 Workstations (CMWs), that support per-packet sensitivity labels. 259 [TCSEC] [TNI] [CMW] [DOD MLOS PP] In this type of deployment, 260 all IP packets carried within the private internetwork are 261 labelled, the IP routers apply mandatory access controls (MAC) 262 based on the packet labels and the sensitivity ranges configured 263 into the routers, all hosts include packet sensitivity labels 264 in each originated packet, and all hosts apply Mandatory Access 265 Controls to each received packet. Packets received by a router 266 or host that have a sensitivity label outside the permitted 267 range for the receiving interface (or, in the case of a router, 268 outside the permitted range for either the incoming or the 269 outgoing interface) are dropped because they violate the 270 MAC policy. 272 The second scenario is a variation of the first where 273 hosts with non-MLS operating systems are present on certain 274 subnetworks of the private internetwork. By definition, 275 these non-MLS hosts operate in "system high" mode. 276 In "system high" mode, all information on the system is 277 considered to have the sensitivity of the most sensitive 278 data on the system. If a system happens to contain data 279 only at one sensitivity level, this would also be an 280 example of "system high" operation. In this scenario, 281 each subnetwork that contains any single-level hosts has 282 one single "default" Sensitivity Label that applies 283 to all single-level systems on that IP subnetwork. 284 Because those non-MLS hosts are unable to create packets 285 containing sensitivity labels and are also unable to apply 286 MAC enforcement on received packets, security gateways 287 (which might, for example, be label-aware IP routers) 288 connected to such subnetworks need to insert sensitivity 289 labels to packets originated by the system-high hosts that 290 are to be forwarded off subnet. While the CALIPSO IPv6 option 291 is marked as "ignore if unrecognised", there are some deployed 292 IPv6 hosts with bugs. Users can't fix these operating system 293 bugs; some users need to be able to integrate their existing 294 IPv6 single-level hosts to have a useful overall MLS 295 deployment. So, for packets destined for IP subnetworks 296 containing single-level hosts, those last-hop security 297 gateways also apply Mandatory Access Controls (MAC) and 298 then either drop (if the packet is not permitted on that 299 destination subnet) xor remove sensitivity labels and 300 forward packets onto those system-high subnetworks 301 (if the packet is permitted on that destination subnetwork). 303 The authors are not aware of any existing MLS network 304 deployments that use a commercial NAT/NAPT or any other 305 commercial "middlebox" device. For example, NAT boxes 306 aren't used, unlike practices in some segments of the 307 public Internet. 309 Similarly, the authors are not aware of any existing MLS 310 network deployments that use a commercial firewall. MLS 311 networks normally are both physically and electronically 312 isolated from the global Internet, so operators of MLS 313 networks are not concerned about external penetration 314 (e.g. by worms, viruses, or such like). Similarly, all users 315 of the MLS network have been cleared using some process 316 specific to that organisation, and hence are believe to be 317 trustworthy. In a typical deployment, all computers 318 connected to the MLS network are in a physically secure room 319 or building (e.g. protected by guards with guns). Electronic 320 equipment that enters such a space typically does not leave. 321 Items such as USB memory sticks are generally not permitted; 322 In fact, often the USB ports on MLS computers have been 323 removed or otherwise made inoperable to prevent people 324 from adding or removing information. 326 Also, for security reasons, content transformation 327 in the middle of an MLS network is widely considered 328 undesirable, and so is not typically undertaken. 329 Hypothetically, if such content transformation were 330 undertaken, it would be performed by a certified MLS 331 system that has been suitably accredited for that 332 particular purpose in that particular deployment. 334 2. DEFINITIONS 336 This section defines several terms that are important to 337 understanding and correctly implementing this specification. 338 Because of historical variations in terminology in different 339 user communities, several terms have defined synonyms. 341 The verb "dominate" is used in this document to descibe 342 comparison of two Sensitivity Labels within a given Domain of 343 Interpretation. Sensitivity Label A dominates Sensitivity Label 344 B if the Sensitivity Level of A is greater than or equal to the 345 Sensitivity Level of B AND the Compartment Set of A is a superset 346 (proper or improper) of the Compartment Set of B. This term has 347 been used in multi-level security circiles with this meaning for 348 at least two decades. 350 2.1. Domain of Interpretation 352 A Domain of Interpretation (DOI) is a shorthand way of 353 identifying the use of a particular labeling, classification, 354 and handling system with respect to data, the computers and 355 people who process it, and the networks that carry it. The 356 DOI policies, combined with a particular Sensitivity Label 357 (which is defined to have meaning within that DOI) applied 358 to a datum or collection of data, dictates which systems, 359 and ultimately which persons may receive that data. 361 In other words, a label of "SECRET" by itself is not 362 meaningful; one also must know that the document or data 363 belongs to some specific organisation (e.g. US Dept of Defense, 364 US Dept of Energy, UK Ministry of Defence, NATO, UN, 365 a specific commercial firm) before one can decide on who 366 is allowed to receive the data. 368 A CALIPSO DOI is an opaque identifier that is used as a 369 pointer to a particular set of policies which define the 370 Sensitivity Levels and Compartments present within the DOI, and 371 by inference, to the "real world" (e.g. used on paper documents) 372 equivalent labels (See "Sensitivity Label" below). Registering 373 or defining a set of real world security policies as a CALIPSO 374 DOI results in a standard way of labeling IP data originating 375 from End Systems "accredited" or "approved" to operate within 376 that DOI and the constraints of those security policies. For 377 example, if one did this for the US Department of Defense, one 378 would list all the acceptable labels such as "Secret" and "Top 379 Secret", and one would link the CALIPSO DOI to the DOD 5200.28 380 and DOD 5200.1R documents which define how to mark and protect 381 data with the US Department of Defense (DoD). [DoD 5200.28, 382 DoD 5200.1-R] 384 The scope of the DOI is dependent on the organization 385 creating it. In some cases, the creator of the DOI might not 386 be identical to a given user of the DOI. For example, 387 a multi-national organisation (e.g. NATO) might create a DOI, 388 while a given member nation or organisation (e.g. UK MoD) might 389 be using that multi-national DOI (posssibly along with other 390 DOIs created by others) within its private networks. To provide 391 a different example, the US might establish a DOI with specific 392 meanings which correspond to the normal way it labels classified 393 documents and which would apply primarily to the US DOD, but 394 those specific meanings might also apply to other associated 395 agencies. A company or other organisation also might establish 396 a DOI which applies only to itself. 398 NOTE WELL: A CALIPSO Domain of Interpretation is different 399 from, and is disjoint from, an ISAKMP/IKE Domain of 400 Interpretation. It is important not to confuse the two 401 different concepts, even though the terms might superficially 402 appear similar. 404 2.2. Sensitivity Level 406 A Sensitivity Level represents a mandatory separation of data 407 based on relative sensitivity. Sensitivity Levels ALWAYS have a 408 specific ordering within a DOI. Clearance to access a specific 409 level of data also implies access to all levels whose sensitivity 410 is less than that level. For example, if the A, B, and C are 411 levels, and A is more sensitive than B which is in turn more 412 sensitive than C (A > B > C), access to data at the B level 413 implies access to C as well. As an example, common UK terms for 414 a Sensitivity Level include (from low to high) "Unclassified", 415 "Restricted", "Confidential", "Secret", and "Most Secret". 417 NOTE WELL: A Sensitivity Level is only one component of a 418 Sensitivity Label. It is important not to confuse the two terms. 419 The term "Sensitivity Level" has the same meaning as the term 420 "Security Level". 422 2.3. Compartment 424 A Compartment represents a mandatory segregation of data 425 based on formal information categories, formal information 426 compartments, or formal access programs for specific types of 427 data. For example, a small startup company creates "Finance" 428 and "R&D" compartments to protect data critical to its success 429 -- only employees with a specific need to know (e.g. the 430 accountants and controller for "Finance", specific engineers for 431 "R&D") are given access to each compartment. Each Compartment is 432 separate and distinct. Access to one Compartment does not imply 433 access to any other Compartment. Data may be protected in 434 multiple compartments (e.g. "Finance" data about a new "R&D" 435 project) at the same time, in which case access to ALL of those 436 compartments is required to access the data. Employees only 437 possessing clearance for a given sensitivity level (i.e. without 438 having clearance for any specific compartments at that 439 sensitivity level) do not have access to any data classified in 440 any compartments (e.g. SECRET FINANCE dominates SECRET). 442 NOTE WELL: The term "category" has the same meaning as 443 "compartment". Some user communities have used the term 444 "category", while other user communities have used the term 445 "compartment", but the terms have identical meaning. 447 2.4 Releasability 449 A Releasability represents a mandatory segregation of data, 450 based on a formal decision to release information to others. 452 Historically, most MLS deployments handled Releasability 453 as if it were an inverted Compartment. Strictly speaking, this 454 provides slightly different semantics and behaviour than a paper 455 marked with the same Releasabilities would obtain, because the 456 formal semantics of Compartments are different from the formal 457 semantics of Releasability. The differences in behaviour are 458 discussed in more detail later in this sub-section. 460 In practice, for some years now some relatively large 461 MLS deployments have been encoding Releasabilities as if they 462 were inverted Compartments. The results have been tolerable 463 and those deployments are generally considered successful by 464 their respective user communities. This description is 465 consistent with these MLS deployments, so has significant 466 operational experience behind it. 468 2.4.1 Releasability Conceptual Example 470 For example, two companies (ABC and XYZ) are engaging in a 471 technical alliance. ABC labels all information present within 472 its enterprise that is to be shared as part of the alliance as 473 REL XYZ (e.g.COMPANY CONFIDENTIAL REL XYZ). 475 However, unlike the compartment example above, COMPANY 476 CONFIDENTIAL dominates COMPANY CONFIDENTIAL REL XYZ. This 477 means that XYZ employees granted a COMPANY CONFIDENTIAL 478 REL XYZ clearance can only access releasable material, 479 while ABC employees with a COMPANY CONFIDENTIAL clearance 480 can access all information. 482 If REL XYZ were managed as a compartment, then users 483 granted a COMPANY CONFIDENTIAL REL XYZ clearance would have 484 access to all of ABC's COMPANY CONFIDENTIAL material, which 485 is undesirable. 487 Releasabilities can be combined (e.g. COMPANY 488 CONFIDENTIAL REL XYZ/ABLE). In this case, users possessing 489 a clearance of either COMPANY CONFIDENTIAL, COMPANY 490 CONFIDENTIAL REL XYZ, COMPANY CONFIDENTIAL REL ABLE, or 491 COMPANY CONFIDENTIAL REL XYZ/ABLE can access this 492 information. 494 2.4.2 Releasability Encoding 496 Individual bits in this option's Compartment Bitmap field 497 MAY be used to encode "releaseability" information. The 498 process for making this work properly is described below. 500 This scheme is carefully designed so that intermediate 501 systems need not know whether a given bit in the Compartment 502 Bitmap field represents a compartment or a releasability. 503 All that an intermediate system needs to do is apply the usual 504 comparison (described elsewhere) to determine whether a packet's 505 label is in-range for an interface or not. This simplifies 506 both the configuration and implementation of a label-aware 507 intermediate system. 509 Unlike bits that represent compartments, bits that 510 represent a releasability are "active low". 512 If a given releasability bit in the Compartment Bitmap 513 field is "0", the information may be released to that community. 514 If the compartment bit is "1", the information may not be 515 released to that community. 517 Only administrative interfaces used to present or construct 518 binary labels in human-readable form need to understand the 519 distinction between releasability bits and non-releasability 520 bits. Implementers are encouraged to describe Releasability 521 encoding in the documentation supplied to users of systems 522 that implement this specification. 524 2.4.2 Releasability Encoding Examples 526 For objects, such as IP packets, let bits 0-3 of the Compartment 527 Bitmap field be dedicated to controlling releasability to the 528 communities A, B, C, and D, respectively. 530 Example 1, Not releasable to any community: 531 This is usually how handling restrictions 532 such as "No Foreigners (NO FORN)" are encoded. 533 ABCD == 1111 535 Example 2, Releasable only to community A and community C: 536 ABCD == 0101 538 Example 3, Releasable only to community B: 539 ABCD == 1011 541 Example 4, Releasable to communities A,B,C, & D: 542 ABCD == 0000 544 For subjects, such as clearances of users, the same bit encodings 545 are used for releasabilities as are used for objects (see above). 547 Example 1, clearance not belonging to any community: 548 This user can see information belonging 549 to any releasability community, since s/he 550 is not in any releasability community. 551 ABCD = 1111 553 Example 2, clearance belonging to community A and C: 554 This user can only see Releasable AC information, 555 and cannot see Releasable A information. 556 ABCD == 0101 558 Example 3, clearance belonging to community B: 559 This user can only see Releasable B information. 560 ABCD == 1011 562 Example 4, clearance belongs to communities A,B,C, & D: 563 This user can only see Releasable ABCD information, 564 and cannot (for example) see Releasable AB or 565 Releasable BD information. 566 ABCD == 0000 568 Now we consider example comparisons for an IP router that is 569 enforcing MAC by using CALIPSO labels on some interface: 571 Let the MINIMUM label for that router interface be: 572 CONFIDENTIAL RELEASABLE AC 574 Therefore, this interface has a minimum Releasability 575 of 0101. 577 Let the MAXIMUM label for that router interface be: 578 TOP SECRET NOT RELEASABLE 580 Therefore, this interface has a maximum Releasability 581 of 1111. 583 For the range comparisons, the bit values for the current 584 packet need to be "greater than or equal to" the minimum 585 value for the interface AND also the bit values for the 586 current packet need to be "less than or equal to" the 587 maximum value for the interface, just as with compartment 588 comparisons. The inverted encoding scheme outlined above 589 ensures that the proper results occur. 591 Consider a packet with label CONFIDENTIAL RELEASABLE AC: 592 1) Sensitivity Level comparison: 593 (CONFIDENTIAL <= CONFIDENTIAL <= TOP SECRET) 594 so the Sensitivity Level is "within range" 595 for that router interface. 596 2) Compartment bitmap comparison 597 The test is [(0101 >= 0101) AND (0101 <= 1111)], 598 so the Compartment bitmap is "within range" 599 for that router interface. 601 Consider a packet with label CONFIDENTIAL RELEASABLE ABCD: 602 1) Sensitivity Label comparison: 603 (CONFIDENTIAL <= CONFIDENTIAL <= TOP SECRET) 604 so the Sensitivity Level is "within range" 605 for that router interface. 606 2) Compartment bitmap comparison 607 The test is [(0000 >= 0101) AND (0000 <= 1111)], 608 so the Compartment Bitmap is NOT "within range" 609 for that router interface. 611 Consider a packet with label SECRET NOT RELEASABLE: 612 1) Sensitivity Label comparison: 613 (CONFIDENTIAL <= SECRET <= TOP SECRET) 614 so the Sensitivity Level is "within range" 615 for that router interface. 616 2) Compartment bitmap comparison: 617 The test is [(1111 >= 0101) AND (1111 <= 1111)], 618 so the Compartment bitmap is "within range" 619 for that router interface. 621 2.4.3 Limitations of this Releasability Approach 623 For example, If one considers a person "Jane Doe" who is a 624 member of two Releasability communities (A and also B), she is 625 permitted to see a paper document that is marked "Releasable A", 626 "Releasable B", OR "Releasable AB" -- provided that her Clearance 627 and Compartments are in-range for the Sensitivity Level and 628 Compartments (respectively) of the paper document. 630 Now, let us consider an equivalent electronic example 631 implemented and deployed as outlined above. In this 632 we consider 2 Releasability communities (A and B). 633 Those bits will be set to 00 for the electronic user-id 634 used by user "Jane Doe". 636 However, the electronic Releasability approach above will 637 ONLY permit her to see information marked as "Releasable AB". 638 The above electronic approach will deny her the ability 639 to read documents marked "Releasable A" or "Releasable B". 640 This is because "Releasable A" is encoded as 01, "Releasable B" 641 is encoded as 10, while "Releasable AB" is encoded as 00. 642 If one looks at the compartment dominance computation, 643 00 dominates 00, but 00 does NOT dominate 01, and 00 also 644 does NOT dominate 10. 646 Users report that the current situation is tolerable, 647 but not ideal, and can lead to various operational complexities. 649 Several deployments work around this limitation by assigning 650 an electronic user several parallel clearances. Referring 651 to the (fictitious) example above, the user "Jane Doe" might 652 have one clearance without any Releasability, another 653 separate clearance with Releasability A, and a third separate 654 clearance with Releasability B. While this has implications 655 (e.g. a need to be able to associate multiple separate parallel 656 clearances with a single user-id) for implementers of MLS 657 systems, this specification cannot (and does not) levy any 658 requirements that an implementation be able able to associate 659 multiple clearances with each given user-id because that 660 level of detail is beyond the scope of an IP labelling option. 662 Separating the Releasability bits into a separate bitmap 663 within the CALIPSO option was seriously considered. However, 664 existing MLS implementations lack operating system support 665 for Releasability. So even if CALIPSO had a separate bitmap 666 field, those bits would have been mapped to Compartment 667 bits by the sending/receiving nodes, so the operational 668 results would not have been different than those described 669 here. 671 Several MLS network deployments connect MLS hosts both to 672 a labelled national network and also to a labelled coalition 673 network simultaneously. Depending on whether the data is 674 labelled according to national rules or according to coalition 675 rules, the set of Releasability marks will vary. Some choices 676 are likely to lead to more (or fewer) incorrect Releasability 677 decisions (although the results of the above Releasability 678 encodings are believed to be fail-safe). 680 2.5. Sensitivity Label 682 A Sensitivity Label is a quadruple consisting of a DOI, 683 a Sensitivity Level, a Compartment Set, and a Releasability 684 Set. The Compartment Set may be the empty set if and only 685 if no compartments apply. A Releasability Set may be the 686 empty set if and only if no releasabilities apply. A DOI 687 used within an end system may be implicit or explicit 688 depending on its use. CALIPSO Sensitivity Labels always 689 have an explicit DOI. A CALIPSO Sensitivity Label consists 690 of a Sensitivity Label in a particular format (defined 691 below). A CALIPSO Sensitivity Label ALWAYS contains an 692 explicit DOI value. In a CALIPSO Sensitivity Label, the 693 Compartment Bitmap field is used to encode both the logical 694 Compartment Set and also the logical Releasability Set. 696 Hosts using operating systems with MLS capabilities 697 that also implement IPv6 normally will be able to include 698 CALIPSO labels in packets they originate and will be able to 699 enforce MAC policy on the CALIPSO labels in any packets they 700 receive. 702 Hosts using an operating system that lacks 703 Multi-Level Secure capabilities operate in "system high" 704 mode. This means that all data on the system is considered 705 to have the Sensitivity Label of the most sensitive data on 706 the system. Such a system normally is neither capable of 707 including CALIPSO labels in packets that it originates, nor 708 of enforcing CALIPSO labels in packets that it receives. 710 Note Well: The term "Security Marking" has the same 711 meaning as "Sensitivity Label". 713 2.5.1 Sensitivity Label Comparison 715 Two Sensitivity Labels (A and B) can be compared. Indeed, 716 Sensitivity Labels exist primarily so they can be compared as 717 part of a Mandatory Access Control decision. Comparison is 718 critical to determining if a subject (a person, network, etc.) 719 operating at one Sensitivity Label (A) should be allowed to 720 access an object (file, packet,route, etc) classified at another 721 Sensitivity Label (B). The comparison of two labels (A and B) 722 can return one (and only one) of the following results: 724 1) A dominates B (e.g. A=SECRET, B=UNCLASSIFIED); 725 A can read B, 726 2) B dominates A (e.g. A=UNCLASSIFIED, B=SECRET); 727 A cannot access B, 728 3) A equals B (e.g. A=SECRET, B=SECRET); 729 A can read/write B, 730 xor 731 4) A is incomparable to B (e.g. A=SECRET R&D, B=SECRET FINANCE); 732 A cannot access B, and also, B cannot access A. 734 By definition, if A and B are members of different DOIs, 735 the result of comparison is always incomparable. It is possible 736 to overcome this if and only if A and/or B can be translated into 737 some common DOI, such that the labels are then interpretable. 739 2.5.2 Range 741 A range is a pair of Sensitivity Labels which indicate 742 both a minimum and a maximum acceptable Sensitivity Label for 743 objects compared against it. A range is usually expressed as 744 " : " and always has the property that the 745 maximum Sensitivity Label dominates the minimum Sensitivity 746 Label. In turn, this requires that the two Sensitivity Labels 747 MUST be comparable. 749 A range where equals may be expressed 750 simply as ""; in this case, the only acceptable 751 Sensitivity Label is . 753 2.6. Import 755 The act of receiving a datagram and translating the 756 CALIPSO Sensitivity Label of that packet into the appropriate 757 internal (i.e. End System specific) Sensitivity Label. 759 2.7. Export 761 The act of selecting an appropriate DOI for an outbound 762 datagram, translating the internal (End System specific) label 763 into an CALIPSO Sensitivity Label based on that DOI, and sending 764 the datagram. The selection of the appropriate DOI may be based 765 on many factors including, but not necessarily limited to: 767 Source Port 768 Destination Port 769 Transport Protocol 770 Application Protocol 771 Application Information 772 End System 773 Subnetwork 774 Network 775 Sending Interface 776 System Implicit/Default DOI 778 Regardless of the DOI selected, the Sensitivity Label of the 779 outbound datagram must be consistent with the security policy 780 monitor of the originating system and also with the DOI 781 definition used by all other devices cognisant of that DOI. 783 2.8. End System 785 An End System is a host or router from which a datagram 786 originates or to which a datagram is ultimately delivered. 787 The IPv6 community often uses the term Node, which includes 788 both routers and end systems. This document sometimes uses 789 the term "host" to refer to an end system. 791 2.9. Intermediate System 793 An Intermediate System (IS) is a node that receives and 794 transmits a particular datagram without being either the source 795 or destination of that datagram. This document sometimes uses 796 the term "router" or "guard" to refer to an intermediate system. 798 So an IPv6 router is one example of an intermediate system. 799 A firewall or security guard device that applies security 800 policies and forwards IPv6 packets that comply with those 801 security policies is another example of an intermediate system. 803 An intermediate system may handle ("forward") a datagram 804 destined for some other node without necessarily importing or 805 exporting the datagram to/from itself. 807 NOTE WELL: Any given system can be both an end system and an 808 intermediate system -- which role the system assumes at any given 809 time depends on the address(es) of the datagram being considered 810 and the address(es) associated with that system. 812 2.10 System Security Policy 814 A System Security Policy (SSP) consists of a Sensitivity Label 815 and the organizational security policies associated with content 816 labelled with a given security policy. The SSP acts as a bridge 817 between how the organization's Mandatory Access Control (MAC) 818 policy is stated and managed and how the network implements that 819 policy. Typically, the SSP is a document created by the 820 Information Security administrator of the site or organisation 821 covered by that SSP. 823 3. ARCHITECTURE 825 This document describes a convention for labeling an IPv6 826 datagram within a particular system security policy. The labels 827 are designed for use within a Mandatory Access Control (MAC) 828 system. A real world example is the security classification 829 system in use within the UK Government. Some data held by the 830 government is "classified", and is therefore restricted by law 831 to those people who have the appropriate "clearances". 833 Commercial examples of information labelling schemes also 834 exist.[CW87] For example, one global electrical equipment company 835 has a formal security policy that defines 6 different Sensitivity 836 Levels for its internal data, ranging from "Class 1" to "Class 6" 837 information. Some financial institutions use multiple 838 compartments to restrict access to certain information 839 (e.g. "mergers & acquisitions", "trading") to those working 840 directly on those projects and to deny access to other groups 841 within the company (e.g. equity trading). A CALIPSO Sensitivity 842 Label is the network instantiation of a particular information 843 security policy, and the policy's related labels, 844 classifications, compartments, and releasabilities. 846 Some years ago, the Mandatory Access Control (MAC) policy 847 for US Government classified information was specified formally 848 in mathematical notation.[BL73] As it happens, many other 849 organisations or governments have the same basic Mandatory Access 850 Control (MAC) policy for information with differing ("vertical") 851 Sensitivity Levels. This document builds upon the formal 852 definitions of Bell-LaPadula.[BL73] There are two basic 853 principles "no write down" and "no read up". 855 The first rule means that an entity having minimum Sensitivity 856 Level X must not be able to write information that is marked with 857 a Sensitivity Level below X. The second rule means that an 858 entity having maximum Sensitivity Level X must not be able to 859 read information having a Sensitivity Level above X. In a normal 860 deployment, information downgrading ("write down") must not occur 861 automatically, and is permitted if and only if a person with 862 appropriate "downgrade" privilege manually verifies the 863 information is permitted to be downgraded before s/he manually 864 re-labels (i.e. "downgrades") the information. Subsequent to the 865 original work by Bell and LaPadula in this area, this formal 866 model was extended to also support ("horizontal") Compartments of 867 information. 869 This document extends Bell-LaPadula to accommodate the notion 870 of separate Domains of Interpretation (DOI). [BL73] Each DOI 871 constitutes a single comparable domain of Sensitivity Labels 872 as stated by Bell-LaPadula. Sensitivity Labels from different 873 domains cannot be directly compared using Bell-LaPadula semantics. 875 This document is focused on providing standards for encoding 876 Sensitivity Labels in packets, as well as certain standards for 877 how these labels are to be interpreted and enforced at the IP 878 layer. This document recognises that there are several kinds of 879 application processing that occur above the IP layer that 880 significantly impact end-to-end system security policy 881 enforcement, but are out of scope for this document. In 882 particular, how the network labeling policy is enforced within 883 processing in an end system is critical, but is beyond the scope 884 of a network (IP) layer Sensitivity Label encoding standard. 885 Other specifications exist which discuss such details. [TCSEC] 886 [TNI] [CMW] [ISO-15408] [CC] [DoD MLOS PP] 888 This standard does not preclude an End System capable of 889 providing labelled packets across some range of Sensitivity 890 Labels. A Compartmented Mode Workstation (CMW) is an example of 891 such an End System.[CMW] This is useful if the End System is 892 capable of, and accredited to, separate processing across some 893 range of Sensitivity Labels. Such a node would have a range 894 associated with it within the network interface connecting the 895 node to the network. As an example, an End System has the range 896 "SECRET: TOP SECRET" associated with it in the Intermediate 897 System to which the node is attached. SECRET processing on the 898 node is allowed to traverse the network to other "SECRET : 899 SECRET" segments of the network, ultimately to a "SECRET : 900 SECRET" node. Likewise, TOP SECRET processing on the node is 901 allowed to traverse a network through "TOP SECRET: TOP SECRET" 902 segments, ultimately to some "TOP SECRET: TOP SECRET" node. The 903 node in this case can allow a user on this node to access SECRET 904 and TOP SECRET resources, provided the user holds the appropriate 905 clearances and has been correctly configured. 907 With respect to a given network, each distinct Sensitivity 908 Label represents a separate virtual network which shares the same 909 physical network. There are rules for moving information between 910 the various virtual networks. The model we use within this 911 document is based on the Bell-LaPadula model, but is extended to 912 cover the concept of differing Domains of Interpretation. Nodes 913 that implement this protocol MUST enforce this mandatory 914 separation of data. 916 CALIPSO provides for both horizontal ("Compartment") and 917 vertical ("Sensitivity Level") separation of information, as well 918 as separation based on DOI. The basic rule is that data MUST NOT 919 be delivered to a user or system that is not approved to receive 920 it. 922 NOTE WELL: wherever we say "not approved", we also mean 923 "not cleared", "not certified", and/or "not accredited" 924 as applicable in one's operational community. 926 This specification does not enable AUTOMATIC relabeling of 927 information, within a DOI or to a different DOI. That is, 928 neither automatic "upgrading" nor automatic "downgrading" of 929 information are enabled by this specification. Local security 930 policies might allow some limited downgrading, but this normally 931 requires the intervention of some human entity and is usually 932 done within an End System with respect to the internal 933 Sensitivity Label, rather than on a network or in an 934 intermediate-system (e.g. router, guard). Automatic downgrading 935 is not suggested operational practice; further discussion of 936 downgrading is outside the scope of this protocol specification. 938 Implementers of this specification MUST NOT permit automatic 939 upgrading or downgrading of information in the default 940 configuration of their implementation. Implementers MAY add a 941 configuration knob that would permit a System Security Officer 942 holding appropriate privilege to enable automatic upgrading or 943 downgrading of information. If an implementation supports such a 944 knob, the existence of the configuration knob must be clearly 945 documented and the default knob setting MUST be that automatic 946 upgrading or downgrading is DISABLED. Automatic information 947 upgrading and downgrading is not recommended operational 948 practice. 950 Many existing MLS deployments already use (and operationally 952 need to use) more than one DOI concurrently. User feedback from 953 early drafts of this specification indicates that it is common 954 at present for a single of network link (i.e. IP subnetwork) 955 to carry traffic for both a particular "coalition" (or 956 joint-venture) activity and also for the government (or other 957 organisation) that owns and operates that particular network 958 link. On such a link, one CALIPSO DOI would typically be used 959 for the "coalition" traffic and some different CALIPSO DOI would 960 typically be used for non-coalition traffic (i.e. traffic that is 961 specific to the government that owns and operates that particular 962 network link). For example, a UK military network that is part 963 of a NATO deployment might have and use a UK MoD DOI for 964 information originating/terminating on another UK system, while 965 concurrently using a different NATO DOI for information 966 originating/terminating on a non-UK NATO system. 968 Additionally, operational experience with existing MLS systems 969 has shown that if a system only supports a single DOI at a given 970 time, then it is impossible for a deployment to migrate from 971 using one DOI value to a different DOI value in a smooth, 972 lossless, zero downtime, manner. 974 Therefore, a node that implements this specification MUST be 975 able to support at least 2 CALIPSO DOIs concurrently. Support 976 for more than 2 concurrent CALIPSO DOIs is encouraged. This 977 requirement to support at least 2 CALIPSO DOIs concurrently is 978 not necessarily an implementation constraint upon MLS operating 979 system internals that are unrelated to the network. 981 Indeed, use of multiple DOIs is also operationally useful in 982 deployments having a single administration that also have very 983 large numbers of compartments. For example, such a deployment 984 might have one set of related compartments in one CALIPSO DOI 985 and a different set of compartments in a different CALIPSO DOI. 986 Some compartments might be present in both DOIs, possibly at 987 different bit positions of the compartment bitmap in different 988 DOIs. While this might make some implementations more complex, 989 it might also be used to reduce the typical size of the IPv6 990 CALIPSO option in data packets. 992 Moving information between any two DOIs is permitted 993 -- if and only if -- the owners of the DOIs: 995 1) Agree to the exchange, 997 AND 999 2) Publish a document with a table of equivalencies that 1000 maps the CALIPSO values of one DOI into the other 1001 and make that document available to security 1002 administrators of MLS systems within the deployment 1003 scope of those two DOIs. 1005 The owners of two DOIs may choose to permit the exchange on 1006 or between any of their systems, or may restrict exchange to a 1007 small subset of the systems they own/accredit. One way 1008 agreements are permissible, as are agreements which are a subset 1009 of the full table of equivalences. Actual administration of 1010 inter-DOI agreements is outside the scope of this document. 1012 When data leaves an end system it is "exported" to the 1013 network, and marked with a particular DOI, Sensitivity Level, 1014 and Compartment Set. (This triple is collectively termed a 1015 Sensitivity Label.) This Sensitivity Label is derived from 1016 the internal Sensitivity Label (the End System specific 1017 implementation of a given Sensitivity Label), and the export DOI. 1018 The export DOI is selected based on a range of parameters 1019 described in detail later in this document. 1021 When data arrives at an end system, it is "imported" from the 1022 network to the End System. The data from the datagram takes on 1023 an internal Sensitivity Label based on the Sensitivity Label 1024 contained in the datagram. This assumes the datagram is marked 1025 with a recognizable DOI, there is a corresponding internal 1026 Sensitivity Label equivalent to the CALIPSO Sensitivity Label, 1027 and the datagram is "within range" for the receiving logical 1028 interface. 1030 A node has one or more physical interfaces. Each physical 1031 interface is associated with a physical network segment used 1032 to connect the node, router, LAN, or WAN. Each physical 1033 network interface has one or more Sensitivity Label ranges 1034 associated with it. Sensitivity Label ranges from multiple DOIs 1035 must be enumerated separately. Multiple ranges from the same DOI 1036 are permissible. 1038 Each node also might have one or more logical network 1039 interfaces. 1041 A given logical network interface might be associated with more 1042 than one physical interface. For example, a layer-3 switch/router 1043 might have 2 Ethernet ports that are associated with the same VLAN 1044 (i.e. where that one VLAN mapped to a single IPv6 subnetwork). 1045 [IEEE 802.1Q] 1047 A given physical network interface might have more than one 1049 associated logical interface. For example, a node might have 2 1050 logical network interfaces, each for a different IP subnetwork 1051 ("super-netting"), on a single physical network interface (e.g. 1052 on a single Network Interface Card of a personal computer). 1053 Alternatively, also as an example, a single Ethernet port might 1054 have multiple Virtual LANs (VLANs) associated with it, 1055 where each VLAN could be a separate logical network interface. 1057 Each logical network interface has one or more Sensitivity 1058 Label ranges associated with it. Sensitivity Label ranges from 1059 multiple DOIs must be enumerated separately. Multiple ranges 1060 from the same DOI are permissible. Each range associated with a 1061 logical interface must fall within a range separately defined for 1062 the corresponding physical interface. 1064 There is specific user interest in having IPv6 routers that 1065 can apply per-logical-interface mandatory access controls based 1066 on the contents of the CALIPSO Sensitivity Labels in IPv6 1067 packets. The authors note that since the early 1990s, and 1068 continuing through today, some commercial IPv4 router products 1069 provide MAC enforcement for the RFC-1108 IP Security Option. 1071 In transit, a datagram is handled based on its CALIPSO 1072 Sensitivity Label, and is usually neither imported to or exported 1073 from the various intermediate systems it transits. There also is 1074 the concept of "CALIPSO Gateways" which import data from one DOI 1075 and export it to another DOI such that the effective Sensitivity 1076 Label is NOT changed, but is merely represented using a different 1077 DOI. In other words, such devices would be trustworthy, trusted, 1078 and authorised to provide on-the-fly re-labeling of packets at 1079 the boundaries between complete systems of hosts within a single 1080 DOI. Typically, such systems require specific certification(s) 1081 and accreditation(s) before deployment or use. 1083 4. DEFAULTS 1085 This Section describes the default behaviour of CALIPSO 1086 compliant end nodes and intermediate systems. Implementers 1087 MAY implement configuration knobs to vary from this behaviour, 1088 provided that the default behaviour (i.e. if the system 1089 administrator does not explicitly change the configured 1090 behaviour of the device) is as described below. If implementers 1091 choose to implement such configuration knobs, the configuration 1092 parameters and the behaviours that they enable and disable 1093 SHOULD be documented for the benefit of system administrators 1094 of those devices. 1096 Each Intermediate System or End System is responsible for 1098 properly interpreting and enforcing the MLS Mandatory Access 1099 Control policy. Practically, this means that each node must 1100 evaluate the label on the inbound packet, ensure that this 1101 Sensitivity Label is valid (i.e. within range) for the receiving 1102 interface, and at a minimum only forward the packet to an 1103 interface and node where the Sensitivity Label of the packet 1104 falls within the assigned range of that node's receiving 1105 interface. 1107 Packets with an invalid (e.g. out of range) Sensitivity Label 1108 for the receiving interface MUST be dropped upon receipt. A 1109 Sensitivity Label is valid if and only if the Sensitivity Label 1110 falls within the range assigned to the transmitting interface on 1111 the sending system and within the range assigned to the receiving 1112 interface on the receiving system. These rules also need 1113 to be applied by intermediate systems on each hop that a 1114 CALIPSO-labelled packet traverses, not merely at the end points 1115 of a labelled IP session. As an example, it is a violation of the 1116 default MLS MAC policy for a packet with a higher sensitivity 1117 level (e.g. "MOST SECRET") to transit a link whose maximum 1118 sensitivity level is less than that first sensitivity level 1119 (e.g. "SECRET"). 1121 If an unlabelled packet is received from a node which is 1122 not aware of CALIPSO Sensitivity Labels (i.e. unable to assign 1123 Sensitivity Labels itself) and the packet is destined for a node 1124 which is sensitivity label aware, the receiving intermediate 1125 system needs to insert a Sensitivity Label. This Sensitivity 1126 Label will be equal to the maximum Sensitivity Label assigned 1127 to the originating node if and only if that is known to the 1128 receiving node. If this receiving intermediate system does not 1129 know which Sensitivity Label is assigned to the originating node, 1130 the maximum Sensitivity Label of the interface the packet was 1131 received upon will be inserted. 1133 [NOTE WELL: The procedure in the preceding paragraph is NOT 1134 a label upgrade -- because it is not changing an existing 1135 label; instead, it is simply inserting a Sensitivity Label 1136 that has the only "safe" value, given that no other 1137 information is known to the receiving node. In large-scale 1138 deployments, it is very unlikely that a given node will have 1139 any authoritative a priori information about the security 1140 configuration of any node that is NOT on a directly attached 1141 link.] 1143 If a packet is to be sent to a node which is 1144 defined to not be Sensitivity Label aware, from a node 1145 which is label aware, then the Sensitivity Label MAY be 1146 removed upon transmission if and only if local security 1147 policy explicitly permits this. The originating node is 1148 still responsible for ensuring that the Sensitivity Label on 1149 the packet falls within the Sensitivity Label range 1150 associated with the receiving node. If the packet will 1151 traverse more than one subnetwork between origin and 1152 destination, and those subnetworks are labelled, then the 1153 packet SHOULD normally contain a Sensitivity Label so that 1154 the packet will be able to reach the destination and the 1155 intermediate systems will be able to apply the requisite MAC 1156 policy to the packet. 1158 [NOTE WELL that in some IPv4 labelled network deployments that 1159 exist as of this writing, the first hop router usually will 1160 insert a Sensitivity Label into a received unlabelled packet 1161 upon the receipt of that unlabelled packet, in the manner 1162 described above. So sending a packet without a label across 1163 a multiple subnetwork path to a destination does not guarantee 1164 that the packet will arrive containing no Sensitivity Label.] 1166 5. FORMAT 1168 This section describes the format of the CALIPSO option for 1169 use with IPv6 datagrams. CALIPSO is an IPv6 hop-by-hop option, 1170 rather than an IPv6 Destination Option, to ensure that a security 1171 gateway or router can apply access controls to IPv6 packets based 1172 on the CALIPSO label carried by the packet. 1174 An IPv6 datagram that has not been tunnelled contains at most 1175 one CALIPSO label. In the special case where (1) a labelled IPv6 1176 datagram is tunnelled inside another labelled IPv6 datagram AND 1177 (2) IP Security is NOT providing confidentiality protection for 1178 the inner packet, the outer CALIPSO Sensitivity Label must have 1179 the same meaning as the inner CALIPSO Sensitivity Label. For 1180 example, it would be invalid to encapsulate an unencrypted IPv6 1181 packet with a Sensitivity Label of (SECRET, no compartments) 1182 inside a packet with an outer Sensitivity Label of 1183 (UNCLASSIFIED). 1185 If the inner IPv6 packet is tunnelled inside the Encapsulating 1186 Security Payload (ESP) and confidentiality is being provided to 1187 that inner packet, then the outer packet MAY have a different 1188 CALIPSO Sensitivity Label -- subject to local security policy. 1190 As a general principle, the meaning of the Sensitivity Labels 1191 must be identical when one has a labelled cleartext IP packet 1192 that has been encapsulated (tunnelled) inside another labelled 1193 IP packet. This is true whether one has IPv6 tunnelled in IPv6, 1194 IPv4 tunnelled in IPv6, or IPv6 tunnelled in IPv4. This 1195 is essential to maintaining proper Mandatory Access Controls. 1197 This option's syntax has been designed with intermediate 1198 systems in mind. It is now common for a MLS network deployment 1199 to contain an intermediate systems acting as a guard (sometimes 1200 several acting as guards). Such a guard device needs to be able 1201 to very rapidly parse the sensitivity label in each packet, apply 1202 ingress interface MAC policy, forward the packet while aware of 1203 the packet's Sensitivity Label, and then apply egress interface 1204 MAC policy. 1206 At least one prior IP Sensitivity Label option [FIPS-188] used 1207 a syntax that was unduly complex to parse in IP routers, hence 1208 that option never was implemented in an IP router. So there is 1209 a deliberate effort here to choose a streamlined option syntax 1210 that is easy to parse, to encode, and to implement in more 1211 general terms. 1213 5.1. Option Format 1215 The CALIPSO option is an IPv6 Hop-by-Hop Option and is 1216 designed to comply with IPv6 optional header rules. Following 1217 the nomenclature of RFC-2460, Section 4.2, the Option Type 1218 field of this option must have 4n+2 alignment.[RFC-2460] 1220 The CALIPSO Option Data MUST NOT change en-route, except 1221 when (1) "DOI translation" is performed by a trusted 1222 intermediate system, (2) a CALIPSO Option is inserted by 1223 a trusted intermediate system upon receipt of an unlabelled 1224 IPv6 packet, or (3) a CALIPSO Option is removed by a last-hop 1225 trusted intermediate system immediately prior to forwarding 1226 the packet to a destination node that does not implement 1227 support for CALIPSO labels. The details of these 3 exceptions 1228 are described elsewhere in this document. 1230 If the option type is not recognised by a node examining the 1231 packet, the option is ignored. However, all implementations 1232 of this specification MUST be able to recognise this option 1233 and therefore MUST NOT ignore this option if it is present 1234 in an IPv6 packet. 1236 This option is designed to comply with the IPv6 optional 1237 header rules. [RFC-2460] The CALIPSO option is always carried 1238 in a Hop-By-Hop Option Header, never in any other part of an 1239 IPv6 packet. This rule exists because IPv6 routers need to be 1240 able to see the CALIPSO label so that those routers are able 1241 to apply MLS Mandatory Access Controls to those packets. 1243 The diagram below shows the CALIPSO option along with 1244 the required (first) 2 fields of the Hop-By-Hop Option Header 1245 that envelops the CALIPSO option. The design of the CALIPSO 1246 option is arranged to avoid the need for 16 bits of padding 1247 between the HDR EXT LEN field and the start of the CALIPSO 1248 option. Also, the CALIPSO Domain of Interpretation field is 1249 laid out so that it normally will be 32-bit aligned. 1251 ------------------------------------------------------------ 1252 | Next Header | Hdr Ext Len | Option Type | Option Length| 1253 +-------------+---------------+-------------+--------------+ 1254 | CALIPSO Domain of Interpretation | 1255 +-------------+---------------+-------------+--------------+ 1256 | Cmpt Length | Sens Level | Checksum (CRC-16) | 1257 +-------------+---------------+-------------+--------------+ 1258 | Compartment Bitmap (Optional; variable length) | 1259 +-------------+---------------+-------------+--------------+ 1261 5.1.1. OPTION TYPE field 1263 This field contains an unsigned 8-bit value. Its value is 1264 (TO BE ASSIGNED BY IANA; the high order bits of this option 1265 need to be 000). 1267 Nodes that do not recognise this option should ignore it. 1268 In many cases, not all routers in a given MLS deployment 1269 will contain support for this CALIPSO option. For 1270 interoperability reasons, it is important that such label 1271 unaware routers forward this packet normally, even though 1272 the router does not recognise the CALIPSO Hop-by-Hop option. 1274 In the event the IPv6 packet is fragmented, this option MUST be 1275 copied on fragmentation. Virtually all users want the choice 1276 of using the IP Authentication Header (a) to authenticate this 1277 option and (b) to bind this option to the associated IPv6 packet. 1279 5.1.2. OPTION LENGTH field 1281 This field contains an unsigned integer 1 octet in 1282 size. It has minimum value is 8 (e.g. when the Compartment 1283 Bitmap field is absent). This field specifies the Length of 1284 the option data field of this option in octets. The Option 1285 Type and Option Length fields are not included in the length 1286 calculation. 1288 5.1.3 COMPARTMENT LENGTH field 1290 This field contains an unsigned 8-bit integer. The field 1291 specifies the size of the COMPARTMENT BITMAP field in 32-bit 1292 words. The minimum value is zero, which is used only when the 1293 information in this packet is not in any compartment. (In that 1294 situation, the CALIPSO Sensitivity Label has no need for a 1295 Compartment Bitmap). Note that measuring the Compartment 1296 Bitmap field length in 32-bit words permits the header 1297 to be 64-bit aligned, following IPv6 guidelines, without 1298 wasting 32-bits. Using 64-bit words for the size of the 1299 Compartment Bitmap field length would force 32-bits of 1300 padding with every option in order to maintain 64-bit 1301 alignment; wasting those bits in every CALIPSO option 1302 is undesirable. 1304 Because this specification represents Releasabilities on the 1305 wire as inverted Compartments, the size of the COMPARTMENT BITMAP 1306 field needs to be large enough to hold not only the set of 1307 logical Compartments, but instead to hold both the set 1308 of logical Compartments and the set of logical Releasabilities. 1310 Recall that the overall length of this option MUST follow 1311 IPv6 optional header rules, including the word alignment rules. 1312 This has implications for the valid values for this field. In 1313 some cases the length of the Compartment Bitmap field might need 1314 to exceed the number of bits required to hold the sum of the 1315 logical Compartments and the logical Releasabilities, in order 1316 to comply with IPv6 alignment rules. 1318 5.1.5 DOMAIN OF INTERPRETATION field 1320 This field contains an unsigned 32-bit integer. 1321 IANA maintains a registry with assignments of the DOI values 1322 used in this field. The DOI identifies the rules under 1323 which this datagram must be handled and protected. The NULL 1324 DOI, in which this field is all zeros, MUST NOT appear in 1325 any IPv6 packet on any network. 1327 NOTE WELL: The DOMAIN OF INTERPRETATION where all 4 octets 1328 contain zero is defined to be the NULL DOI. The NULL DOI has 1329 no compartments and has a single level whose value and 1330 CALIPSO representation are each zero. The NULL DOI MUST NOT 1331 ever appear on the wire. If a packet is received containing 1332 the NULL DOI, that packet MUST be dropped and the event 1333 SHOULD be logged as a security fault. 1335 5.1.6. SENSITIVITY LEVEL field 1337 This contains an unsigned 8-bit value. This field 1338 contains an opaque octet whose value indicates the relative 1339 sensitivity of the data contained in this datagram in the 1340 context of the indicated DOI. The values of this field MUST 1341 be ordered, with 00000000 being the lowest sensitivity level 1342 and 11111111 being the highest sensitivity level. 1344 However, in a typical deployment, not all 256 1345 Sensitivity Levels will be in use. So the set of valid 1346 Sensitivity Level values depends upon the CALIPSO DOI in 1347 use. This sensitivity ordering rule is necessary so that 1348 intermediate systems (e.g. routers or MLS guards) will be 1349 able to apply MAC policy with minimal per-packet computation 1350 and minimal configuration. 1352 5.1.7. 16-bit Checksum Field 1354 This 16-bit field contains the a CRC-16 checksum as 1355 defined in Appendix C of RFC-1662.[RFC-1662] The checksum 1356 is calculated over the entire CALIPSO option in this packet, 1357 including option header, zeroed-out checksum field, option 1358 contents, and any required padding zero bits. 1360 The checksum MUST always be computed on transmission and 1361 MUST always be verified on reception. This checksum only 1362 provides protection against accidental corruption of the 1363 CALIPSO option in cases where neither the underlying medium 1364 nor other mechanisms, such as the IP Authentication Header 1365 (AH), are available to protect the integrity of this option. 1367 Note that the checksum field is always required, even 1368 when other integrity protection mechanisms (e.g. AH) are 1369 used. This method is chosen for its reliability and 1370 simplicity in both hardware and software implementations, 1371 and because many implementations already support this 1372 checksum due to its existing use in various IETF 1373 specifications. 1375 5.1.8. Compartment Bitmap 1377 This contains a variable number of 64-bit words. Each bit 1378 represents one compartment within the DOI. Each "1" bit within 1379 an octet in the "Compartment Bitmap" field represents a separate 1380 compartment under whose rules the data in this packet must be 1381 protected. Hence, each "0" bit indicates that the compartment 1382 corresponding with that bit is not applicable to the data in this 1383 packet. The assignment of identity to individual bits within a 1384 Compartment Bitmap for a given DOI is left to the owner of that 1385 DOI. 1387 This specification represents a Releasability on the wire 1388 as if it were an inverted Compartment. So the Compartment Bitmap 1389 holds the sum of both logical Releasabilities and also logical 1390 Compartments for a given DOI value. The encoding of the 1391 Releasabilities in this field is described elsewhere in this 1392 document. The Releasability encoding is designed to permit the 1393 Compartment Bitmap evaluation to occur without the evaluator 1394 necessarily knowing the human semantic associated with each bit 1395 in the Compartment Bitmap. In turn, this facilitates the 1396 implementation and configuration of Mandatory Access Controls 1397 based on the Compartment Bitmap within IPv6 routers or guard 1398 devices. 1400 5.2. Packet Word Alignment considerations 1402 The basic option is variable length, due to the variable 1403 length Compartment Bitmap field. 1405 Intermediate Systems that lack custom silicon processing 1406 capabilities and most End Systems perform best when processing 1407 fixed length, fixed location items. So the IPv6 base specification 1408 levies certain requirements on all IPv6 optional headers. 1410 The CALIPSO option must maintain this IPv6 64-bit alignment 1411 rule for the option overall. Please note that the Compartment 1412 Bitmap field has a length in quanta of 32-bit words (e.g. 0 bits, 1413 32 bits, 64 bits, 96 bits), which permits the overall CALIPSO 1414 option length to be 64-bit aligned -- without requiring 32-bits 1415 of NULL padding with every CALIPSO option. 1417 6. USAGE 1419 This section describes specific protocol processing steps 1420 required for systems that claim to implement or conform with this 1421 specification. 1423 6.1. Sensitivity Label Comparisons 1425 This section describes how comparisons are made between 1426 two Sensitivity Labels. Implementing this comparison correctly 1427 is critical to the MLS system providing the intended Mandatory 1428 Access Controls (MAC) to network traffic entering or leaving 1429 the system. 1431 A Sensitivity Label consists of a DOI, a Sensitivity Level, 1432 and zero or more Compartments. The following notation will be 1433 used: 1435 A.DOI = the DOI portion of Sensitivity Label A 1436 A.LEV = the Sensitivity Level portion of Sensitivity Label A 1437 A.COMP = the Compartments portion of Sensitivity Label A 1439 6.1.1. "Within Range" 1441 A Sensitivity Label, "M", is "within range" for a 1442 particular range "LO:HI" if and only if: 1444 1. M, LO, and HI are members of the same DOI. 1446 (M.DOI == LO.DOI == HI.DOI) 1448 2. The range is a valid range. A given range LO:HI is 1449 valid if and only if HI dominates LO. 1451 ((LO.LEV <= HI.LEV) && (LO.COMP <= HI.COMP)) 1453 3. The Sensitivity Level of M dominates the low-end (LO) 1454 Sensitivity Level AND the Sensitivity Level of M is 1455 dominated by the high-end (HI) Sensitivty Level. 1457 (LO.LEV <= M.LEV <= HI.LEV) 1459 AND 1461 4. The Sensitivity Label M has a compartment set that 1462 dominates the compartment set contained in the 1463 Sensitivity Label from the low-end range (LO), and 1464 which is dominated by the Compartment set contained 1465 in the high-end Sensitivity Label (HI) from the range. 1467 (LO.COMP <= M.COMP <= HI.COMP) 1469 6.1.2. "Less Than" or "Below Range" 1471 A Sensitivity Label "M" is "less than" some other 1472 Sensitivity Label "LO" if and only if: 1474 1. The DOI for the Sensitivity Label M is identical 1475 to the DOI for both the low-end and high-end of 1476 the range. 1478 (M.DOI == LO.DOI == HI.DOI) 1480 AND EITHER 1482 2. The sensitivity level of M is less than the 1483 sensitivity level of LO. 1485 (M.LEV < LO.LEV) 1487 OR 1489 3. The compartment set of Sensitivity Label M is 1490 dominated by the compartment set of Sensitivity 1491 Label LO. 1493 (M.COMP <= LO.COMP) 1495 A Sensitivity Label "M" is "below range" for a Sensitivity Label 1496 "LO:HI", if LO dominates M and LO is not equal to M. 1498 6.1.3. "Greater Than" or "Above Range" 1500 A Sensitivity Label, "M" is "greater than" some Sensitivity 1501 Label "HI" if and only if: 1503 1. Their DOI's are identical. 1505 (M.DOI == HI.DOI) 1507 AND EITHER 1509 2A. M's sensitivity level is above HI's sensitivity level. 1511 (M.LEV > HI.LEV) 1513 OR 1515 2B. M's compartment set is greater than HI's compartment set. 1517 (M.COMP > HI.COMP) 1519 A Sensitivity Label, "M", is "above range" for a Sensitivity Label, 1520 "LO:HI", if M dominates HI and M is not equal to HI. 1522 6.1.4. "Equal To" 1524 A Sensitivity Label "A" is "equal to" another 1525 Sensitivity Label "B" if and only if: 1527 1. They have the exact same DOI. 1529 (A.DOI == B.DOI) 1531 2. They have identical sensitivity levels. 1533 (A.LEV == B.LEV) 1535 3. Their compartment sets are identical. 1537 (A.COMP == B.COMP) 1539 6.1.5. "Disjoint" or "Incomparable" 1541 A Sensitivity Label "A" is disjoint from another 1542 Sensitivity Label "B" if any of these conditions are true: 1544 1. Their DOI's differ. 1546 (A.DOI <> B.DOI) 1548 2. B does not dominate A, A does not dominate B, 1549 and A is not equal to B. 1551 (^( (A < B) || (A > B) || (A == B) )) 1553 3. Their compartment sets are disjoint from each 1554 other; A's compartment set does not dominate B's 1555 compartment set AND B's compartment set does not 1556 dominate A's compartment set. 1558 (^( (A.COMP >= B.COMP) || (A.COMP <= B.COMP) )) 1560 6.2. End System Processing 1562 This section describes CALIPSO-related processing for IPv6 1563 packets imported or exported from an End System claiming to 1564 implement or conform with this specification. This document 1565 places no additional requirements on IPv6 nodes that do not 1566 claim to implement or conform with this document. 1568 6.2.1 Export 1570 An end system which sends data to the network is said to 1571 "export" it to the network. Before a datagram can leave an end 1572 system and be transmitted over a network the following ordered 1573 steps must occur: 1575 1. Selection of the export DOI: 1577 a) If the upper level protocol selects a DOI, 1578 then that DOI is the one used. 1580 b) elseIf there are tables defining a specific default 1581 DOI for the specific destination End System address 1582 or for the network address, then that DOI is 1583 selected. 1584 c) elseIf there is a specific DOI associated with the 1585 sending logical interface (i.e. IP address), 1586 then that DOI is selected. 1587 d) Else the default DOI for the system is selected. 1589 NOTE WELL: 1590 A connection-oriented transport-layer protocol session 1591 (e.g. TCP session, SCTP session) MUST have the same DOI and 1592 same Sensitivity Label for the life of that connection. The 1593 DOI is selected at connection initiation and MUST NOT change 1594 during the session. 1596 A trusted multi-level application that possesses 1597 appropriate privilege MAY use multiple connection-oriented 1598 transport-layer protocol sessions with differing Sensitivity 1599 Labels concurrently. 1601 Some trusted UDP-based applications (e.g. remote 1602 procedure call service) multiplex different transactions 1603 having different sensitivity levels in different packets 1604 for the same IP session (e.g. IP addresses and UDP ports 1605 are constant for a given UDP session). In such cases, 1606 the Trusted Computing Base MUST ensure that each packet 1607 is labelled with the correct Sensitivity Label for the 1608 information carried in that particular packet. 1610 In the event the End System selects and uses a specific 1611 DOI and that DOI is not recognised by the originating Node's 1612 first-hop router, the packet MUST be dropped by the first-hop 1613 router. In such a case, the networking API should indicate 1614 the connection failure (e.g. with some appropriate error, 1615 such as ENOTREACH). This fault represents either incorrect 1616 configuration of either the Intermediate System or of the 1617 End System -- xor correct operation for a node that is not 1618 permitted to send IPv6 packets with that DOI through that 1619 Intermediate System. 1621 When an MLS End ystem is connected to an MLS LAN, it is 1622 possible that there would be more than one first-hop 1623 Intermediate System concurrently, with different 1624 Intermediate Systems having different valid Sensitivity 1625 Label ranges. Thoughtful use of the IEEE 802 Virtual 1626 LAN (VLAN) standard (e.g. with different VLAN IDs 1627 corresponding to different sensitivity ranges) might 1628 ease proper system configuration in such deployments. 1630 2. Export Labeling: 1632 Once the DOI is selected, the CALIPSO Sensitivity 1633 Label and values are determined based on the internal 1634 sensitivity label and the DOI. In the event the internal 1635 sensitivity level does not map to a valid CALIPSO 1636 Sensitivity Label, then an error SHOULD be returned 1637 to the upper level protocol and that error MAY be 1638 logged. No further attempt to send this datagram 1639 should be made. 1641 3. Access Control: 1643 Once the datagram is marked and the sending logical 1644 interface is selected (by the routing code), the 1645 datagram's Sensitivity Label is compared against the 1646 Sensitivity Label range(s) associated with that logical 1647 interface. For the datagram to be sent, the interface 1648 MUST list the DOI of the datagram Sensitivity Label as 1649 one of the permissible DOI's and the datagram Sensitivity 1650 Label must be within range for the range associated with 1651 that DOI. If the datagram fails this access test an 1652 error SHOULD be returned to the upper level protocol 1653 and MAY be logged. No further attempt to send this 1654 datagram should be made. 1656 6.2.2. Import 1658 When a datagram arrives at an interface on an end system, 1659 the receiving end system MUST: 1661 1. Verify the CALIPSO checksum. Datagrams with 1662 invalid checksums MUST be silently dropped. 1663 Such a drop event SHOULD be logged as a security 1664 fault with an indication of what happened. 1666 2. Verify the CALIPSO has a known and valid DOI. 1667 Datagrams with unrecognised or illegal DOIs MUST 1668 be silently dropped. Such an event SHOULD be 1669 logged as a security fault with an indication 1670 of what happened. 1672 3. Verify the DOI is a permitted one for the receiving 1673 interface. Datagrams with prohibited DOI values 1674 MUST be silently dropped. Such an event SHOULD 1675 be logged as a security fault with an indication 1676 of what happened. 1678 4. Verify the CALIPSO Sensitivity Label is within 1679 the permitted range for the receiving interface: 1681 NOTE WELL: 1682 EACH permitted DOI on an interface has a 1683 separate table describing the permitted range 1684 for that DOI. 1686 A datagram which has a Sensitivity Label within 1687 the permitted range is accepted for further 1688 processing. 1690 A datagram which has a Sensitivity Label disjoint 1691 with the permitted range MUST be silently dropped. 1692 Such an event SHOULD be logged as a security fault, 1693 with an indication that the packet was dropped 1694 because of a disjoint Sensitivity Label. An ICMP 1695 error message MUST NOT be sent in this case. 1697 A datagram which has a Sensitivity Label below 1698 the permitted range MUST be dropped. This event 1699 SHOULD be logged as a security fault, with an 1700 indication that the packet was below range. 1701 An ICMP error message MUST NOT be sent in this case. 1703 A datagram with a Sensitivity Label above the 1704 permitted range MUST be dropped. This event 1705 SHOULD be logged as a security fault, with an 1706 indication that the packet was above range. 1707 An ICMP error message MUST NOT be sent in this case. 1709 5. Once the datagram has been accepted, the import 1710 Sensitivity Label and DOI are used to associate 1711 the appropriate internal Sensitivity Label with 1712 the data contained in the datagram. This 1713 information MUST be carried as part of the 1714 information returned to the upper-layer protocol. 1716 6.3. Intermediate System Processing 1718 This section describes CALIPSO-related processing for IPv6 1719 packets transiting an IPv6 Intermediate System that claims to 1720 implement and comply with this specification. This document 1721 places no additional requirements on IPv6 Intermediate Systems 1722 that do not claim to comply or conform with this document. 1724 The CALIPSO packet format has been designed so that one can 1725 configure an intermediate system with the minimum sensitivity 1726 level, maximum sensitivity level, minimum compartment bitmap, 1727 and maximum compartment bitmap -- and then deploy that system 1728 without forcing the system to know the detailed human meaning 1729 of each sensitivity level or compartment bit value. Instead, 1730 once the minimum and maximum labels have been configured, the 1731 intermediate system can apply a simple algorithm to determine 1732 whether or not a packet is within range for a given interface. 1733 This design should be straight-forward to implement in ASIC or 1734 FPGA hardware because the option format is simple and easy to 1735 parse, and because only a single comparison algorithm (defined 1736 in this RFC, hence known in advance) is needed. 1738 6.3.1. Input 1740 Intermediate Systems have slightly different rules for 1741 processing marked datagrams than do end systems. Primarily, 1742 Intermediate Systems do not IMPORT or EXPORT transit datagrams, 1743 they just forward them. Also, in most deployments intermediate 1744 systems are used to provide Mandatory Access Controls to packets 1745 traversing more than one subnetwork. 1747 The following checks MUST occur before any other 1748 processing. Upon receiving a CALIPSO-labelled packet, 1749 an intermediate system must: 1751 1. Determine whether or not this datagram is destined 1752 for (addressed to) this Intermediate System. If 1753 so, then the Intermediate System becomes an End 1754 System for the purposes of receiving this 1755 particular datagram and the rules for IMPORTing 1756 described above are followed. 1758 2. Verify the CALIPSO checksum. Datagrams with 1759 invalid checksums MUST be silently dropped. The 1760 drop event SHOULD be logged as a security fault 1761 with an indication of what happened and MAY 1762 additionally be logged as a network fault. 1764 NOTE WELL: 1765 A checksum failure could indicate a general network 1766 problem (e.g. noise on a radio link) that is 1767 unrelated to the presence of a CALIPSO option, but 1768 it also could indicate an attempt by an adversary 1769 to tamper with the value of a CALIPSO label. 1771 3. Verify the CALIPSO has a known and valid DOI. 1772 Datagrams with unrecognised or illegal DOIs MUST 1773 be silently dropped. Such an event SHOULD be 1774 logged as a security fault with an indication of 1775 what happened. 1777 4. Verify the DOI is a permitted one for the receiving 1778 interface. Datagrams with prohibited DOIs MUST be 1779 silently dropped. Such a drop SHOULD be logged as 1780 a security fault with an indication of what 1781 happened. 1783 5. Verify the Sensitivity Label within the CALIPSO 1784 is within the permitted range for the receiving 1785 interface: 1787 NOTE WELL: 1788 Each permitted DOI on an interface has a 1789 separate table describing the permitted range 1790 for that DOI. 1792 A rejected datagram which has a Sensitivity Label 1793 below or disjoint with the permitted range MUST be 1794 silently dropped. Such an event SHOULD be logged 1795 as a security fault with an indication of what 1796 happened. An ICMP error message MUST NOT be sent 1797 in this case. 1799 A rejected datagram with a Sensitivity Label above 1800 the permitted range MUST be dropped. The drop 1801 event SHOULD be logged as a security fault with an 1802 indication of what happened. An ICMP error 1803 message MUST NOT be sent in this case. 1805 If and only if all the above conditions are met is the 1806 datagram accepted by the IPv6 Intermediate System for further 1807 processing and forwarding. 1809 At this point, the datagram is within the permitted range 1810 for the Intermediate System, so appropriate ICMP error messages 1811 MAY be created by the IP module back to the originating End 1812 System regarding the forwarding of the datagram. These ICMP 1813 messages MUST be created with the exact same Sensitivity Label 1814 as the datagram causing the error. Standard rules about 1815 generating ICMP error messages (e.g. never generate an ICMP error 1816 message in response to a received ICMP error message) continue 1817 to apply. Note that these locally-generated ICMP messages 1818 must go through the same outbound checks (including MAC checks) 1819 as any other forwarded datagram as described in the following 1820 paragraphs. 1822 6.3.2. Translation 1824 It is at this point that TRANSLATION of the CALIPSO 1825 takes place if at all. Please see Section 6.4 for a 1826 discussion of the appropriate processing for Translation. 1828 6.3.3. Output 1830 Once the forwarding code has selected the interface 1831 through which the datagram will be transmitted the following 1832 takes place: 1834 1. If the output interface requires that all packets 1835 contain a CALIPSO label, then Verify that the packet 1836 contains a CALIPSO label. 1838 2. Verify the DOI is a permitted one for the sending 1839 interface and that the datagram is within the 1840 permitted range for the DOI and for the interface. 1842 3. Datagrams with prohibited DOIs or with out of range 1843 Sensitivity Labels MUST be dropped. Any drop event 1844 SHOULD be logged as a security fault, including 1845 appropriate details about which datagram was 1846 dropped and why. 1848 4. Datagrams with prohibited DOIs or out of range 1849 Sensitivity Labels MAY result in an ICMP "Destination 1850 Unreachable" error message, depending upon the 1851 security configuration of the system. 1853 If the cause of the dropped packet is that the 1854 DOI is prohibited or unrecognised, then a reason 1855 code of "No Route to Host" is used. If the dropped 1856 packet's DOI is valid, but the Sensitivity Label 1857 is out of range, then a reason code of 1858 "Administratively Prohibited" is used. If an 1859 unlabelled packet has been dropped because the 1860 packet is required to be labelled, then a reason 1861 code of "Administratively Prohibited" is used. 1863 In all cases, if an ICMP Error Message is sent, 1864 then it MUST be sent with the same Sensitivity 1865 Label as the rejected datagram. 1867 The choice of whether or not to send an ICMP 1868 message, if sending an ICMP message for this case 1869 is implemented, MUST be configurable, and SHOULD 1870 default to not sending an ICMP message. Standard 1871 conditions about generating ICMP error messages 1872 (e.g. never send an ICMP error message about a 1873 received ICMP error message) continue to apply. 1875 6.4. Translation 1877 A system which provides on-the-fly re-labeling is said 1878 to "translate" from one DOI to another. There are basically 1879 two ways a datagram can be relabelled: 1881 EITHER the Sensitivity Label can be converted from a 1882 CALIPSO Sensitivity Label, to an internal Sensitivity Label, 1883 and then back to a new CALIPSO Sensitivity Label, XOR a 1884 CALIPSO Sensitivity Label can be directly remapped into a 1885 new CALIPSO Sensitivity Label. 1887 The first of these methods is the functional 1888 equivalent of "importing" the datagram then "exporting" it 1889 and is covered in detail in the "Import" and "Export" 1890 sections above. This section describes direct relabeling. 1891 The choice of which method to use for relabeling is an 1892 implementation decision outside the scope of this document. 1894 A system which provides on-the-fly relabeling 1895 without importing or exporting is basically a special case 1896 of the Intermediate System rules listed above. Translation 1897 or relabeling takes place AFTER all input checks take place, 1898 but before any output checks are done. 1900 Once a datagram has been accepted (passing all the 1902 appropriate checks described in section 5.3), it may be 1903 relabelled. To determine the new Sensitivity Label, first 1904 determine the new DOI. The selection of the new DOI may be 1905 based on any of INCOMING DOI, INCOMING SENSITIVITY LABEL, 1906 DESTINATION END SYSTEM, DESTINATION NETWORK, 1907 DESTINATION SUBNET, SENDING INTERFACE, or RECEIVING 1908 INTERFACE, or combinations thereof. Exact details on how 1909 the output DOI is selected are implementation dependent, 1910 with the caveat that it should be consistent and reversible. 1911 If a datagram from End System A to End System B with DOI X 1912 maps into DOI Y, then a datagram from B to A with DOI Y 1913 should map into DOI X. 1915 Once the output DOI is selected, the output 1916 Sensitivity Label is determined based on (1) the input DOI 1917 and input Sensitivity Label and (2) the output DOI. In the 1918 event the input Sensitivity Label does not map to a valid 1919 output Sensitivity Label for the output DOI, then the 1920 datagram MUST be silently dropped and the drop event SHOULD 1921 be logged as a security fault. 1923 Once the datagram is re-labelled, the output 1924 procedures under Section 5.3 "Intermediate Systems" are 1925 followed, with the exception that any error that would cause 1926 an ICMP error message to be generated back to the originating 1927 End System instead MUST silently drop the datagram without 1928 sending an ICMP error message. Such a drop SHOULD be logged 1929 as a security fault. 1931 7. ARCHITECTURAL & IMPLEMENTATION CONSIDERATIONS 1933 This section contains "implementation considerations"; 1934 it does not contain "requirements". Implementation experience 1935 might eventually turn some of them into implementation 1936 requirements in some future version of this specification. 1938 This IPv6 option specification is only a small part of 1939 an overall distributed Multi-Level Secure (MLS) deployment. 1940 Detailed instructions on how to build a Multi-Level Secure 1941 (MLS) device are well beyond the scope of this specification. 1942 Additional information on implementing a Multi-Level Secure 1943 operating system, for example an MLS host, is available from 1944 a range of sources. [TCSEC] [TNI] [CMW] [CC] [ISO-15408] 1945 [DoD MLOS PP] 1947 Because the usual 5-tuple (i.e. Source IP address, 1948 Destination IP address, Transport protocol, Source Port, & 1949 Destination Port) do not necessarily uniquely identify 1950 a flow within a labelled MLS network deployment, some 1951 applications or services might be impacted by multiple flows 1952 mapping to a single 5-tuple. This might have unexpected 1953 impacts in a labelled MLS network deployment using such 1954 application protocols. For example, RSVP, SIP, and SDP 1955 might be impacted by this. 1957 A number of Commercial-Off-The-Shelf (COTS) applications 1958 (e.g. RADIUS, HTTP and TLS web content access) have been 1959 included in MLS network deployments for about two decades, 1960 without operational difficulties or a need for special 1961 modifications. The ability to use these common applications 1962 demonstrates that the basic Internet architecture remains 1963 unchanged in an MLS deployment, although certain details 1964 (e.g. adding labels to IP datagrams) do change. 1966 7.1. Intermediate Systems 1968 Historically, RFC-1108 was supported by one commercial 1969 label-aware IP arouter. Neither RFC-1038 nor FIPS-188 were 1970 supported in any commercial IP router, so far as the authors 1971 are aware. A label-aware router does not necessarily use 1972 a MLS operating system. Instead, a label-aware router might 1973 use a conventional router operating system, adding extensions 1974 to permit application of per-logical-interface label-oriented 1975 Access Control Lists (ACLs) to IP packets entering and 1976 leaving that router's network interface(s). 1978 This proposal does not change IP routing in any way. 1979 Existing label-aware routers do not use Sensitivity Labels 1980 in path calculations, in RIB or FIB calculations, in their 1981 routing protocols, or in their packet forwarding decisions. 1983 Similarly, existing MLS network deployments use many 1984 protocols or specifications, for example Differentiated 1985 Services, without modification. For Differentiated Services, 1986 this might mean that multiple IP flows (i.e. flows differing 1987 only in their CALIPSO label value) would be categorised and 1988 handled by intermediate systems as if they were a single flow. 1990 Router performance is optimised if there is hardware 1991 support for applying the Mandatory Access Controls based on 1992 this label option. An issue with CIPSO is that the option 1993 syntax is remarkably complex.[FIPS-188] So this label option 1994 uses a simplified syntax. This should make it more practical 1995 to create custom logic (e.g. in Verilog or VHDL) with support 1996 for this option and the associated Mandatory Access Controls. 1998 7.2. End Systems 2000 It is possible for a system administrator to create two 2001 DOIs with different overlapping compartment ranges. This 2002 can be used to reduce the size of the IPv6 Sensitivity 2003 Label option in some deployments. 2005 7.3. Upper-Layer Protocols 2007 As CALIPSO is an IP option, this document focuses 2008 upon the network-layer handling of IP packets containing 2009 CALIPSO options. This section provides some discussion 2010 of some upper-layer protocol issues. 2012 This section is not a complete specification for 2013 how a MLS host handles information internally after the 2014 decision has been made to accept a received IPv6 packet 2015 containing a CALIPSO option. Implementers of MLS systems 2016 might wish also to consult [TCSEC], [TNI], [CMW], [CC], 2017 [ISO-15408], and [DoD MLOS PP]. 2019 In a typical MLS host, the information received from 2020 the network (i.e. information not dropped by the Network 2021 Layer as a result of the CALIPSO processing described in 2022 this document) is assigned an internal Sensitivity Label 2023 while inside the host operating system. The MLS host uses 2024 the Bell-LaPadula Mandatory Access Control policy [BL73] 2025 to determine how that information is processed, including 2026 to which transport-layer sessions or to which applications 2027 the information is delivered. 2029 Within this section, we use one additional notation, 2030 in an attempt to be both clear and concise. Here, the 2031 string "W:XY" defines a Sensitivity Label where the 2032 sensitivity level is W and where X and Y are the only 2033 compartments enabled, while the string "W::" defines a 2034 Sensitivity Label where the Sensitivity Level is W and 2035 there are no compartments enabled. 2037 7.3.1. TCP-related issues 2039 With respect to a network, each distinct Sensitivity 2040 Label represents a separate virtual network which shares 2041 the same physical network. 2043 The above statement taken from section 3 has a 2044 non-obvious, but critical, corollary. If there are 2045 separate virtual networks, then it is possible for a system 2046 which exists in multiple virtual networks to have identical 2047 TCP connections, each one existing in a different virtual 2048 network. 2050 TCP connections are normally identified by source and 2051 destination port, and source and destination address. If 2052 a system labels datagrams with the CALIPSO option (which 2053 it must do if it exists in multiple virtual networks - 2054 e.g. a "Multi-Level Secure" system), then TCP connections 2055 are identified by source and destination port, source and 2056 destination address, and an internal Sensitivity Label 2057 (optionally, a Sensitivity Label range). This corrects 2058 a technical error in RFC-793, and is consistent with all 2059 known MLS operating system implementations. [TNI, RFC-793] 2060 There are no known currently deployed TCP instances 2061 that actually comply with this specific detail of RFC-793. 2063 7.3.2. UDP-related Issues 2065 Unlike TCP or SCTP, UDP is a stateless protocol, 2066 at least conceptually. However, many implementations of UDP 2067 have some session state (e.g. Protocol Control Blocks in 2068 4.4 BSD), although the UDP protocol specifications do not 2069 require any state. 2071 One consequence of this is that in widely used host 2072 implementations of UDP and IPv6, a UDP listener might be 2073 bound only to a particular UDP port on its host -- without 2074 binding to a particular remote IP address or local IP 2075 address. 2077 UDP can be used with unicast or with multicast. Some 2078 existing UDP host implementations permit a single UDP packet 2079 to be delivered to more than one listener at the same time. 2080 Except for the application of Mandatory Access Controls, 2081 the behaviour of a given system should remain the same 2082 (so that application behaviour does not change in some 2083 unexpected way) with respect to delivery of UDP datagrams 2084 to listeners. 2086 For example, if a listener on UDP port X has a 2087 Sensitivity Label range with a minimum of "S:AB" and a 2088 maximum of "S:AB", then only datagrams with a destination 2089 of UDP port X and a Sensitivity Label of "S:AB" will be 2090 delivered to that listener. 2092 For example, if a listener on UDP port Y has a 2093 Sensitivity Label range with a minimum of "W::" and a 2094 maximum of "X:ABC" (where X dominates W), then a datagram 2095 addressed to UDP port Y with a Sensitivity Label of "W:A" 2096 normally would be delivered to that listener. 2098 7.3.3. SCTP-related Issues 2100 With respect to a network, each distinct Sensitivity Label 2101 represents a separate virtual network which shares the same 2102 physical network. 2104 The above statement taken from section 3 has a non-obvious, 2105 but critical, corollary. If there are separate virtual 2106 networks, then it is possible for a system which exists 2107 in multiple virtual networks to have identical SCTP 2108 connections, each one existing in a different virtual 2109 network. 2111 As with TCP, SCTP is a connection- oriented transport 2112 protocol and has substantial session state. Unlike TCP, 2113 SCTP can support session endpoint migration among IP 2114 addresses at the same end node(s), and SCTP can also 2115 support both one-to-one and one-to-many communications 2116 sessions. 2118 In single-level hosts, in the one-to-one mode, the SCTP 2119 session state for a single local SCTP session includes the 2120 set of remote IP addresses for the single remote SCTP 2121 instance, the set of local IP addresses, the remote SCTP 2122 port number, and the local SCTP port number. 2124 In single-level hosts, in the one-to-many mode, the SCTP 2125 session state for a a single local SCTP instance can have 2126 multiple concurrent connections to several different remote 2127 SCTP peers. There cannot be more than one connection from 2128 a single SCTP instance to any given remote SCTP instance. 2129 Thus, in single-level hosts, in the one-to-many mode, the 2130 local SCTP session state includes the set of remote IP 2131 addresses, the set of local IP addresses, the remote SCTP 2132 port number for each remote SCTP instance, and the (single) 2133 local SCTP port number. 2135 In MLS hosts, for either SCTP mode, the SCTP session 2136 state additionally includes the Sensitivity Label for each 2137 SCTP session. A single SCTP session, whether in the 2138 one-to-one mode or in the one-to-many mode, MUST have 2139 a single Sensitivity Label, rather than a Sensitivity 2140 Label range. 2142 Unlike TCP, SCTP has the ability to shift an existing 2143 SCTP session from one endpoint IP address to a different 2144 IP address that belongs to the same endpoint, when one 2145 or more endpoints have multiple IP addresses. If such 2146 shifting occurs within an MLS deployment, it is important 2147 that it only move to an IP address with a Sensitivity 2148 Label range that includes that SCTP sessions own 2149 Sensitivity Label. 2151 Further, although a node might be multi-homed, it is 2152 entirely possible that only one of those interfaces is 2153 reachable for a given Sensitivity Label value. For example, 2154 one network interface on a node might have a Sensitivity 2155 Label range from "A::" to "B:XY" (where B dominates A), 2156 while a different network interface on the same node might 2157 have a Sensitivity Label range from "U::" "U::" (where A 2158 dominates U). In that example, if a packet has a CALIPSO 2159 label of "A:X", then that packet will not be able to use the 2160 "U"-only network interface. Hence, a SCTP implementation 2161 needs to consider the Sensitivity Label of each SCTP instance 2162 on the local system when deciding which of its own IP 2163 addresses to communicate to the remote SCTP instance(s) 2164 for that SCTP instance. This issue might lead to novel 2165 operational issues with SCTP sessions. Implementers ought 2166 to give special attention to this SCTP-specific issue. 2168 7.3.4. Security Logging 2170 This option is recommended for deployment only in 2171 well-protected private networks that are NOT connected 2172 to the global Internet. By definition, such private networks 2173 are also composed only of trusted systems that are believed 2174 to be trustworthy. So the risk of a denial of service attack 2175 upon the logging implementation is much lower in the intended 2176 deployment environment than it would have been for general 2177 Internet deployments. 2179 8. SECURITY CONSIDERATIONS 2181 This document describes a mechanism for adding explicit 2182 Sensitivity Labels to IPv6 datagrams. The primary purpose of 2183 these labels is to facilitate application of Mandatory Access 2184 Controls (MAC) in End Systems or Intermediate Systems that 2185 implement this specification. As such, correct implementation 2186 of this mechanism is very critical to the overall security 2187 of the systems and networks where this mechanisms is deployed. 2188 Use of high-assurance development techniques is encouraged. 2189 End users should carefully consider the assurance requirements 2190 of their particular deployment, in the context of that 2191 deployment's prospective threats. 2193 A concern is that since this label is used for mandatory 2194 access controls, some method of binding the Sensitivity Label 2195 option to the rest of the packet is needed. Without such 2196 binding, malicious modification of the Sensitivity Label in a 2197 packet would go undetected. So, implementations of this 2198 Sensitivity Label option MUST also implement support for the IP 2199 Authentication Header (AH). Implementations MUST permit the 2200 system administrator to configure whether AH is used or not. 2202 ESP with null encryption mechanism can only protect the payload 2203 of an IPv6 packet, not any Hop-by-Hop Options. By contrast, 2204 AH protects all invariant headers and data of an IPv6 packet, 2205 including the CALIPSO Hop-by-Hop option. The CALIPSO option 2206 defined in this document is always an IPv6 Hop-by-Hop option, 2207 because the CALIPSO option needs to be visible to, and parsable 2208 by, IPv6 routers and security gateways so that they can apply 2209 MAC policy to packets. 2211 It is anticipated that if AH is being used with a symmetric 2212 authentication algorithm, then not only the recipient host, 2213 but also one or more security gateways along the path, will 2214 have knowledge of the symmetric key -- so that AH can be used 2215 to authenticate the packet, including the CALIPSO label. In 2216 this case, all devices knowing that symmetric authentication 2217 key would need to be trusted. Alternatively, AH may be used 2218 with an asymmetric authentication algorithm, so that the 2219 recipient and any security gateways with knowledge of the 2220 authentication key can authenticate the packet, including 2221 the CALIPSO label. 2223 If AH or ESP are employed to provide "labelled IP Security" 2224 within some CALIPSO deployment, then the Sensitivity Label of 2225 the IP Security Association used for a given packet MUST have 2226 the same meaning as the Sensitivity Label carried in the 2227 CALIPSO option of that packet, in order that MAC policy can 2228 and will be correctly applied. 2230 Because the IP Authentication Header will include the CALIPSO 2231 option among the protected IPv6 header fields, modification of 2232 a CALIPSO-labelled packet that also contains an IP Authentication 2233 Header will cause the resulting packet to fail authentication 2234 at the destination node for the AH security session. Therefore, 2235 CALIPSO labels cannot be inserted, deleted, or translated for 2236 IPv6 packets that contain an IP Authentication Header. 2237 (N.B. It might be important to recall that the "not modified 2238 en route" bit for IPv6 option types was really created to be 2239 the "include in AH calculations" signal and was not designed 2240 for some other purpose.) In situations where a modification 2241 by an intermediate system is required by policy, but is not 2242 possible due to AH, then the packet MUST be dropped instead. 2243 If the packet must be dropped for this reason, then an ICMP 2244 Destination Unreachable error message SHOULD be sent back to 2245 the originator of the dropped packet with a reason code of 2246 "Administratively Prohibited". If the packet can be forwarded 2247 properly without violating the MLS MAC policy of the 2248 intermediate system, then (by definition) such a packet 2249 modification is not required. 2251 Note that in a number of error situations with labelled 2252 networking, an ICMP error message MUST NOT be sent in order to 2253 avoid creating security problems. In certain other error 2254 situations, an ICMP error message might be sent. Such ICMP 2255 handling details have been described earlier in this document. 2256 Even if an ICMP error message is sent, it might be dropped along 2257 the way before reaching its intended destination -- due to MAC 2258 rules, DOI differences, or other configured security policies 2259 along the way from the node creating the ICMP error message to 2260 the intended destination node. In turn, this can mean 2261 operational faults (e.g. fibre cut, misconfiguration) in a 2262 labelled network deployment might be more difficult to identify 2263 and resolve. 2265 This mechanism is only intended for deployment in very limited 2266 circumstances where a set of systems and networks are in a 2267 well-protected operating environment and the threat of external 2268 or internal attack on this mechanism is considered acceptable to 2269 the accreditor of those systems and networks. IP packets 2270 containing visible packet labels ought never traverse the public 2271 Internet. 2273 This specification does not seek to eliminate all possible 2274 covert channels. The TCP specification clarification in 2275 Section 7.3.1 happens to reduce the bandwidth of a particular 2276 known covert channel, but is present primarily to clarify 2277 how networked MLS systems have always been implemented. [TNI] 2278 [DoD MLOS PP] 2280 Of course, subject to local security policies, encrypted 2281 IPv6 packets with CALIPSO labels might well traverse the 2282 public Internet after receiving suitable cryptographic 2283 protection. For example, a CALIPSO labelled packet might 2284 travel either through a Tunnel-mode ESP (with encryption) 2285 VPN tunnel that connects two or more MLS labelled network 2286 segments. Alternatively, a CALIPSO labelled IPv6 packet 2287 might travel over some external link that has been protected 2288 by the deployment of evaluated, certified, and accredited 2289 bulk encryptors that would encrypt the labelled packet 2290 before transmission onto the link and decrypt the labelled 2291 packet after reception from the link. 2293 Accreditors of a given CALIPSO deployment should consider 2294 not only personnel clearances and physical security issues, 2295 but also electronic security (e.g. TEMPEST), network security 2296 (NETSEC), communications security (COMSEC), and other issues. 2297 This specification is only a small component of an overall 2298 MLS network deployment. 2300 9. IANA CONSIDERATIONS 2302 9.1 IP Option Number 2304 CALIPSO requires an IPv6 Option Number [RFC-2460]: 2306 HEX act chg rest 2307 ---- ---- --- ---- 2308 TBD3 00 0 TBD4 CALIPSO 2310 For the IPv6 Option Number, the first two bits indicate 2311 that the IPv6 node skip over this option and continue 2312 processing the header if it does not recognise the option 2313 type. The third bit indicates that the Option Data must 2314 not change en-route. 2316 This document should be listed as the reference document. 2318 9.2 CALIPSO DOI Values Registry 2320 IANA is requested to create a registry for 2321 CALIPSO DOI values. The initial values for the 2322 CALIPSO DOI registry, shown in colon-separated 2323 quad format, are as follows: 2325 DOI Value Organisation or Use 2326 ======================= ============================ 2327 0:0:0:0 Null DOI. This ought not 2328 be used on any network; 2329 0:0:0:1 to 0:255:255:255 For private use among 2330 consenting parties within 2331 private networks; 2332 1:0:0:0 to 254:255:255:255 For assignment by IANA to 2333 organisations following the 2334 Expert Review procedure. 2335 [RFC-2434]; 2336 255:0:0:0 to 255:255:255:255 Reserved to the IETF for 2337 future use by possible 2338 revisions of this specification. 2340 The CALIPSO DOI value 0:0:0:0 is the Null DOI and 2341 is not to be used on any network or in any deployment. 2343 All other CALIPSO DOI values beginning with decimal 0: 2344 are reserved for private use amongst consenting parties; 2345 values in this range will not be allocated by IANA to any 2346 particular user or user community. 2348 For the CALIPSO DOI values 1:0:0:0 through 254:255:255:255 2349 (inclusive), IANA should follow the Expert Review procedure 2350 when DOI Allocation requests are received. 2352 CALIPSO DOI values beginning with decimal 255 are reserved 2353 to the IETF for potential future use in revisions of this 2354 specification. IESG approval is required for allocation 2355 of DOI values within that range. 2357 ACKNOWLEDGEMENTS 2359 This document is directly derived from an Internet-Draft 2360 titled "Son of IPSO (SIPSO)" written by Mike StJohns circa 1992. 2361 Packet format changes have been made since that draft, primarily 2362 to comply with IPv6 syntax rules. The concepts, most definitions, 2363 and nearly all of the processing rules here are identical to those 2364 in that earlier document. 2366 Steve Brenneman, L.C. Bruzenak, James Carlson, Pasi Eronen, 2367 Michael Fidler, Bob Hinden, Alfred Hoenes, Russ Housley, Suresh 2368 Krishnan, Jarrett Lu, Dan McDonald, Paul Moore, Joe Nall, Dave 2369 Parker, Tim Polk, Ken Powell, Randall Stewart, Bill Sommerfeld, 2370 and Joe Touch (listed in alphabetical order by family name) 2371 provided specific feedback on earlier versions of this document. 2373 The editors also would like to thank the several anonymous 2374 reviewers for their feedback, and particularly for sharing their 2375 insights into operational considerations with MLS networking. 2377 The editors would like to thank the IESG as a whole for 2378 providing feedback on earlier versions of this document. 2380 INFORMATIVE REFERENCES 2382 [BL73] Bell, D.E. & LaPadula, L.J., "Secure Computer 2383 Systems: Mathematical Foundations and Model" 2384 Technical Report M74-244, MITRE Corporation, 2385 Bedford, MA, May 1973. 2387 [CW87] D.D. Clark & D.R. Wilson, "A Comparison of 2388 Commercial and Military Computer Security 2389 Policies", in Proceedings of the IEEE Symposium 2390 on Security & Privacy, pp. 184-194, IEEE 2391 Computer Society, Oakland, CA, May 1987. 2393 [CMW] US Defense Intelligence Agency, 2394 "Compartmented Mode Workstation Evaluation 2395 Criteria", Technical Report 2396 DDS-2600-6243-91, Washington, DC, 2397 November 1991. 2399 [DOD 5200.1] US Department of Defense, 2400 "DoD Information Security Program", 2401 Directive 5200.1, 13 December 1996. 2403 [DOD 5200.1-R] US Department of Defense, 2404 "Information Security Program Regulation", 2405 DoD 5200.1-R, 17 January 1997. 2407 [DoD 5200.28] US Department of Defense, "Security Requirements 2408 for Automated Information Systems," 2409 Directive 5200.28, 21 March 1988. 2411 [DoD MLOS PP] US Department of Defense, 2412 "Protection Profile for Multi-level 2413 Operating Systems in Environments requiring 2414 Medium Robustness, Version 1.22, 23 May 2001. 2416 [ISO-15408] International Stanards Organisation, 2417 "Evaluation Criteria for IT Security", 2418 ISO/IEC 15408, 2005. 2420 [CC] "Common Criteria for Information Technology 2421 Security Evaluation", Version 3.1, Revision 2422 1, CCMB-2006-09-001, September 2006. 2424 [TCSEC] US Department of Defense, "Trusted Computer 2425 System Evaluation Criteria", DoD 5200.28-STD, 2426 26 December 1985. 2428 [TNI] (US) National Computer Security Center, "Trusted 2429 Network Interpretation (TNI) of the Trusted Computer 2430 System Evaluation Criteria", NCSC-TG-005, 2431 Version 1, 31 July 1987. 2433 [DoD 8500.1] US Department of Defense, "Information Assurance", 2434 Directive 8500.1, 24 October 2002. 2436 [FIPS-188] US National Institute of Standards & Technology, 2437 "Standard Security Labels for Information Transfer", 2438 Federal Information Processing Standard (FIPS) 188, 2439 September 1994. 2441 [RFC-791] J. Postel, Internet Protocol, RFC-791, 2442 September 1981. 2444 [RFC-793] J. Postel, Transmission Control Protocol, 2445 RFC-793, September 1981. 2447 [RFC-1038] M. StJohns, Draft Revised IP Security Option, 2448 RFC-1038, January 1988. 2450 [RFC-1108] S. Kent, US DoD Security Options for the 2451 Internet Protocol, RFC-1108, November 1991. 2453 [RFC-1825] R. Atkinson, Security Architecture for the 2454 Internet Protocol, RFC-1825, August 1995. 2456 [RFC-2119] S. Bradner, "Key words for use in RFCs to 2457 Indicate Requirement Levels", RFC-2119, 2458 March 1997. 2460 [IPSEC] S. Kent & K. Seo, "Security Architecture for the 2461 Internet Protocol", RFC-4301, December 2005. 2463 [AH] S. Kent, "IP Authentication Header", RFC-4302, 2464 December 2005. 2466 [ESP] S. Kent, "IP Encapsulating Security Payload", 2467 RFC-4303, December 2005. 2469 NORMATIVE REFERENCES 2471 [RFC-2460] S. Deering & R. Hinden, "Internet Protocol 2472 Version 6 Specification", RFC-2460, 2473 December 1998. 2475 [RFC-2434] T. Narten & H. Alvestrand, "Guidelines 2476 for Writing an IANA Considerations Section", 2477 RFC-2434, BCP 26, October 1998. 2479 [RFC-1662] W. Simpson, "PPP in HDLC-like Framing", 2480 Appendix C, RFC-1662, July 1992. 2482 AUTHORS: 2484 M. StJohns 2485 Germantown, MD 2487 R. Atkinson 2488 Extreme Networks 2489 3585 Monroe Street 2490 Santa Clara, CA 2491 USA 95051 2493 rja@extremenetworks.com 2494 +1 (408)579-2800 2496 G. Thomas 2497 US Department of Defense 2498 Washington, DC 2499 USA 2501 COPYRIGHT AND LICENSE NOTICE 2503 Copyright (c) 2008 IETF Trust and the persons identified as the 2504 document authors. All rights reserved. 2506 This document is subject to BCP 78 and the IETF Trust's 2507 Legal Provisions Relating to IETF Documents 2508 (http://trustee.ietf.org/license-info) in effect on the 2509 date of publication of this document. Please review these 2510 documents carefully, as they describe your rights and 2511 restrictions with respect to this document. 2513 IETF LEGAL NOTICES 2515 All IETF Documents the information contained therein are 2516 provided on an "AS IS" basis and THE CONTRIBUTOR, THE 2517 ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), 2518 THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET 2519 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 2520 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE 2521 USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS 2522 OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR 2523 A PARTICULAR PURPOSE. 2525 The IETF Trust takes no position regarding the validity or 2526 scope of any Intellectual Property Rights or other rights 2527 that might be claimed to pertain to the implementation or use 2528 of the technology described in any IETF document or the extent 2529 to which any license under such rights might or might not 2530 be available; nor does it represent that it has made any 2531 independent effort to identify any such rights. 2533 Copies of Intellectual Property disclosures made to the 2534 IETF Secretariat and any assurances of licenses to be made 2535 available, or the result of an attempt made to obtain a 2536 general license or permission for the use of such 2537 proprietary rights by implementers or users of this 2538 specification can be obtained from the IETF on-line 2539 IPR repository at http://www.ietf.org/ipr. 2541 The IETF invites any interested party to bring to its 2542 attention any copyrights, patents or patent applications, 2543 or other proprietary rights that may cover technology 2544 that may be required to implement any standard or 2545 specification contained in an IETF document. Please 2546 address the information to the IETF at ietf-ipr@ietf.org. 2548 The definitive version of an IETF document is that 2549 published by, or under the auspices of, the IETF. Versions 2550 of IETF Documents that are published by third parties, 2551 including those that are translated into other languages, 2552 should not be considered to be definitive versions of 2553 IETF Documents. The definitive version of these Legal 2554 Provisions is that published by, or under the auspices 2555 of, the IETF. Versions of these Legal Provisions that 2556 are published by third parties, including those that are 2557 translated into other languages, should not be considered 2558 to be definitive versions of these Legal Provisions. 2560 For avoidance of doubt, each Contributor to the IETF 2561 Standards Process licenses each contribution that he 2562 or she makes as part of the IETF Standards Process to 2563 the IETF Trust persuant to the provisions of RFC 5378. 2564 No language to the contrary, or terms, conditions or 2565 rights that differ from or are inconsistent with the 2566 rights and licenses granted under RFC 5378, shall have 2567 any effect and shall be null and void, whether published 2568 or posted by such Contributor, or included with such 2569 Contribution. 2571 Draft Expires: 6 SEP 2009