idnits 2.17.1 draft-ietf-cipso-ipsecurity-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 792 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 145 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 72: '...This option MUST be copied on fragment...' RFC 2119 keyword, line 93: '...alue of this field MUST not exceed 40....' RFC 2119 keyword, line 97: '...ger. The value 0 is reserved and MUST...' RFC 2119 keyword, line 138: '...greater than 127 MUST support at least...' RFC 2119 keyword, line 223: '...minimal encoding SHOULD be used result...' (32 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 525 has weird spacing: '...ncoming datag...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: This field is 1 octet in length. It is the total length of the option including the type and length fields. With the current IP header length restriction of 40 octets the value of this field MUST not exceed 40. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: This field is an unsigned 32 bit integer. The value 0 is reserved and MUST not appear as the DOI identifier in any CIPSO option. Implementations should assume that the DOI identifier field is not aligned on any particular byte boundary. == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'PAGE 1' on line 52 looks like a reference -- Missing reference section? 'PAGE 2' on line 107 looks like a reference -- Missing reference section? 'PAGE 3' on line 165 looks like a reference -- Missing reference section? 'PAGE 4' on line 219 looks like a reference -- Missing reference section? 'PAGE 5' on line 274 looks like a reference -- Missing reference section? 'PAGE 6' on line 326 looks like a reference -- Missing reference section? 'PAGE 7' on line 383 looks like a reference -- Missing reference section? 'PAGE 8' on line 441 looks like a reference -- Missing reference section? 'PAGE 9' on line 498 looks like a reference -- Missing reference section? 'PAGE 10' on line 555 looks like a reference -- Missing reference section? 'PAGE 11' on line 610 looks like a reference -- Missing reference section? 'PAGE 12' on line 625 looks like a reference Summary: 14 errors (**), 0 flaws (~~), 6 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF CIPSO Working Group 2 16 July, 1992 4 COMMERCIAL IP SECURITY OPTION (CIPSO 2.2) 6 1. Status 8 This Internet Draft provides the high level specification for a Commercial 9 IP Security Option (CIPSO). This draft reflects the version as approved by 10 the CIPSO IETF Working Group. Distribution of this memo is unlimited. 12 This document is an Internet Draft. Internet Drafts are working documents 13 of the Internet Engineering Task Force (IETF), its Areas, and its Working 14 Groups. Note that other groups may also distribute working documents as 15 Internet Drafts. 17 Internet Drafts are draft documents valid for a maximum of six months. 18 Internet Drafts may be updated, replaced, or obsoleted by other documents 19 at any time. It is not appropriate to use Internet Drafts as reference 20 material or to cite them other than as a "working draft" or "work in 21 progress." 23 Please check the I-D abstract listing contained in each Internet Draft 24 directory to learn the current status of this or any other Internet Draft. 26 2. Background 28 Currently the Internet Protocol includes two security options. One of 29 these options is the DoD Basic Security Option (BSO) (Type 130) which allows 30 IP datagrams to be labeled with security classifications. This option 31 provides sixteen security classifications and a variable number of handling 32 restrictions. To handle additional security information, such as security 33 categories or compartments, another security option (Type 133) exists and 34 is referred to as the DoD Extended Security Option (ESO). The values for 35 the fixed fields within these two options are administered by the Defense 36 Information Systems Agency (DISA). 38 Computer vendors are now building commercial operating systems with 39 mandatory access controls and multi-level security. These systems are 40 no longer built specifically for a particular group in the defense or 41 intelligence communities. They are generally available commercial systems 42 for use in a variety of government and civil sector environments. 44 The small number of ESO format codes can not support all the possible 45 applications of a commercial security option. The BSO and ESO were 46 designed to only support the United States DoD. CIPSO has been designed 47 to support multiple security policies. This Internet Draft provides the 48 format and procedures required to support a Mandatory Access Control 49 security policy. Support for additional security policies shall be 50 defined in future RFCs. 52 Internet Draft, Expires 15 Jan 93 [PAGE 1] 54 CIPSO INTERNET DRAFT 16 July, 1992 56 3. CIPSO Format 58 Option type: 134 (Class 0, Number 6, Copy on Fragmentation) 59 Option length: Variable 61 This option permits security related information to be passed between 62 systems within a single Domain of Interpretation (DOI). A DOI is a 63 collection of systems which agree on the meaning of particular values 64 in the security option. An authority that has been assigned a DOI 65 identifier will define a mapping between appropriate CIPSO field values 66 and their human readable equivalent. This authority will distribute that 67 mapping to hosts within the authority's domain. These mappings may be 68 sensitive, therefore a DOI authority is not required to make these 69 mappings available to anyone other than the systems that are included in 70 the DOI. 72 This option MUST be copied on fragmentation. This option appears at most 73 once in a datagram. All multi-octet fields in the option are defined to be 74 transmitted in network byte order. The format of this option is as follows: 76 +----------+----------+------//------+-----------//---------+ 77 | 10000110 | LLLLLLLL | DDDDDDDDDDDD | TTTTTTTTTTTTTTTTTTTT | 78 +----------+----------+------//------+-----------//---------+ 80 TYPE=134 OPTION DOMAIN OF TAGS 81 LENGTH INTERPRETATION 83 Figure 1. CIPSO Format 85 3.1 Type 87 This field is 1 octet in length. Its value is 134. 89 3.2 Length 91 This field is 1 octet in length. It is the total length of the option 92 including the type and length fields. With the current IP header length 93 restriction of 40 octets the value of this field MUST not exceed 40. 95 3.3 Domain of Interpretation Identifier 97 This field is an unsigned 32 bit integer. The value 0 is reserved and MUST 98 not appear as the DOI identifier in any CIPSO option. Implementations 99 should assume that the DOI identifier field is not aligned on any particular 100 byte boundary. 102 To conserve space in the protocol, security levels and categories are 103 represented by numbers rather than their ASCII equivalent. This requires 104 a mapping table within CIPSO hosts to map these numbers to their 105 corresponding ASCII representations. Non-related groups of systems may 107 Internet Draft, Expires 15 Jan 93 [PAGE 2] 109 CIPSO INTERNET DRAFT 16 July, 1992 111 have their own unique mappings. For example, one group of systems may 112 use the number 5 to represent Unclassified while another group may use the 113 number 1 to represent that same security level. The DOI identifier is used 114 to identify which mapping was used for the values within the option. 116 3.4 Tag Types 118 A common format for passing security related information is necessary 119 for interoperability. CIPSO uses sets of "tags" to contain the security 120 information relevant to the data in the IP packet. Each tag begins with 121 a tag type identifier followed by the length of the tag and ends with the 122 actual security information to be passed. All multi-octet fields in a tag 123 are defined to be transmitted in network byte order. Like the DOI 124 identifier field in the CIPSO header, implementations should assume that 125 all tags, as well as fields within a tag, are not aligned on any particular 126 octet boundary. The tag types defined in this document contain alignment 127 bytes to assist alignment of some information, however alignment can not 128 be guaranteed if CIPSO is not the first IP option. 130 CIPSO tag types 0 through 127 are reserved for defining standard tag 131 formats. Their definitions will be published in RFCs. Tag types whose 132 identifiers are greater than 127 are defined by the DOI authority and may 133 only be meaningful in certain Domains of Interpretation. For these tag 134 types, implementations will require the DOI identifier as well as the tag 135 number to determine the security policy and the format associated with the 136 tag. Use of tag types above 127 are restricted to closed networks where 137 interoperability with other networks will not be an issue. Implementations 138 that support a tag type greater than 127 MUST support at least one DOI that 139 requires only tag types 1 to 127. 141 Tag type 0 is reserved. Tag types 1, 2, and 5 are defined in this 142 Internet Draft. Types 3 and 4 are reserved for work in progress. 143 The standard format for all current and future CIPSO tags is shown below: 145 +----------+----------+--------//--------+ 146 | TTTTTTTT | LLLLLLLL | IIIIIIIIIIIIIIII | 147 +----------+----------+--------//--------+ 148 TAG TAG TAG 149 TYPE LENGTH INFORMATION 151 Figure 2: Standard Tag Format 153 In the three tag types described in this document, the length and count 154 restrictions are based on the current IP limitation of 40 octets for all 155 IP options. If the IP header is later expanded, then the length and count 156 restrictions specified in this document may increase to use the full area 157 provided for IP options. 159 3.4.1 Tag Type Classes 161 Tag classes consist of tag types that have common processing requirements 162 and support the same security policy. The three tags defined in this 163 Internet Draft belong to the Mandatory Access Control (MAC) Sensitivity 165 Internet Draft, Expires 15 Jan 93 [PAGE 3] 167 CIPSO INTERNET DRAFT 16 July, 1992 169 class and support the MAC Sensitivity security policy. 171 3.4.2 Tag Type 1 173 This is referred to as the "bit-mapped" tag type. Tag type 1 is included 174 in the MAC Sensitivity tag type class. The format of this tag type is as 175 follows: 177 +----------+----------+----------+----------+--------//---------+ 178 | 00000001 | LLLLLLLL | 00000000 | LLLLLLLL | CCCCCCCCCCCCCCCCC | 179 +----------+----------+----------+----------+--------//---------+ 181 TAG TAG ALIGNMENT SENSITIVITY BIT MAP OF 182 TYPE LENGTH OCTET LEVEL CATEGORIES 184 Figure 3. Tag Type 1 Format 186 3.4.2.1 Tag Type 188 This field is 1 octet in length and has a value of 1. 190 3.4.2.2 Tag Length 192 This field is 1 octet in length. It is the total length of the tag type 193 including the type and length fields. With the current IP header length 194 restriction of 40 bytes the value within this field is between 4 and 34. 196 3.4.2.3 Alignment Octet 198 This field is 1 octet in length and always has the value of 0. Its purpose 199 is to align the category bitmap field on an even octet boundary. This will 200 speed many implementations including router implementations. 202 3.4.2.4 Sensitivity Level 204 This field is 1 octet in length. Its value is from 0 to 255. The values 205 are ordered with 0 being the minimum value and 255 representing the maximum 206 value. 208 3.4.2.5 Bit Map of Categories 210 The length of this field is variable and ranges from 0 to 30 octets. This 211 provides representation of categories 0 to 239. The ordering of the bits 212 is left to right or MSB to LSB. For example category 0 is represented by 213 the most significant bit of the first byte and category 15 is represented 214 by the least significant bit of the second byte. Figure 4 graphically 215 shows this ordering. Bit N is binary 1 if category N is part of the label 216 for the datagram, and bit N is binary 0 if category N is not part of the 217 label. Except for the optimized tag 1 format described in the next section, 219 Internet Draft, Expires 15 Jan 93 [PAGE 4] 221 CIPSO INTERNET DRAFT 16 July, 1992 223 minimal encoding SHOULD be used resulting in no trailing zero octets in the 224 category bitmap. 226 octet 0 octet 1 octet 2 octet 3 octet 4 octet 5 227 XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX . . . 228 bit 01234567 89111111 11112222 22222233 33333333 44444444 229 number 012345 67890123 45678901 23456789 01234567 231 Figure 4. Ordering of Bits in Tag 1 Bit Map 233 3.4.2.6 Optimized Tag 1 Format 235 Routers work most efficiently when processing fixed length fields. To 236 support these routers there is an optimized form of tag type 1. The format 237 does not change. The only change is to the category bitmap which is set to 238 a constant length of 10 octets. Trailing octets required to fill out the 10 239 octets are zero filled. Ten octets, allowing for 80 categories, was chosen 240 because it makes the total length of the CIPSO option 20 octets. If CIPSO 241 is the only option then the option will be full word aligned and additional 242 filler octets will not be required. 244 3.4.3 Tag Type 2 246 This is referred to as the "enumerated" tag type. It is used to describe 247 large but sparsely populated sets of categories. Tag type 2 is in the MAC 248 Sensitivity tag type class. The format of this tag type is as follows: 250 +----------+----------+----------+----------+-------------//-------------+ 251 | 00000010 | LLLLLLLL | 00000000 | LLLLLLLL | CCCCCCCCCCCCCCCCCCCCCCCCCC | 252 +----------+----------+----------+----------+-------------//-------------+ 254 TAG TAG ALIGNMENT SENSITIVITY ENUMERATED 255 TYPE LENGTH OCTET LEVEL CATEGORIES 257 Figure 5. Tag Type 2 Format 259 3.4.3.1 Tag Type 261 This field is one octet in length and has a value of 2. 263 3.4.3.2 Tag Length 265 This field is 1 octet in length. It is the total length of the tag type 266 including the type and length fields. With the current IP header length 267 restriction of 40 bytes the value within this field is between 4 and 34. 269 3.4.3.3 Alignment Octet 271 This field is 1 octet in length and always has the value of 0. Its purpose 272 is to align the category field on an even octet boundary. This will 274 Internet Draft, Expires 15 Jan 93 [PAGE 5] 276 CIPSO INTERNET DRAFT 16 July, 1992 278 speed many implementations including router implementations. 280 3.4.3.4 Sensitivity Level 282 This field is 1 octet in length. Its value is from 0 to 255. The values 283 are ordered with 0 being the minimum value and 255 representing the 284 maximum value. 286 3.4.3.5 Enumerated Categories 288 In this tag, categories are represented by their actual value rather than 289 by their position within a bit field. The length of each category is 2 290 octets. Up to 15 categories may be represented by this tag. Valid values 291 for categories are 0 to 65534. Category 65535 is not a valid category 292 value. The categories MUST be listed in ascending order within the tag. 294 3.4.4 Tag Type 5 296 This is referred to as the "range" tag type. It is used to represent 297 labels where all categories in a range, or set of ranges, are included 298 in the sensitivity label. Tag type 5 is in the MAC Sensitivity tag type 299 class. The format of this tag type is as follows: 301 +----------+----------+----------+----------+------------//-------------+ 302 | 00000101 | LLLLLLLL | 00000000 | LLLLLLLL | Top/Bottom | Top/Bottom | 303 +----------+----------+----------+----------+------------//-------------+ 305 TAG TAG ALIGNMENT SENSITIVITY CATEGORY RANGES 306 TYPE LENGTH OCTET LEVEL 308 Figure 6. Tag Type 5 Format 310 3.4.4.1 Tag Type 312 This field is one octet in length and has a value of 5. 314 3.4.4.2 Tag Length 316 This field is 1 octet in length. It is the total length of the tag type 317 including the type and length fields. With the current IP header length 318 restriction of 40 bytes the value within this field is between 4 and 34. 320 3.4.4.3 Alignment Octet 322 This field is 1 octet in length and always has the value of 0. Its purpose 323 is to align the category range field on an even octet boundary. This will 324 speed many implementations including router implementations. 326 Internet Draft, Expires 15 Jan 93 [PAGE 6] 328 CIPSO INTERNET DRAFT 16 July, 1992 330 3.4.4.4 Sensitivity Level 332 This field is 1 octet in length. Its value is from 0 to 255. The values 333 are ordered with 0 being the minimum value and 255 representing the maximum 334 value. 336 3.4.4.5 Category Ranges 338 A category range is a 4 octet field comprised of the 2 octet index of the 339 highest numbered category followed by the 2 octet index of the lowest 340 numbered category. These range endpoints are inclusive within the range of 341 categories. All categories within a range are included in the sensitivity 342 label. This tag may contain a maximum of 7 category pairs. The bottom 343 category endpoint for the last pair in the tag MAY be omitted and SHOULD be 344 assumed to be 0. The ranges MUST be non-overlapping and be listed in 345 descending order. Valid values for categories are 0 to 65534. Category 346 65535 is not a valid category value. 348 3.4.5 Minimum Requirements 350 A CIPSO implementation MUST be capable of generating at least tag type 1 in 351 the non-optimized form. In addition, a CIPSO implementation MUST be able 352 to receive any valid tag type 1 even those using the optimized tag type 1 353 format. 355 4. Configuration Parameters 357 The configuration parameters defined below are required for all CIPSO hosts, 358 gateways, and routers that support multiple sensitivity labels. A CIPSO 359 host is defined to be the origination or destination system for an IP 360 datagram. A CIPSO gateway provides IP routing services between two or more 361 IP networks and may be required to perform label translations between 362 networks. A CIPSO gateway may be an enhanced CIPSO host or it may just 363 provide gateway services with no end system CIPSO capabilities. A CIPSO 364 router is a dedicated IP router that routes IP datagrams between two or more 365 IP networks. 367 An implementation of CIPSO on a host MUST have the capability to reject a 368 datagram for reasons that the information contained can not be adequately 369 protected by the receiving host or if acceptance may result in violation of 370 the host or network security policy. In addition, a CIPSO gateway or router 371 MUST be able to reject datagrams going to networks that can not provide 372 adequate protection or may violate the network's security policy. To 373 provide this capability the following minimal set of configuration 374 parameters are required for CIPSO implementations: 376 HOST_LABEL_MAX - This parameter contains the maximum sensitivity label that 377 a CIPSO host is authorized to handle. All datagrams that have a label 378 greater than this maximum MUST be rejected by the CIPSO host. This 379 parameter does not apply to CIPSO gateways or routers. This parameter need 380 not be defined explicitly as it can be implicitly derived from the 381 PORT_LABEL_MAX parameters for the associated interfaces. 383 Internet Draft, Expires 15 Jan 93 [PAGE 7] 385 CIPSO INTERNET DRAFT 16 July, 1992 387 HOST_LABEL_MIN - This parameter contains the minimum sensitivity label that 388 a CIPSO host is authorized to handle. All datagrams that have a label less 389 than this minimum MUST be rejected by the CIPSO host. This parameter does 390 not apply to CIPSO gateways or routers. This parameter need not be defined 391 explicitly as it can be implicitly derived from the PORT_LABEL_MIN 392 parameters for the associated interfaces. 394 PORT_LABEL_MAX - This parameter contains the maximum sensitivity label for 395 all datagrams that may exit a particular network interface port. All 396 outgoing datagrams that have a label greater than this maximum MUST be 397 rejected by the CIPSO system. The label within this parameter MUST be 398 less than or equal to the label within the HOST_LABEL_MAX parameter. This 399 parameter does not apply to CIPSO hosts that support only one network port. 401 PORT_LABEL_MIN - This parameter contains the minimum sensitivity label for 402 all datagrams that may exit a particular network interface port. All 403 outgoing datagrams that have a label less than this minimum MUST be 404 rejected by the CIPSO system. The label within this parameter MUST be 405 greater than or equal to the label within the HOST_LABEL_MIN parameter. 406 This parameter does not apply to CIPSO hosts that support only one network 407 port. 409 PORT_DOI - This parameter is used to assign a DOI identifier value to a 410 particular network interface port. All CIPSO labels within datagrams 411 going out this port MUST use the specified DOI identifier. All CIPSO 412 hosts and gateways MUST support either this parameter, the NET_DOI 413 parameter, or the HOST_DOI parameter. 415 NET_DOI - This parameter is used to assign a DOI identifier value to a 416 particular IP network address. All CIPSO labels within datagrams destined 417 for the particular IP network MUST use the specified DOI identifier. All 418 CIPSO hosts and gateways MUST support either this parameter, the PORT_DOI 419 parameter, or the HOST_DOI parameter. 421 HOST_DOI - This parameter is used to assign a DOI identifier value to a 422 particular IP host address. All CIPSO labels within datagrams destined for 423 the particular IP host will use the specified DOI identifier. All CIPSO 424 hosts and gateways MUST support either this parameter, the PORT_DOI 425 parameter, or the NET_DOI parameter. 427 This list represents the minimal set of configuration parameters required 428 to be compliant. Implementors are encouraged to add to this list to 429 provide enhanced functionality and control. For example, many security 430 policies may require both incoming and outgoing datagrams be checked against 431 the port and host label ranges. 433 4.1 Port Range Parameters 435 The labels represented by the PORT_LABEL_MAX and PORT_LABEL_MIN parameters 436 MAY be in CIPSO or local format. Some CIPSO systems, such as routers, may 437 want to have the range parameters expressed in CIPSO format so that incoming 438 labels do not have to be converted to a local format before being compared 439 against the range. If multiple DOIs are supported by one of these CIPSO 441 Internet Draft, Expires 15 Jan 93 [PAGE 8] 443 CIPSO INTERNET DRAFT 16 July, 1992 445 systems then multiple port range parameters would be needed, one set for 446 each DOI supported on a particular port. 448 The port range will usually represent the total set of labels that may 449 exist on the logical network accessed through the corresponding network 450 interface. It may, however, represent a subset of these labels that are 451 allowed to enter the CIPSO system. 453 4.2 Single Label CIPSO Hosts 455 CIPSO implementations that support only one label are not required to 456 support the parameters described above. These limited implementations are 457 only required to support a NET_LABEL parameter. This parameter contains 458 the CIPSO label that may be inserted in datagrams that exit the host. In 459 addition, the host MUST reject any incoming datagram that has a label which 460 is not equivalent to the NET_LABEL parameter. 462 5. Handling Procedures 464 This section describes the processing requirements for incoming and 465 outgoing IP datagrams. Just providing the correct CIPSO label format 466 is not enough. Assumptions will be made by one system on how a 467 receiving system will handle the CIPSO label. Wrong assumptions may 468 lead to non-interoperability or even a security incident. The 469 requirements described below represent the minimal set needed for 470 interoperability and that provide users some level of confidence. 471 Many other requirements could be added to increase user confidence, 472 however at the risk of restricting creativity and limiting vendor 473 participation. 475 5.1 Input Procedures 477 All datagrams received through a network port MUST have a security label 478 associated with them, either contained in the datagram or assigned to the 479 receiving port. Without this label the host, gateway, or router will not 480 have the information it needs to make security decisions. This security 481 label will be obtained from the CIPSO if the option is present in the 482 datagram. See section 4.1.2 for handling procedures for unlabeled 483 datagrams. This label will be compared against the PORT (if appropriate) 484 and HOST configuration parameters defined in section 3. 486 If any field within the CIPSO option, such as the DOI identifier, is not 487 recognized the IP datagram is discarded and an ICMP "parameter problem" 488 (type 12) is generated and returned. The ICMP code field is set to "bad 489 parameter" (code 0) and the pointer is set to the start of the CIPSO field 490 that is unrecognized. 492 If the contents of the CIPSO are valid but the security label is 493 outside of the configured host or port label range, the datagram is 494 discarded and an ICMP "destination unreachable" (type 3) is generated 495 and returned. The code field of the ICMP is set to "communication with 496 destination network administratively prohibited" (code 9) or to 498 Internet Draft, Expires 15 Jan 93 [PAGE 9] 500 CIPSO INTERNET DRAFT 16 July, 1992 502 "communication with destination host administratively prohibited" 503 (code 10). The value of the code field used is dependent upon whether 504 the originator of the ICMP message is acting as a CIPSO host or a CIPSO 505 gateway. The recipient of the ICMP message MUST be able to handle either 506 value. The same procedure is performed if a CIPSO can not be added to an 507 IP packet because it is too large to fit in the IP options area. 509 If the error is triggered by receipt of an ICMP message, the message 510 is discarded and no response is permitted (consistent with general ICMP 511 processing rules). 513 5.1.1 Unrecognized tag types 515 The default condition for any CIPSO implementation is that an 516 unrecognized tag type MUST be treated as a "parameter problem" and 517 handled as described in section 4.1. A CIPSO implementation MAY allow 518 the system administrator to identify tag types that may safely be 519 ignored. This capability is an allowable enhancement, not a 520 requirement. 522 5.1.2 Unlabeled Packets 524 A network port may be configured to not require a CIPSO label for all 525 incoming datagrams. For this configuration a CIPSO label must be 526 assigned to that network port and associated with all unlabeled IP 527 datagrams. This capability might be used for single level networks or 528 networks that have CIPSO and non-CIPSO hosts and the non-CIPSO hosts 529 all operate at the same label. 531 If a CIPSO option is required and none is found, the datagram is 532 discarded and an ICMP "parameter problem" (type 12) is generated and 533 returned to the originator of the datagram. The code field of the ICMP 534 is set to "option missing" (code 1) and the ICMP pointer is set to 134 535 (the value of the option type for the missing CIPSO option). 537 5.2 Output Procedures 539 A CIPSO option MUST appear only once in a datagram. Only one tag type 540 from the MAC Sensitivity class MAY be included in a CIPSO option. Given 541 the current set of defined tag types, this means that CIPSO labels at 542 first will contain only one tag. 544 All datagrams leaving a CIPSO system MUST meet the following condition: 546 PORT_LABEL_MIN <= CIPSO label <= PORT_LABEL_MAX 548 If this condition is not satisfied the datagram MUST be discarded. 549 If the CIPSO system only supports one port, the HOST_LABEL_MIN and the 550 HOST_LABEL_MAX parameters MAY be substituted for the PORT parameters in 551 the above condition. 553 The DOI identifier to be used for all outgoing datagrams is configured by 555 Internet Draft, Expires 15 Jan 93 [PAGE 10] 557 CIPSO INTERNET DRAFT 16 July, 1992 559 the administrator. If port level DOI identifier assignment is used, then 560 the PORT_DOI configuration parameter MUST contain the DOI identifier to 561 use. If network level DOI assignment is used, then the NET_DOI parameter 562 MUST contain the DOI identifier to use. And if host level DOI assignment 563 is employed, then the HOST_DOI parameter MUST contain the DOI identifier 564 to use. A CIPSO implementation need only support one level of DOI 565 assignment. 567 5.3 DOI Processing Requirements 569 A CIPSO implementation MUST support at least one DOI and SHOULD support 570 multiple DOIs. System and network administrators are cautioned to 571 ensure that at least one DOI is common within an IP network to allow for 572 broadcasting of IP datagrams. 574 CIPSO gateways MUST be capable of translating a CIPSO option from one 575 DOI to another when forwarding datagrams between networks. For 576 efficiency purposes this capability is only a desired feature for CIPSO 577 routers. 579 5.4 Label of ICMP Messages 581 The CIPSO label to be used on all outgoing ICMP messages MUST be equivalent 582 to the label of the datagram that caused the ICMP message. If the ICMP was 583 generated due to a problem associated with the original CIPSO label then the 584 following responses are allowed: 586 a. Use the CIPSO label of the original IP datagram 587 b. Drop the original datagram with no return message generated 589 In most cases these options will have the same effect. If you can not 590 interpret the label or if it is outside the label range of your host or 591 interface then an ICMP message with the same label will probably not be 592 able to exit the system. 594 6. Assignment of DOI Identifier Numbers = 596 Requests for assignment of a DOI identifier number should be addressed to 597 the Internet Assigned Numbers Authority (IANA). 599 7. Acknowledgements 601 Much of the material in this RFC is based on (and copied from) work 602 done by Gary Winiger of Sun Microsystems and published as Commercial 603 IP Security Option at the INTEROP 89, Commercial IPSO Workshop. 605 8. Author's Address 607 To submit mail for distribution to members of the IETF CIPSO Working 608 Group, send mail to: cipso@wdl1.wdl.loral.com. 610 Internet Draft, Expires 15 Jan 93 [PAGE 11] 612 CIPSO INTERNET DRAFT 16 July, 1992 614 To be added to or deleted from this distribution, send mail to: 615 cipso-request@wdl1.wdl.loral.com. 617 9. References 619 RFC 1038, "Draft Revised IP Security Option", M. St. Johns, IETF, January 620 1988. 622 RFC 1108, "U.S. Department of Defense Security Options 623 for the Internet Protocol", Stephen Kent, IAB, 1 March, 1991. 625 Internet Draft, Expires 15 Jan 93 [PAGE 12]