Root/
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 | |
792 |
Branches:
ben-wpan
ben-wpan-stefan
javiroman/ks7010
jz-2.6.34
jz-2.6.34-rc5
jz-2.6.34-rc6
jz-2.6.34-rc7
jz-2.6.35
jz-2.6.36
jz-2.6.37
jz-2.6.38
jz-2.6.39
jz-3.0
jz-3.1
jz-3.11
jz-3.12
jz-3.13
jz-3.15
jz-3.16
jz-3.18-dt
jz-3.2
jz-3.3
jz-3.4
jz-3.5
jz-3.6
jz-3.6-rc2-pwm
jz-3.9
jz-3.9-clk
jz-3.9-rc8
jz47xx
jz47xx-2.6.38
master
Tags:
od-2011-09-04
od-2011-09-18
v2.6.34-rc5
v2.6.34-rc6
v2.6.34-rc7
v3.9