]>
Commit | Line | Data |
---|---|---|
8802f616 PM |
1 | IETF CIPSO Working Group |
2 | 16 July, 1992 | |
3 | ||
4 | ||
5 | ||
6 | COMMERCIAL IP SECURITY OPTION (CIPSO 2.2) | |
7 | ||
8 | ||
9 | ||
10 | 1. Status | |
11 | ||
12 | This Internet Draft provides the high level specification for a Commercial | |
13 | IP Security Option (CIPSO). This draft reflects the version as approved by | |
14 | the CIPSO IETF Working Group. Distribution of this memo is unlimited. | |
15 | ||
16 | This document is an Internet Draft. Internet Drafts are working documents | |
17 | of the Internet Engineering Task Force (IETF), its Areas, and its Working | |
18 | Groups. Note that other groups may also distribute working documents as | |
19 | Internet Drafts. | |
20 | ||
21 | Internet Drafts are draft documents valid for a maximum of six months. | |
22 | Internet Drafts may be updated, replaced, or obsoleted by other documents | |
23 | at any time. It is not appropriate to use Internet Drafts as reference | |
24 | material or to cite them other than as a "working draft" or "work in | |
25 | progress." | |
26 | ||
27 | Please check the I-D abstract listing contained in each Internet Draft | |
28 | directory to learn the current status of this or any other Internet Draft. | |
29 | ||
30 | ||
31 | ||
32 | ||
33 | 2. Background | |
34 | ||
35 | Currently the Internet Protocol includes two security options. One of | |
36 | these options is the DoD Basic Security Option (BSO) (Type 130) which allows | |
37 | IP datagrams to be labeled with security classifications. This option | |
38 | provides sixteen security classifications and a variable number of handling | |
39 | restrictions. To handle additional security information, such as security | |
40 | categories or compartments, another security option (Type 133) exists and | |
41 | is referred to as the DoD Extended Security Option (ESO). The values for | |
42 | the fixed fields within these two options are administered by the Defense | |
43 | Information Systems Agency (DISA). | |
44 | ||
45 | Computer vendors are now building commercial operating systems with | |
46 | mandatory access controls and multi-level security. These systems are | |
47 | no longer built specifically for a particular group in the defense or | |
48 | intelligence communities. They are generally available commercial systems | |
49 | for use in a variety of government and civil sector environments. | |
50 | ||
51 | The small number of ESO format codes can not support all the possible | |
52 | applications of a commercial security option. The BSO and ESO were | |
53 | designed to only support the United States DoD. CIPSO has been designed | |
54 | to support multiple security policies. This Internet Draft provides the | |
55 | format and procedures required to support a Mandatory Access Control | |
56 | security policy. Support for additional security policies shall be | |
57 | defined in future RFCs. | |
58 | ||
59 | ||
60 | ||
61 | ||
62 | Internet Draft, Expires 15 Jan 93 [PAGE 1] | |
63 | ||
64 | ||
65 | ||
66 | CIPSO INTERNET DRAFT 16 July, 1992 | |
67 | ||
68 | ||
69 | ||
70 | ||
71 | 3. CIPSO Format | |
72 | ||
73 | Option type: 134 (Class 0, Number 6, Copy on Fragmentation) | |
74 | Option length: Variable | |
75 | ||
76 | This option permits security related information to be passed between | |
77 | systems within a single Domain of Interpretation (DOI). A DOI is a | |
78 | collection of systems which agree on the meaning of particular values | |
79 | in the security option. An authority that has been assigned a DOI | |
80 | identifier will define a mapping between appropriate CIPSO field values | |
81 | and their human readable equivalent. This authority will distribute that | |
82 | mapping to hosts within the authority's domain. These mappings may be | |
83 | sensitive, therefore a DOI authority is not required to make these | |
84 | mappings available to anyone other than the systems that are included in | |
85 | the DOI. | |
86 | ||
87 | This option MUST be copied on fragmentation. This option appears at most | |
88 | once in a datagram. All multi-octet fields in the option are defined to be | |
89 | transmitted in network byte order. The format of this option is as follows: | |
90 | ||
91 | +----------+----------+------//------+-----------//---------+ | |
92 | | 10000110 | LLLLLLLL | DDDDDDDDDDDD | TTTTTTTTTTTTTTTTTTTT | | |
93 | +----------+----------+------//------+-----------//---------+ | |
94 | ||
95 | TYPE=134 OPTION DOMAIN OF TAGS | |
96 | LENGTH INTERPRETATION | |
97 | ||
98 | ||
99 | Figure 1. CIPSO Format | |
100 | ||
101 | ||
102 | 3.1 Type | |
103 | ||
104 | This field is 1 octet in length. Its value is 134. | |
105 | ||
106 | ||
107 | 3.2 Length | |
108 | ||
109 | This field is 1 octet in length. It is the total length of the option | |
110 | including the type and length fields. With the current IP header length | |
111 | restriction of 40 octets the value of this field MUST not exceed 40. | |
112 | ||
113 | ||
114 | 3.3 Domain of Interpretation Identifier | |
115 | ||
116 | This field is an unsigned 32 bit integer. The value 0 is reserved and MUST | |
117 | not appear as the DOI identifier in any CIPSO option. Implementations | |
118 | should assume that the DOI identifier field is not aligned on any particular | |
119 | byte boundary. | |
120 | ||
121 | To conserve space in the protocol, security levels and categories are | |
122 | represented by numbers rather than their ASCII equivalent. This requires | |
123 | a mapping table within CIPSO hosts to map these numbers to their | |
124 | corresponding ASCII representations. Non-related groups of systems may | |
125 | ||
126 | ||
127 | ||
128 | Internet Draft, Expires 15 Jan 93 [PAGE 2] | |
129 | ||
130 | ||
131 | ||
132 | CIPSO INTERNET DRAFT 16 July, 1992 | |
133 | ||
134 | ||
135 | ||
136 | have their own unique mappings. For example, one group of systems may | |
137 | use the number 5 to represent Unclassified while another group may use the | |
138 | number 1 to represent that same security level. The DOI identifier is used | |
139 | to identify which mapping was used for the values within the option. | |
140 | ||
141 | ||
142 | 3.4 Tag Types | |
143 | ||
144 | A common format for passing security related information is necessary | |
145 | for interoperability. CIPSO uses sets of "tags" to contain the security | |
146 | information relevant to the data in the IP packet. Each tag begins with | |
147 | a tag type identifier followed by the length of the tag and ends with the | |
148 | actual security information to be passed. All multi-octet fields in a tag | |
149 | are defined to be transmitted in network byte order. Like the DOI | |
150 | identifier field in the CIPSO header, implementations should assume that | |
151 | all tags, as well as fields within a tag, are not aligned on any particular | |
152 | octet boundary. The tag types defined in this document contain alignment | |
153 | bytes to assist alignment of some information, however alignment can not | |
154 | be guaranteed if CIPSO is not the first IP option. | |
155 | ||
156 | CIPSO tag types 0 through 127 are reserved for defining standard tag | |
157 | formats. Their definitions will be published in RFCs. Tag types whose | |
158 | identifiers are greater than 127 are defined by the DOI authority and may | |
159 | only be meaningful in certain Domains of Interpretation. For these tag | |
160 | types, implementations will require the DOI identifier as well as the tag | |
161 | number to determine the security policy and the format associated with the | |
162 | tag. Use of tag types above 127 are restricted to closed networks where | |
163 | interoperability with other networks will not be an issue. Implementations | |
164 | that support a tag type greater than 127 MUST support at least one DOI that | |
165 | requires only tag types 1 to 127. | |
166 | ||
167 | Tag type 0 is reserved. Tag types 1, 2, and 5 are defined in this | |
168 | Internet Draft. Types 3 and 4 are reserved for work in progress. | |
169 | The standard format for all current and future CIPSO tags is shown below: | |
170 | ||
171 | +----------+----------+--------//--------+ | |
172 | | TTTTTTTT | LLLLLLLL | IIIIIIIIIIIIIIII | | |
173 | +----------+----------+--------//--------+ | |
174 | TAG TAG TAG | |
175 | TYPE LENGTH INFORMATION | |
176 | ||
177 | Figure 2: Standard Tag Format | |
178 | ||
179 | In the three tag types described in this document, the length and count | |
180 | restrictions are based on the current IP limitation of 40 octets for all | |
181 | IP options. If the IP header is later expanded, then the length and count | |
182 | restrictions specified in this document may increase to use the full area | |
183 | provided for IP options. | |
184 | ||
185 | ||
186 | 3.4.1 Tag Type Classes | |
187 | ||
188 | Tag classes consist of tag types that have common processing requirements | |
189 | and support the same security policy. The three tags defined in this | |
190 | Internet Draft belong to the Mandatory Access Control (MAC) Sensitivity | |
191 | ||
192 | ||
193 | ||
194 | Internet Draft, Expires 15 Jan 93 [PAGE 3] | |
195 | ||
196 | ||
197 | ||
198 | CIPSO INTERNET DRAFT 16 July, 1992 | |
199 | ||
200 | ||
201 | ||
202 | class and support the MAC Sensitivity security policy. | |
203 | ||
204 | ||
205 | 3.4.2 Tag Type 1 | |
206 | ||
207 | This is referred to as the "bit-mapped" tag type. Tag type 1 is included | |
208 | in the MAC Sensitivity tag type class. The format of this tag type is as | |
209 | follows: | |
210 | ||
211 | +----------+----------+----------+----------+--------//---------+ | |
212 | | 00000001 | LLLLLLLL | 00000000 | LLLLLLLL | CCCCCCCCCCCCCCCCC | | |
213 | +----------+----------+----------+----------+--------//---------+ | |
214 | ||
215 | TAG TAG ALIGNMENT SENSITIVITY BIT MAP OF | |
216 | TYPE LENGTH OCTET LEVEL CATEGORIES | |
217 | ||
218 | Figure 3. Tag Type 1 Format | |
219 | ||
220 | ||
221 | 3.4.2.1 Tag Type | |
222 | ||
223 | This field is 1 octet in length and has a value of 1. | |
224 | ||
225 | ||
226 | 3.4.2.2 Tag Length | |
227 | ||
228 | This field is 1 octet in length. It is the total length of the tag type | |
229 | including the type and length fields. With the current IP header length | |
230 | restriction of 40 bytes the value within this field is between 4 and 34. | |
231 | ||
232 | ||
233 | 3.4.2.3 Alignment Octet | |
234 | ||
235 | This field is 1 octet in length and always has the value of 0. Its purpose | |
236 | is to align the category bitmap field on an even octet boundary. This will | |
237 | speed many implementations including router implementations. | |
238 | ||
239 | ||
240 | 3.4.2.4 Sensitivity Level | |
241 | ||
242 | This field is 1 octet in length. Its value is from 0 to 255. The values | |
243 | are ordered with 0 being the minimum value and 255 representing the maximum | |
244 | value. | |
245 | ||
246 | ||
247 | 3.4.2.5 Bit Map of Categories | |
248 | ||
249 | The length of this field is variable and ranges from 0 to 30 octets. This | |
250 | provides representation of categories 0 to 239. The ordering of the bits | |
251 | is left to right or MSB to LSB. For example category 0 is represented by | |
252 | the most significant bit of the first byte and category 15 is represented | |
253 | by the least significant bit of the second byte. Figure 4 graphically | |
254 | shows this ordering. Bit N is binary 1 if category N is part of the label | |
255 | for the datagram, and bit N is binary 0 if category N is not part of the | |
256 | label. Except for the optimized tag 1 format described in the next section, | |
257 | ||
258 | ||
259 | ||
260 | Internet Draft, Expires 15 Jan 93 [PAGE 4] | |
261 | ||
262 | ||
263 | ||
264 | CIPSO INTERNET DRAFT 16 July, 1992 | |
265 | ||
266 | ||
267 | ||
268 | minimal encoding SHOULD be used resulting in no trailing zero octets in the | |
269 | category bitmap. | |
270 | ||
271 | octet 0 octet 1 octet 2 octet 3 octet 4 octet 5 | |
272 | XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX . . . | |
273 | bit 01234567 89111111 11112222 22222233 33333333 44444444 | |
274 | number 012345 67890123 45678901 23456789 01234567 | |
275 | ||
276 | Figure 4. Ordering of Bits in Tag 1 Bit Map | |
277 | ||
278 | ||
279 | 3.4.2.6 Optimized Tag 1 Format | |
280 | ||
281 | Routers work most efficiently when processing fixed length fields. To | |
282 | support these routers there is an optimized form of tag type 1. The format | |
283 | does not change. The only change is to the category bitmap which is set to | |
284 | a constant length of 10 octets. Trailing octets required to fill out the 10 | |
285 | octets are zero filled. Ten octets, allowing for 80 categories, was chosen | |
286 | because it makes the total length of the CIPSO option 20 octets. If CIPSO | |
287 | is the only option then the option will be full word aligned and additional | |
288 | filler octets will not be required. | |
289 | ||
290 | ||
291 | 3.4.3 Tag Type 2 | |
292 | ||
293 | This is referred to as the "enumerated" tag type. It is used to describe | |
294 | large but sparsely populated sets of categories. Tag type 2 is in the MAC | |
295 | Sensitivity tag type class. The format of this tag type is as follows: | |
296 | ||
297 | +----------+----------+----------+----------+-------------//-------------+ | |
298 | | 00000010 | LLLLLLLL | 00000000 | LLLLLLLL | CCCCCCCCCCCCCCCCCCCCCCCCCC | | |
299 | +----------+----------+----------+----------+-------------//-------------+ | |
300 | ||
301 | TAG TAG ALIGNMENT SENSITIVITY ENUMERATED | |
302 | TYPE LENGTH OCTET LEVEL CATEGORIES | |
303 | ||
304 | Figure 5. Tag Type 2 Format | |
305 | ||
306 | ||
307 | 3.4.3.1 Tag Type | |
308 | ||
309 | This field is one octet in length and has a value of 2. | |
310 | ||
311 | ||
312 | 3.4.3.2 Tag Length | |
313 | ||
314 | This field is 1 octet in length. It is the total length of the tag type | |
315 | including the type and length fields. With the current IP header length | |
316 | restriction of 40 bytes the value within this field is between 4 and 34. | |
317 | ||
318 | ||
319 | 3.4.3.3 Alignment Octet | |
320 | ||
321 | This field is 1 octet in length and always has the value of 0. Its purpose | |
322 | is to align the category field on an even octet boundary. This will | |
323 | ||
324 | ||
325 | ||
326 | Internet Draft, Expires 15 Jan 93 [PAGE 5] | |
327 | ||
328 | ||
329 | ||
330 | CIPSO INTERNET DRAFT 16 July, 1992 | |
331 | ||
332 | ||
333 | ||
334 | speed many implementations including router implementations. | |
335 | ||
336 | ||
337 | 3.4.3.4 Sensitivity Level | |
338 | ||
339 | This field is 1 octet in length. Its value is from 0 to 255. The values | |
340 | are ordered with 0 being the minimum value and 255 representing the | |
341 | maximum value. | |
342 | ||
343 | ||
344 | 3.4.3.5 Enumerated Categories | |
345 | ||
346 | In this tag, categories are represented by their actual value rather than | |
347 | by their position within a bit field. The length of each category is 2 | |
348 | octets. Up to 15 categories may be represented by this tag. Valid values | |
349 | for categories are 0 to 65534. Category 65535 is not a valid category | |
350 | value. The categories MUST be listed in ascending order within the tag. | |
351 | ||
352 | ||
353 | 3.4.4 Tag Type 5 | |
354 | ||
355 | This is referred to as the "range" tag type. It is used to represent | |
356 | labels where all categories in a range, or set of ranges, are included | |
357 | in the sensitivity label. Tag type 5 is in the MAC Sensitivity tag type | |
358 | class. The format of this tag type is as follows: | |
359 | ||
360 | +----------+----------+----------+----------+------------//-------------+ | |
361 | | 00000101 | LLLLLLLL | 00000000 | LLLLLLLL | Top/Bottom | Top/Bottom | | |
362 | +----------+----------+----------+----------+------------//-------------+ | |
363 | ||
364 | TAG TAG ALIGNMENT SENSITIVITY CATEGORY RANGES | |
365 | TYPE LENGTH OCTET LEVEL | |
366 | ||
367 | Figure 6. Tag Type 5 Format | |
368 | ||
369 | ||
370 | 3.4.4.1 Tag Type | |
371 | ||
372 | This field is one octet in length and has a value of 5. | |
373 | ||
374 | ||
375 | 3.4.4.2 Tag Length | |
376 | ||
377 | This field is 1 octet in length. It is the total length of the tag type | |
378 | including the type and length fields. With the current IP header length | |
379 | restriction of 40 bytes the value within this field is between 4 and 34. | |
380 | ||
381 | ||
382 | 3.4.4.3 Alignment Octet | |
383 | ||
384 | This field is 1 octet in length and always has the value of 0. Its purpose | |
385 | is to align the category range field on an even octet boundary. This will | |
386 | speed many implementations including router implementations. | |
387 | ||
388 | ||
389 | ||
390 | ||
391 | ||
392 | Internet Draft, Expires 15 Jan 93 [PAGE 6] | |
393 | ||
394 | ||
395 | ||
396 | CIPSO INTERNET DRAFT 16 July, 1992 | |
397 | ||
398 | ||
399 | ||
400 | 3.4.4.4 Sensitivity Level | |
401 | ||
402 | This field is 1 octet in length. Its value is from 0 to 255. The values | |
403 | are ordered with 0 being the minimum value and 255 representing the maximum | |
404 | value. | |
405 | ||
406 | ||
407 | 3.4.4.5 Category Ranges | |
408 | ||
409 | A category range is a 4 octet field comprised of the 2 octet index of the | |
410 | highest numbered category followed by the 2 octet index of the lowest | |
411 | numbered category. These range endpoints are inclusive within the range of | |
412 | categories. All categories within a range are included in the sensitivity | |
413 | label. This tag may contain a maximum of 7 category pairs. The bottom | |
414 | category endpoint for the last pair in the tag MAY be omitted and SHOULD be | |
415 | assumed to be 0. The ranges MUST be non-overlapping and be listed in | |
416 | descending order. Valid values for categories are 0 to 65534. Category | |
417 | 65535 is not a valid category value. | |
418 | ||
419 | ||
420 | 3.4.5 Minimum Requirements | |
421 | ||
422 | A CIPSO implementation MUST be capable of generating at least tag type 1 in | |
423 | the non-optimized form. In addition, a CIPSO implementation MUST be able | |
424 | to receive any valid tag type 1 even those using the optimized tag type 1 | |
425 | format. | |
426 | ||
427 | ||
428 | 4. Configuration Parameters | |
429 | ||
430 | The configuration parameters defined below are required for all CIPSO hosts, | |
431 | gateways, and routers that support multiple sensitivity labels. A CIPSO | |
432 | host is defined to be the origination or destination system for an IP | |
433 | datagram. A CIPSO gateway provides IP routing services between two or more | |
434 | IP networks and may be required to perform label translations between | |
435 | networks. A CIPSO gateway may be an enhanced CIPSO host or it may just | |
436 | provide gateway services with no end system CIPSO capabilities. A CIPSO | |
437 | router is a dedicated IP router that routes IP datagrams between two or more | |
438 | IP networks. | |
439 | ||
440 | An implementation of CIPSO on a host MUST have the capability to reject a | |
441 | datagram for reasons that the information contained can not be adequately | |
442 | protected by the receiving host or if acceptance may result in violation of | |
443 | the host or network security policy. In addition, a CIPSO gateway or router | |
444 | MUST be able to reject datagrams going to networks that can not provide | |
445 | adequate protection or may violate the network's security policy. To | |
446 | provide this capability the following minimal set of configuration | |
447 | parameters are required for CIPSO implementations: | |
448 | ||
449 | HOST_LABEL_MAX - This parameter contains the maximum sensitivity label that | |
450 | a CIPSO host is authorized to handle. All datagrams that have a label | |
451 | greater than this maximum MUST be rejected by the CIPSO host. This | |
452 | parameter does not apply to CIPSO gateways or routers. This parameter need | |
453 | not be defined explicitly as it can be implicitly derived from the | |
454 | PORT_LABEL_MAX parameters for the associated interfaces. | |
455 | ||
456 | ||
457 | ||
458 | Internet Draft, Expires 15 Jan 93 [PAGE 7] | |
459 | ||
460 | ||
461 | ||
462 | CIPSO INTERNET DRAFT 16 July, 1992 | |
463 | ||
464 | ||
465 | ||
466 | ||
467 | HOST_LABEL_MIN - This parameter contains the minimum sensitivity label that | |
468 | a CIPSO host is authorized to handle. All datagrams that have a label less | |
469 | than this minimum MUST be rejected by the CIPSO host. This parameter does | |
470 | not apply to CIPSO gateways or routers. This parameter need not be defined | |
471 | explicitly as it can be implicitly derived from the PORT_LABEL_MIN | |
472 | parameters for the associated interfaces. | |
473 | ||
474 | PORT_LABEL_MAX - This parameter contains the maximum sensitivity label for | |
475 | all datagrams that may exit a particular network interface port. All | |
476 | outgoing datagrams that have a label greater than this maximum MUST be | |
477 | rejected by the CIPSO system. The label within this parameter MUST be | |
478 | less than or equal to the label within the HOST_LABEL_MAX parameter. This | |
479 | parameter does not apply to CIPSO hosts that support only one network port. | |
480 | ||
481 | PORT_LABEL_MIN - This parameter contains the minimum sensitivity label for | |
482 | all datagrams that may exit a particular network interface port. All | |
483 | outgoing datagrams that have a label less than this minimum MUST be | |
484 | rejected by the CIPSO system. The label within this parameter MUST be | |
485 | greater than or equal to the label within the HOST_LABEL_MIN parameter. | |
486 | This parameter does not apply to CIPSO hosts that support only one network | |
487 | port. | |
488 | ||
489 | PORT_DOI - This parameter is used to assign a DOI identifier value to a | |
490 | particular network interface port. All CIPSO labels within datagrams | |
491 | going out this port MUST use the specified DOI identifier. All CIPSO | |
492 | hosts and gateways MUST support either this parameter, the NET_DOI | |
493 | parameter, or the HOST_DOI parameter. | |
494 | ||
495 | NET_DOI - This parameter is used to assign a DOI identifier value to a | |
496 | particular IP network address. All CIPSO labels within datagrams destined | |
497 | for the particular IP network MUST use the specified DOI identifier. All | |
498 | CIPSO hosts and gateways MUST support either this parameter, the PORT_DOI | |
499 | parameter, or the HOST_DOI parameter. | |
500 | ||
501 | HOST_DOI - This parameter is used to assign a DOI identifier value to a | |
502 | particular IP host address. All CIPSO labels within datagrams destined for | |
503 | the particular IP host will use the specified DOI identifier. All CIPSO | |
504 | hosts and gateways MUST support either this parameter, the PORT_DOI | |
505 | parameter, or the NET_DOI parameter. | |
506 | ||
507 | This list represents the minimal set of configuration parameters required | |
508 | to be compliant. Implementors are encouraged to add to this list to | |
509 | provide enhanced functionality and control. For example, many security | |
510 | policies may require both incoming and outgoing datagrams be checked against | |
511 | the port and host label ranges. | |
512 | ||
513 | ||
514 | 4.1 Port Range Parameters | |
515 | ||
516 | The labels represented by the PORT_LABEL_MAX and PORT_LABEL_MIN parameters | |
517 | MAY be in CIPSO or local format. Some CIPSO systems, such as routers, may | |
518 | want to have the range parameters expressed in CIPSO format so that incoming | |
519 | labels do not have to be converted to a local format before being compared | |
520 | against the range. If multiple DOIs are supported by one of these CIPSO | |
521 | ||
522 | ||
523 | ||
524 | Internet Draft, Expires 15 Jan 93 [PAGE 8] | |
525 | ||
526 | ||
527 | ||
528 | CIPSO INTERNET DRAFT 16 July, 1992 | |
529 | ||
530 | ||
531 | ||
532 | systems then multiple port range parameters would be needed, one set for | |
533 | each DOI supported on a particular port. | |
534 | ||
535 | The port range will usually represent the total set of labels that may | |
536 | exist on the logical network accessed through the corresponding network | |
537 | interface. It may, however, represent a subset of these labels that are | |
538 | allowed to enter the CIPSO system. | |
539 | ||
540 | ||
541 | 4.2 Single Label CIPSO Hosts | |
542 | ||
543 | CIPSO implementations that support only one label are not required to | |
544 | support the parameters described above. These limited implementations are | |
545 | only required to support a NET_LABEL parameter. This parameter contains | |
546 | the CIPSO label that may be inserted in datagrams that exit the host. In | |
547 | addition, the host MUST reject any incoming datagram that has a label which | |
548 | is not equivalent to the NET_LABEL parameter. | |
549 | ||
550 | ||
551 | 5. Handling Procedures | |
552 | ||
553 | This section describes the processing requirements for incoming and | |
554 | outgoing IP datagrams. Just providing the correct CIPSO label format | |
555 | is not enough. Assumptions will be made by one system on how a | |
556 | receiving system will handle the CIPSO label. Wrong assumptions may | |
557 | lead to non-interoperability or even a security incident. The | |
558 | requirements described below represent the minimal set needed for | |
559 | interoperability and that provide users some level of confidence. | |
560 | Many other requirements could be added to increase user confidence, | |
561 | however at the risk of restricting creativity and limiting vendor | |
562 | participation. | |
563 | ||
564 | ||
565 | 5.1 Input Procedures | |
566 | ||
567 | All datagrams received through a network port MUST have a security label | |
568 | associated with them, either contained in the datagram or assigned to the | |
569 | receiving port. Without this label the host, gateway, or router will not | |
570 | have the information it needs to make security decisions. This security | |
571 | label will be obtained from the CIPSO if the option is present in the | |
572 | datagram. See section 4.1.2 for handling procedures for unlabeled | |
573 | datagrams. This label will be compared against the PORT (if appropriate) | |
574 | and HOST configuration parameters defined in section 3. | |
575 | ||
576 | If any field within the CIPSO option, such as the DOI identifier, is not | |
577 | recognized the IP datagram is discarded and an ICMP "parameter problem" | |
578 | (type 12) is generated and returned. The ICMP code field is set to "bad | |
579 | parameter" (code 0) and the pointer is set to the start of the CIPSO field | |
580 | that is unrecognized. | |
581 | ||
582 | If the contents of the CIPSO are valid but the security label is | |
583 | outside of the configured host or port label range, the datagram is | |
584 | discarded and an ICMP "destination unreachable" (type 3) is generated | |
585 | and returned. The code field of the ICMP is set to "communication with | |
586 | destination network administratively prohibited" (code 9) or to | |
587 | ||
588 | ||
589 | ||
590 | Internet Draft, Expires 15 Jan 93 [PAGE 9] | |
591 | ||
592 | ||
593 | ||
594 | CIPSO INTERNET DRAFT 16 July, 1992 | |
595 | ||
596 | ||
597 | ||
598 | "communication with destination host administratively prohibited" | |
599 | (code 10). The value of the code field used is dependent upon whether | |
600 | the originator of the ICMP message is acting as a CIPSO host or a CIPSO | |
601 | gateway. The recipient of the ICMP message MUST be able to handle either | |
602 | value. The same procedure is performed if a CIPSO can not be added to an | |
603 | IP packet because it is too large to fit in the IP options area. | |
604 | ||
605 | If the error is triggered by receipt of an ICMP message, the message | |
606 | is discarded and no response is permitted (consistent with general ICMP | |
607 | processing rules). | |
608 | ||
609 | ||
610 | 5.1.1 Unrecognized tag types | |
611 | ||
612 | The default condition for any CIPSO implementation is that an | |
613 | unrecognized tag type MUST be treated as a "parameter problem" and | |
614 | handled as described in section 4.1. A CIPSO implementation MAY allow | |
615 | the system administrator to identify tag types that may safely be | |
616 | ignored. This capability is an allowable enhancement, not a | |
617 | requirement. | |
618 | ||
619 | ||
620 | 5.1.2 Unlabeled Packets | |
621 | ||
622 | A network port may be configured to not require a CIPSO label for all | |
623 | incoming datagrams. For this configuration a CIPSO label must be | |
624 | assigned to that network port and associated with all unlabeled IP | |
625 | datagrams. This capability might be used for single level networks or | |
626 | networks that have CIPSO and non-CIPSO hosts and the non-CIPSO hosts | |
627 | all operate at the same label. | |
628 | ||
629 | If a CIPSO option is required and none is found, the datagram is | |
630 | discarded and an ICMP "parameter problem" (type 12) is generated and | |
631 | returned to the originator of the datagram. The code field of the ICMP | |
632 | is set to "option missing" (code 1) and the ICMP pointer is set to 134 | |
633 | (the value of the option type for the missing CIPSO option). | |
634 | ||
635 | ||
636 | 5.2 Output Procedures | |
637 | ||
638 | A CIPSO option MUST appear only once in a datagram. Only one tag type | |
639 | from the MAC Sensitivity class MAY be included in a CIPSO option. Given | |
640 | the current set of defined tag types, this means that CIPSO labels at | |
641 | first will contain only one tag. | |
642 | ||
643 | All datagrams leaving a CIPSO system MUST meet the following condition: | |
644 | ||
645 | PORT_LABEL_MIN <= CIPSO label <= PORT_LABEL_MAX | |
646 | ||
647 | If this condition is not satisfied the datagram MUST be discarded. | |
648 | If the CIPSO system only supports one port, the HOST_LABEL_MIN and the | |
649 | HOST_LABEL_MAX parameters MAY be substituted for the PORT parameters in | |
650 | the above condition. | |
651 | ||
652 | The DOI identifier to be used for all outgoing datagrams is configured by | |
653 | ||
654 | ||
655 | ||
656 | Internet Draft, Expires 15 Jan 93 [PAGE 10] | |
657 | ||
658 | ||
659 | ||
660 | CIPSO INTERNET DRAFT 16 July, 1992 | |
661 | ||
662 | ||
663 | ||
664 | the administrator. If port level DOI identifier assignment is used, then | |
665 | the PORT_DOI configuration parameter MUST contain the DOI identifier to | |
666 | use. If network level DOI assignment is used, then the NET_DOI parameter | |
667 | MUST contain the DOI identifier to use. And if host level DOI assignment | |
668 | is employed, then the HOST_DOI parameter MUST contain the DOI identifier | |
669 | to use. A CIPSO implementation need only support one level of DOI | |
670 | assignment. | |
671 | ||
672 | ||
673 | 5.3 DOI Processing Requirements | |
674 | ||
675 | A CIPSO implementation MUST support at least one DOI and SHOULD support | |
676 | multiple DOIs. System and network administrators are cautioned to | |
677 | ensure that at least one DOI is common within an IP network to allow for | |
678 | broadcasting of IP datagrams. | |
679 | ||
680 | CIPSO gateways MUST be capable of translating a CIPSO option from one | |
681 | DOI to another when forwarding datagrams between networks. For | |
682 | efficiency purposes this capability is only a desired feature for CIPSO | |
683 | routers. | |
684 | ||
685 | ||
686 | 5.4 Label of ICMP Messages | |
687 | ||
688 | The CIPSO label to be used on all outgoing ICMP messages MUST be equivalent | |
689 | to the label of the datagram that caused the ICMP message. If the ICMP was | |
690 | generated due to a problem associated with the original CIPSO label then the | |
691 | following responses are allowed: | |
692 | ||
693 | a. Use the CIPSO label of the original IP datagram | |
694 | b. Drop the original datagram with no return message generated | |
695 | ||
696 | In most cases these options will have the same effect. If you can not | |
697 | interpret the label or if it is outside the label range of your host or | |
698 | interface then an ICMP message with the same label will probably not be | |
699 | able to exit the system. | |
700 | ||
701 | ||
702 | 6. Assignment of DOI Identifier Numbers = | |
703 | ||
704 | Requests for assignment of a DOI identifier number should be addressed to | |
705 | the Internet Assigned Numbers Authority (IANA). | |
706 | ||
707 | ||
708 | 7. Acknowledgements | |
709 | ||
710 | Much of the material in this RFC is based on (and copied from) work | |
711 | done by Gary Winiger of Sun Microsystems and published as Commercial | |
712 | IP Security Option at the INTEROP 89, Commercial IPSO Workshop. | |
713 | ||
714 | ||
715 | 8. Author's Address | |
716 | ||
717 | To submit mail for distribution to members of the IETF CIPSO Working | |
718 | Group, send mail to: cipso@wdl1.wdl.loral.com. | |
719 | ||
720 | ||
721 | ||
722 | Internet Draft, Expires 15 Jan 93 [PAGE 11] | |
723 | ||
724 | ||
725 | ||
726 | CIPSO INTERNET DRAFT 16 July, 1992 | |
727 | ||
728 | ||
729 | ||
730 | ||
731 | To be added to or deleted from this distribution, send mail to: | |
732 | cipso-request@wdl1.wdl.loral.com. | |
733 | ||
734 | ||
735 | 9. References | |
736 | ||
737 | RFC 1038, "Draft Revised IP Security Option", M. St. Johns, IETF, January | |
738 | 1988. | |
739 | ||
740 | RFC 1108, "U.S. Department of Defense Security Options | |
741 | for the Internet Protocol", Stephen Kent, IAB, 1 March, 1991. | |
742 | ||
743 | ||
744 | ||
745 | ||
746 | ||
747 | ||
748 | ||
749 | ||
750 | ||
751 | ||
752 | ||
753 | ||
754 | ||
755 | ||
756 | ||
757 | ||
758 | ||
759 | ||
760 | ||
761 | ||
762 | ||
763 | ||
764 | ||
765 | ||
766 | ||
767 | ||
768 | ||
769 | ||
770 | ||
771 | ||
772 | ||
773 | ||
774 | ||
775 | ||
776 | ||
777 | ||
778 | ||
779 | ||
780 | ||
781 | ||
782 | ||
783 | ||
784 | ||
785 | ||
786 | ||
787 | ||
788 | Internet Draft, Expires 15 Jan 93 [PAGE 12] | |
789 | ||
790 | ||
791 |