summaryrefslogtreecommitdiffstats
path: root/Documentation/netlabel/draft-ietf-cipso-ipsecurity-01.txt
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/netlabel/draft-ietf-cipso-ipsecurity-01.txt')
-rw-r--r--Documentation/netlabel/draft-ietf-cipso-ipsecurity-01.txt791
1 files changed, 0 insertions, 791 deletions
diff --git a/Documentation/netlabel/draft-ietf-cipso-ipsecurity-01.txt b/Documentation/netlabel/draft-ietf-cipso-ipsecurity-01.txt
deleted file mode 100644
index 256c2c9..0000000
--- a/Documentation/netlabel/draft-ietf-cipso-ipsecurity-01.txt
+++ /dev/null
@@ -1,791 +0,0 @@
-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
-
-
-
-3.4.4.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.4.5 Category Ranges
-
-A category range is a 4 octet field comprised of the 2 octet index of the
-highest numbered category followed by the 2 octet index of the lowest
-numbered category. These range endpoints are inclusive within the range of
-categories. All categories within a range are included in the sensitivity
-label. This tag may contain a maximum of 7 category pairs. The bottom
-category endpoint for the last pair in the tag MAY be omitted and SHOULD be
-assumed to be 0. The ranges MUST be non-overlapping and be listed in
-descending order. Valid values for categories are 0 to 65534. Category
-65535 is not a valid category value.
-
-
-3.4.5 Minimum Requirements
-
-A CIPSO implementation MUST be capable of generating at least tag type 1 in
-the non-optimized form. In addition, a CIPSO implementation MUST be able
-to receive any valid tag type 1 even those using the optimized tag type 1
-format.
-
-
-4. Configuration Parameters
-
-The configuration parameters defined below are required for all CIPSO hosts,
-gateways, and routers that support multiple sensitivity labels. A CIPSO
-host is defined to be the origination or destination system for an IP
-datagram. A CIPSO gateway provides IP routing services between two or more
-IP networks and may be required to perform label translations between
-networks. A CIPSO gateway may be an enhanced CIPSO host or it may just
-provide gateway services with no end system CIPSO capabilities. A CIPSO
-router is a dedicated IP router that routes IP datagrams between two or more
-IP networks.
-
-An implementation of CIPSO on a host MUST have the capability to reject a
-datagram for reasons that the information contained can not be adequately
-protected by the receiving host or if acceptance may result in violation of
-the host or network security policy. In addition, a CIPSO gateway or router
-MUST be able to reject datagrams going to networks that can not provide
-adequate protection or may violate the network's security policy. To
-provide this capability the following minimal set of configuration
-parameters are required for CIPSO implementations:
-
-HOST_LABEL_MAX - This parameter contains the maximum sensitivity label that
-a CIPSO host is authorized to handle. All datagrams that have a label
-greater than this maximum MUST be rejected by the CIPSO host. This
-parameter does not apply to CIPSO gateways or routers. This parameter need
-not be defined explicitly as it can be implicitly derived from the
-PORT_LABEL_MAX parameters for the associated interfaces.
-
-
-
-Internet Draft, Expires 15 Jan 93 [PAGE 7]
-
-
-
-CIPSO INTERNET DRAFT 16 July, 1992
-
-
-
-
-HOST_LABEL_MIN - This parameter contains the minimum sensitivity label that
-a CIPSO host is authorized to handle. All datagrams that have a label less
-than this minimum MUST be rejected by the CIPSO host. This parameter does
-not apply to CIPSO gateways or routers. This parameter need not be defined
-explicitly as it can be implicitly derived from the PORT_LABEL_MIN
-parameters for the associated interfaces.
-
-PORT_LABEL_MAX - This parameter contains the maximum sensitivity label for
-all datagrams that may exit a particular network interface port. All
-outgoing datagrams that have a label greater than this maximum MUST be
-rejected by the CIPSO system. The label within this parameter MUST be
-less than or equal to the label within the HOST_LABEL_MAX parameter. This
-parameter does not apply to CIPSO hosts that support only one network port.
-
-PORT_LABEL_MIN - This parameter contains the minimum sensitivity label for
-all datagrams that may exit a particular network interface port. All
-outgoing datagrams that have a label less than this minimum MUST be
-rejected by the CIPSO system. The label within this parameter MUST be
-greater than or equal to the label within the HOST_LABEL_MIN parameter.
-This parameter does not apply to CIPSO hosts that support only one network
-port.
-
-PORT_DOI - This parameter is used to assign a DOI identifier value to a
-particular network interface port. All CIPSO labels within datagrams
-going out this port MUST use the specified DOI identifier. All CIPSO
-hosts and gateways MUST support either this parameter, the NET_DOI
-parameter, or the HOST_DOI parameter.
-
-NET_DOI - This parameter is used to assign a DOI identifier value to a
-particular IP network address. All CIPSO labels within datagrams destined
-for the particular IP network MUST use the specified DOI identifier. All
-CIPSO hosts and gateways MUST support either this parameter, the PORT_DOI
-parameter, or the HOST_DOI parameter.
-
-HOST_DOI - This parameter is used to assign a DOI identifier value to a
-particular IP host address. All CIPSO labels within datagrams destined for
-the particular IP host will use the specified DOI identifier. All CIPSO
-hosts and gateways MUST support either this parameter, the PORT_DOI
-parameter, or the NET_DOI parameter.
-
-This list represents the minimal set of configuration parameters required
-to be compliant. Implementors are encouraged to add to this list to
-provide enhanced functionality and control. For example, many security
-policies may require both incoming and outgoing datagrams be checked against
-the port and host label ranges.
-
-
-4.1 Port Range Parameters
-
-The labels represented by the PORT_LABEL_MAX and PORT_LABEL_MIN parameters
-MAY be in CIPSO or local format. Some CIPSO systems, such as routers, may
-want to have the range parameters expressed in CIPSO format so that incoming
-labels do not have to be converted to a local format before being compared
-against the range. If multiple DOIs are supported by one of these CIPSO
-
-
-
-Internet Draft, Expires 15 Jan 93 [PAGE 8]
-
-
-
-CIPSO INTERNET DRAFT 16 July, 1992
-
-
-
-systems then multiple port range parameters would be needed, one set for
-each DOI supported on a particular port.
-
-The port range will usually represent the total set of labels that may
-exist on the logical network accessed through the corresponding network
-interface. It may, however, represent a subset of these labels that are
-allowed to enter the CIPSO system.
-
-
-4.2 Single Label CIPSO Hosts
-
-CIPSO implementations that support only one label are not required to
-support the parameters described above. These limited implementations are
-only required to support a NET_LABEL parameter. This parameter contains
-the CIPSO label that may be inserted in datagrams that exit the host. In
-addition, the host MUST reject any incoming datagram that has a label which
-is not equivalent to the NET_LABEL parameter.
-
-
-5. Handling Procedures
-
-This section describes the processing requirements for incoming and
-outgoing IP datagrams. Just providing the correct CIPSO label format
-is not enough. Assumptions will be made by one system on how a
-receiving system will handle the CIPSO label. Wrong assumptions may
-lead to non-interoperability or even a security incident. The
-requirements described below represent the minimal set needed for
-interoperability and that provide users some level of confidence.
-Many other requirements could be added to increase user confidence,
-however at the risk of restricting creativity and limiting vendor
-participation.
-
-
-5.1 Input Procedures
-
-All datagrams received through a network port MUST have a security label
-associated with them, either contained in the datagram or assigned to the
-receiving port. Without this label the host, gateway, or router will not
-have the information it needs to make security decisions. This security
-label will be obtained from the CIPSO if the option is present in the
-datagram. See section 4.1.2 for handling procedures for unlabeled
-datagrams. This label will be compared against the PORT (if appropriate)
-and HOST configuration parameters defined in section 3.
-
-If any field within the CIPSO option, such as the DOI identifier, is not
-recognized the IP datagram is discarded and an ICMP "parameter problem"
-(type 12) is generated and returned. The ICMP code field is set to "bad
-parameter" (code 0) and the pointer is set to the start of the CIPSO field
-that is unrecognized.
-
-If the contents of the CIPSO are valid but the security label is
-outside of the configured host or port label range, the datagram is
-discarded and an ICMP "destination unreachable" (type 3) is generated
-and returned. The code field of the ICMP is set to "communication with
-destination network administratively prohibited" (code 9) or to
-
-
-
-Internet Draft, Expires 15 Jan 93 [PAGE 9]
-
-
-
-CIPSO INTERNET DRAFT 16 July, 1992
-
-
-
-"communication with destination host administratively prohibited"
-(code 10). The value of the code field used is dependent upon whether
-the originator of the ICMP message is acting as a CIPSO host or a CIPSO
-gateway. The recipient of the ICMP message MUST be able to handle either
-value. The same procedure is performed if a CIPSO can not be added to an
-IP packet because it is too large to fit in the IP options area.
-
-If the error is triggered by receipt of an ICMP message, the message
-is discarded and no response is permitted (consistent with general ICMP
-processing rules).
-
-
-5.1.1 Unrecognized tag types
-
-The default condition for any CIPSO implementation is that an
-unrecognized tag type MUST be treated as a "parameter problem" and
-handled as described in section 4.1. A CIPSO implementation MAY allow
-the system administrator to identify tag types that may safely be
-ignored. This capability is an allowable enhancement, not a
-requirement.
-
-
-5.1.2 Unlabeled Packets
-
-A network port may be configured to not require a CIPSO label for all
-incoming datagrams. For this configuration a CIPSO label must be
-assigned to that network port and associated with all unlabeled IP
-datagrams. This capability might be used for single level networks or
-networks that have CIPSO and non-CIPSO hosts and the non-CIPSO hosts
-all operate at the same label.
-
-If a CIPSO option is required and none is found, the datagram is
-discarded and an ICMP "parameter problem" (type 12) is generated and
-returned to the originator of the datagram. The code field of the ICMP
-is set to "option missing" (code 1) and the ICMP pointer is set to 134
-(the value of the option type for the missing CIPSO option).
-
-
-5.2 Output Procedures
-
-A CIPSO option MUST appear only once in a datagram. Only one tag type
-from the MAC Sensitivity class MAY be included in a CIPSO option. Given
-the current set of defined tag types, this means that CIPSO labels at
-first will contain only one tag.
-
-All datagrams leaving a CIPSO system MUST meet the following condition:
-
- PORT_LABEL_MIN <= CIPSO label <= PORT_LABEL_MAX
-
-If this condition is not satisfied the datagram MUST be discarded.
-If the CIPSO system only supports one port, the HOST_LABEL_MIN and the
-HOST_LABEL_MAX parameters MAY be substituted for the PORT parameters in
-the above condition.
-
-The DOI identifier to be used for all outgoing datagrams is configured by
-
-
-
-Internet Draft, Expires 15 Jan 93 [PAGE 10]
-
-
-
-CIPSO INTERNET DRAFT 16 July, 1992
-
-
-
-the administrator. If port level DOI identifier assignment is used, then
-the PORT_DOI configuration parameter MUST contain the DOI identifier to
-use. If network level DOI assignment is used, then the NET_DOI parameter
-MUST contain the DOI identifier to use. And if host level DOI assignment
-is employed, then the HOST_DOI parameter MUST contain the DOI identifier
-to use. A CIPSO implementation need only support one level of DOI
-assignment.
-
-
-5.3 DOI Processing Requirements
-
-A CIPSO implementation MUST support at least one DOI and SHOULD support
-multiple DOIs. System and network administrators are cautioned to
-ensure that at least one DOI is common within an IP network to allow for
-broadcasting of IP datagrams.
-
-CIPSO gateways MUST be capable of translating a CIPSO option from one
-DOI to another when forwarding datagrams between networks. For
-efficiency purposes this capability is only a desired feature for CIPSO
-routers.
-
-
-5.4 Label of ICMP Messages
-
-The CIPSO label to be used on all outgoing ICMP messages MUST be equivalent
-to the label of the datagram that caused the ICMP message. If the ICMP was
-generated due to a problem associated with the original CIPSO label then the
-following responses are allowed:
-
- a. Use the CIPSO label of the original IP datagram
- b. Drop the original datagram with no return message generated
-
-In most cases these options will have the same effect. If you can not
-interpret the label or if it is outside the label range of your host or
-interface then an ICMP message with the same label will probably not be
-able to exit the system.
-
-
-6. Assignment of DOI Identifier Numbers =
-
-Requests for assignment of a DOI identifier number should be addressed to
-the Internet Assigned Numbers Authority (IANA).
-
-
-7. Acknowledgements
-
-Much of the material in this RFC is based on (and copied from) work
-done by Gary Winiger of Sun Microsystems and published as Commercial
-IP Security Option at the INTEROP 89, Commercial IPSO Workshop.
-
-
-8. Author's Address
-
-To submit mail for distribution to members of the IETF CIPSO Working
-Group, send mail to: cipso@wdl1.wdl.loral.com.
-
-
-
-Internet Draft, Expires 15 Jan 93 [PAGE 11]
-
-
-
-CIPSO INTERNET DRAFT 16 July, 1992
-
-
-
-
-To be added to or deleted from this distribution, send mail to:
-cipso-request@wdl1.wdl.loral.com.
-
-
-9. References
-
-RFC 1038, "Draft Revised IP Security Option", M. St. Johns, IETF, January
-1988.
-
-RFC 1108, "U.S. Department of Defense Security Options
-for the Internet Protocol", Stephen Kent, IAB, 1 March, 1991.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Draft, Expires 15 Jan 93 [PAGE 12]
-
-
-