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