draft-ietf-cipso-ipsecurity-01.txt

linux 内核源代码

IETF CIPSO Working Group
16 July, 1992



                 COMMERCIAL IP SECURITY OPTION (CIPSO 2.2)



1.    Status

This Internet Draft provides the high level specification for a Commercial
IP Security Option (CIPSO).  This draft reflects the version as approved by
the CIPSO IETF Working Group.  Distribution of this memo is unlimited.

This document is an Internet Draft.  Internet Drafts are working documents
of the Internet Engineering Task Force (IETF), its Areas, and its Working
Groups. Note that other groups may also distribute working documents as
Internet Drafts.

Internet Drafts are draft documents valid for a maximum of six months.
Internet Drafts may be updated, replaced, or obsoleted by other documents
at any time.  It is not appropriate to use Internet Drafts as reference
material or to cite them other than as a "working draft" or "work in
progress."

Please check the I-D abstract listing contained in each Internet Draft
directory to learn the current status of this or any other Internet Draft.




2.    Background

Currently the Internet Protocol includes two security options.  One of
these options is the DoD Basic Security Option (BSO) (Type 130) which allows
IP datagrams to be labeled with security classifications.  This option
provides sixteen security classifications and a variable number of handling
restrictions.  To handle additional security information, such as security
categories or compartments, another security option (Type 133) exists and
is referred to as the DoD Extended Security Option (ESO).  The values for
the fixed fields within these two options are administered by the Defense
Information Systems Agency (DISA).

Computer vendors are now building commercial operating systems with
mandatory access controls and multi-level security.  These systems are
no longer built specifically for a particular group in the defense or
intelligence communities.  They are generally available commercial systems
for use in a variety of government and civil sector environments.

The small number of ESO format codes can not support all the possible
applications of a commercial security option.  The BSO and ESO were
designed to only support the United States DoD.  CIPSO has been designed
to support multiple security policies.  This Internet Draft provides the
format and procedures required to support a Mandatory Access Control
security policy.  Support for additional security policies shall be
defined in future RFCs.




Internet Draft, Expires 15 Jan 93                                 [PAGE 1]



CIPSO INTERNET DRAFT                                         16 July, 1992




3.    CIPSO Format

Option type: 134 (Class 0, Number 6, Copy on Fragmentation)
Option length: Variable

This option permits security related information to be passed between
systems within a single Domain of Interpretation (DOI).  A DOI is a
collection of systems which agree on the meaning of particular values
in the security option.  An authority that has been assigned a DOI
identifier will define a mapping between appropriate CIPSO field values
and their human readable equivalent.  This authority will distribute that
mapping to hosts within the authority's domain.  These mappings may be
sensitive, therefore a DOI authority is not required to make these
mappings available to anyone other than the systems that are included in
the DOI.

This option MUST be copied on fragmentation.  This option appears at most
once in a datagram.  All multi-octet fields in the option are defined to be
transmitted in network byte order.  The format of this option is as follows:

+----------+----------+------//------+-----------//---------+
| 10000110 | LLLLLLLL | DDDDDDDDDDDD | TTTTTTTTTTTTTTTTTTTT |
+----------+----------+------//------+-----------//---------+

  TYPE=134    OPTION    DOMAIN OF               TAGS
              LENGTH    INTERPRETATION


                Figure 1. CIPSO Format


3.1    Type

This field is 1 octet in length.  Its value is 134.


3.2    Length

This field is 1 octet in length.  It is the total length of the option
including the type and length fields.  With the current IP header length
restriction of 40 octets the value of this field MUST not exceed 40.


3.3    Domain of Interpretation Identifier

This field is an unsigned 32 bit integer.  The value 0 is reserved and MUST
not appear as the DOI identifier in any CIPSO option.  Implementations
should assume that the DOI identifier field is not aligned on any particular
byte boundary.

To conserve space in the protocol, security levels and categories are
represented by numbers rather than their ASCII equivalent.  This requires
a mapping table within CIPSO hosts to map these numbers to their
corresponding ASCII representations.  Non-related groups of systems may



Internet Draft, Expires 15 Jan 93                                 [PAGE 2]



CIPSO INTERNET DRAFT                                         16 July, 1992



have their own unique mappings.  For example, one group of systems may
use the number 5 to represent Unclassified while another group may use the
number 1 to represent that same security level.  The DOI identifier is used
to identify which mapping was used for the values within the option.


3.4    Tag Types

A common format for passing security related information is necessary
for interoperability.  CIPSO uses sets of "tags" to contain the security
information relevant to the data in the IP packet.  Each tag begins with
a tag type identifier followed by the length of the tag and ends with the
actual security information to be passed.  All multi-octet fields in a tag
are defined to be transmitted in network byte order.  Like the DOI
identifier field in the CIPSO header, implementations should assume that
all tags, as well as fields within a tag, are not aligned on any particular
octet boundary.   The tag types defined in this document contain alignment
bytes to assist alignment of some information, however alignment can not
be guaranteed if CIPSO is not the first IP option.

CIPSO tag types 0 through 127 are reserved for defining standard tag
formats.  Their definitions will be published in RFCs.  Tag types whose
identifiers are greater than 127 are defined by the DOI authority and may
only be meaningful in certain Domains of Interpretation.  For these tag
types, implementations will require the DOI identifier as well as the tag
number to determine the security policy and the format associated with the
tag.  Use of tag types above 127 are restricted to closed networks where
interoperability with other networks will not be an issue.  Implementations
that support a tag type greater than 127 MUST support at least one DOI that
requires only tag types 1 to 127.

Tag type 0 is reserved. Tag types 1, 2, and 5 are defined in this
Internet Draft.  Types 3 and 4 are reserved for work in progress.
The standard format for all current and future CIPSO tags is shown below:

+----------+----------+--------//--------+
| TTTTTTTT | LLLLLLLL | IIIIIIIIIIIIIIII |
+----------+----------+--------//--------+
    TAG       TAG         TAG
    TYPE      LENGTH      INFORMATION

    Figure 2:  Standard Tag Format

In the three tag types described in this document, the length and count
restrictions are based on the current IP limitation of 40 octets for all
IP options.  If the IP header is later expanded, then the length and count
restrictions specified in this document may increase to use the full area
provided for IP options.


3.4.1    Tag Type Classes

Tag classes consist of tag types that have common processing requirements
and support the same security policy.  The three tags defined in this
Internet Draft belong to the Mandatory Access Control (MAC) Sensitivity



Internet Draft, Expires 15 Jan 93                                 [PAGE 3]



CIPSO INTERNET DRAFT                                         16 July, 1992



class and support the MAC Sensitivity security policy.


3.4.2    Tag Type 1

This is referred to as the "bit-mapped" tag type.  Tag type 1 is included
in the MAC Sensitivity tag type class.  The format of this tag type is as
follows:

+----------+----------+----------+----------+--------//---------+
| 00000001 | LLLLLLLL | 00000000 | LLLLLLLL | CCCCCCCCCCCCCCCCC |
+----------+----------+----------+----------+--------//---------+

    TAG       TAG      ALIGNMENT  SENSITIVITY    BIT MAP OF
    TYPE      LENGTH   OCTET      LEVEL          CATEGORIES

            Figure 3. Tag Type 1 Format


3.4.2.1    Tag Type

This field is 1 octet in length and has a value of 1.


3.4.2.2    Tag Length

This field is 1 octet in length.  It is the total length of the tag type
including the type and length fields.  With the current IP header length
restriction of 40 bytes the value within this field is between 4 and 34.


3.4.2.3    Alignment Octet

This field is 1 octet in length and always has the value of 0.  Its purpose
is to align the category bitmap field on an even octet boundary.  This will
speed many implementations including router implementations.


3.4.2.4    Sensitivity Level

This field is 1 octet in length.  Its value is from 0 to 255.  The values
are ordered with 0 being the minimum value and 255 representing the maximum
value.


3.4.2.5    Bit Map of Categories

The length of this field is variable and ranges from 0 to 30 octets.  This
provides representation of categories 0 to 239.  The ordering of the bits
is left to right or MSB to LSB.  For example category 0 is represented by
the most significant bit of the first byte and category 15 is represented
by the least significant bit of the second byte.  Figure 4 graphically
shows this ordering.  Bit N is binary 1 if category N is part of the label
for the datagram, and bit N is binary 0 if category N is not part of the
label.  Except for the optimized tag 1 format described in the next section,



Internet Draft, Expires 15 Jan 93                                 [PAGE 4]



CIPSO INTERNET DRAFT                                         16 July, 1992



minimal encoding SHOULD be used resulting in no trailing zero octets in the
category bitmap.

        octet 0  octet 1  octet 2  octet 3  octet 4  octet 5
        XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX . . .
bit     01234567 89111111 11112222 22222233 33333333 44444444
number             012345 67890123 45678901 23456789 01234567

            Figure 4. Ordering of Bits in Tag 1 Bit Map


3.4.2.6    Optimized Tag 1 Format

Routers work most efficiently when processing fixed length fields.  To
support these routers there is an optimized form of tag type 1.  The format
does not change.  The only change is to the category bitmap which is set to
a constant length of 10 octets.  Trailing octets required to fill out the 10
octets are zero filled.  Ten octets, allowing for 80 categories, was chosen
because it makes the total length of the CIPSO option 20 octets.  If CIPSO
is the only option then the option will be full word aligned and additional
filler octets will not be required.


3.4.3    Tag Type 2

This is referred to as the "enumerated" tag type.  It is used to describe
large but sparsely populated sets of categories.  Tag type 2 is in the MAC
Sensitivity tag type class.  The format of this tag type is as follows:

+----------+----------+----------+----------+-------------//-------------+
| 00000010 | LLLLLLLL | 00000000 | LLLLLLLL | CCCCCCCCCCCCCCCCCCCCCCCCCC |
+----------+----------+----------+----------+-------------//-------------+

    TAG       TAG      ALIGNMENT  SENSITIVITY         ENUMERATED
    TYPE      LENGTH   OCTET      LEVEL               CATEGORIES

                Figure 5. Tag Type 2 Format


3.4.3.1     Tag Type

This field is one octet in length and has a value of 2.


3.4.3.2    Tag Length

This field is 1 octet in length. It is the total length of the tag type
including the type and length fields.  With the current IP header length
restriction of 40 bytes the value within this field is between 4 and 34.


3.4.3.3    Alignment Octet

This field is 1 octet in length and always has the value of 0.  Its purpose
is to align the category field on an even octet boundary.  This will



Internet Draft, Expires 15 Jan 93                                 [PAGE 5]



CIPSO INTERNET DRAFT                                         16 July, 1992



speed many implementations including router implementations.


3.4.3.4    Sensitivity Level

This field is 1 octet in length. Its value is from 0 to 255.  The values
are ordered with 0 being the minimum value and 255 representing the
maximum value.


3.4.3.5    Enumerated Categories

In this tag, categories are represented by their actual value rather than
by their position within a bit field.  The length of each category is 2
octets.  Up to 15 categories may be represented by this tag.  Valid values
for categories are 0 to 65534.  Category 65535 is not a valid category
value.  The categories MUST be listed in ascending order within the tag.


3.4.4    Tag Type 5

This is referred to as the "range" tag type.  It is used to represent
labels where all categories in a range, or set of ranges, are included
in the sensitivity label.  Tag type 5 is in the MAC Sensitivity tag type
class.  The format of this tag type is as follows:

+----------+----------+----------+----------+------------//-------------+
| 00000101 | LLLLLLLL | 00000000 | LLLLLLLL |  Top/Bottom | Top/Bottom  |
+----------+----------+----------+----------+------------//-------------+

    TAG       TAG      ALIGNMENT  SENSITIVITY        CATEGORY RANGES
    TYPE      LENGTH   OCTET      LEVEL

                     Figure 6. Tag Type 5 Format


3.4.4.1     Tag Type

This field is one octet in length and has a value of 5.


3.4.4.2    Tag Length

This field is 1 octet in length. It is the total length of the tag type
including the type and length fields.  With the current IP header length
restriction of 40 bytes the value within this field is between 4 and 34.


3.4.4.3    Alignment Octet

This field is 1 octet in length and always has the value of 0.  Its purpose
is to align the category range field on an even octet boundary.  This will
speed many implementations including router implementations.





Internet Draft, Expires 15 Jan 93                                 [PAGE 6]



CIPSO INTERNET DRAFT                                         16 July, 1992