rfc1108.txt

RFC 的详细文档！

   end or intermediate systems, system administrators, or protection
   authorities may impose more stringent restrictions on responses and
   in some instances may not permit any response at all to a datagram
   which is outside the security range of a host or system.

   In all cases, if the error is triggered by receipt of an ICMP, the
   ICMP is discarded and no response is permitted (consistent with
   general ICMP processing rules).

2.8.1.Parameter Problem Response

   If a datagram is received with no Basic Security Option and the
   system security configuration parameters require the option on the
   network port via which the datagram was received, an ICMP Parameter
   Problem Missing Option (Type = 12, Code = 1) message is transmitted
   in response.  The Pointer field of the ICMP should be set to the
   value "130" to indicate the type of option missing.  A Basic Security
   Option is included in the response datagram with Clearance Level set
   to PORT-LEVEL-MIN and Protection Authority Flags set to PORT-
   AUTHORITY-ERROR.

   If a datagram is received in which the Basic Security Option is
   malformed (e.g., an invalid Classification Level Protection Authority
   Flag field), an ICMP Parameter Problem (Type = 12, Code = 0) message
   is transmitted in response.  The pointer field is set to the
   malformed Basic Security Option.  The Basic Security Option is
   included in the response datagram with Clearance Level set to PORT-
   LEVEL-MIN and Protection Authority Flags set to PORT-AUTHORITY-ERROR.







Kent                                                           [Page 12]

RFC 1108                U.S. DOD Security Option           November 1991


2.8.2.  Out-Of-Range Response

   If a datagram is received which is out of range for the network port
   on which it was received, an ICMP Destination Unreachable
   Communication Administratively Prohibited (Type = 3, Code = 9 for net
   or Code = 10 for host) message is transmitted in response.  A Basic
   Security Option is included in the response datagram with Clearance
   Level set to PORT-LEVEL-MIN and Protection Authority Flags set to
   PORT-AUTHORITY-ERROR.

2.9.  Trusted Intermediary Procedure

   Certain devices in an internet may act as intermediaries to validate
   that communications between two hosts are authorized.  This decision
   is based on the knowledge of the accredited security levels of the
   hosts and the values in the DoD Basic Security Option.  These devices
   may receive IP datagrams which are in range for the intermediate
   device, but are not within the accredited range either for the source
   or for the destination.  In the former case, the datagram should be
   treated as described above for an out-of-range option.  In the latter
   case, an ICMP Destination Unreachable Communication Administratively
   Prohibited (Type = 3, Code = 9 for net or Code = 10 for host)
   response should be transmitted. The security range of the network
   interface on which the reply will be sent determines whether a reply
   is allowed and at what level it will be sent.

3.  DoD Extended Security Option

   This option permits additional security labelling information, beyond
   that present in the Basic Security Option, to be supplied in an IP
   datagram to meet the needs of registered authorities.  Note that
   information which is not labelling data or which is meaningful only
   to the end systems (not intermediate systems) is not appropriate for
   transmission in the IP layer and thus should not be transported using
   this option.  This option must be copied on fragmentation.  Unlike
   the Basic Option, this option may appear multiple times within a
   datagram, subject to overall IP header size constraints.

   This option may be present only in conjunction with the Basic
   Security Option, thus all systems which support Extended Security
   Options must also support the Basic Security Option.  However, not
   all systems which support the Basic Security Option need to support
   Extended Security Options and support for these options may be
   selective, i.e., a system need not support all Extended Security
   Options.

   The top-level format for this option is as follows:




Kent                                                           [Page 13]

RFC 1108                U.S. DOD Security Option           November 1991


             +------------+------------+------------+-------//-------+
             |  10000101  |  000LLLLL  |  AAAAAAAA  |  add sec info  |
             +------------+------------+------------+-------//-------+
              TYPE = 133      LENGTH     ADDITIONAL      ADDITIONAL
                                        SECURITY INFO     SECURITY
                                         FORMAT CODE        INFO

                   FIGURE 3.  DoD EXTENDED SECURITY OPTION FORMAT

3.1.  Type

   The value 133 identifies this as the DoD Extended Security Option.

3.2.  Length.

   The length of the option, which includes the "Type" and "Length"
   fields, is variable.  The minimum length of the option is 3 octets.

3.3.  Additional Security Info Format Code

        Length:  1 Octet

   The value of the Additional Security Info Format Code identifies the
   syntax and semantics for a specific "Additional Security Information"
   field.  For each Additional Security Info Format Code, an RFC will be
   published to specify the syntax and to provide an algorithmic
   description of the processing required to determine whether a
   datagram carrying a label specified by this Format Code should be
   accepted or rejected.  This specification must be sufficiently
   detailed to permit vendors to produce interoperable implementations,
   e.g., it should be comparable to the specification of the Basic
   Security Option provided in this RFC.  However, the specification
   need not include a mapping from the syntax of the option to human
   labels if such mapping would cause distribution of the specification
   to be restricted.

   In order to maintain the architectural consistency of DoD common user
   data networks, and to maximize interoperability, each activity should
   submit its plans for the definition and use of an Additional Security
   Info Format Code to DISA DISDB, Washington, D.C.  20305-2000 for
   review and approval.  DISA DISDB will forward plans to the Internet
   Activities Board for architectural review and, if required, a cleared
   committee formed by the IAB will be constituted for the review
   process.  Once approved, the Internet Assigned Number authority will
   assign an Additional Security Info Format Code to the requesting
   activity, concurrent with publication of the corresponding RFC.

   Note: The bit assignments for the Protection Authority flags of the



Kent                                                           [Page 14]

RFC 1108                U.S. DOD Security Option           November 1991


   Basic Security Option have no relationship to the "Additional
   Security Info Format Code" of this option.

3.4.  Additional Security Information.

        Length:  Variable

   The Additional Security Info field contains the additional security
   labelling information specified by the "Additional Security Info
   Format Code" of the Extended Security Option.  The syntax and
   processing requirements for this field are specified by the
   associated RFC as noted above.  The minimum length of this field is
   zero.

3.5.  System Security Configuration Parameters

   Use of the Extended Security Option requires that the intermediate or
   end system configuration accurately reflect the security parameters
   associated with communication via each network port (see Section 2.5
   as a guide).  Internal representation of the security parameters
   implementation dependent.  The set of parameters required to support
   processing of the Extended Security Option is a function of the set
   of Additional Security Info Format Codes supported by the system.
   The RFC which specifies syntax and processing rules for a registered
   Additional Security Info Format Code will specify the additional
   system security parameters required for processing an Extended
   Security Option relative to that Code.

3.6.  Processing Rules

   Any datagram containing an Extended Security Option must also contain
   a Basic Security Option and receipt of a datagram containing the
   former absent the latter constitutes an error.  If the length
   specified by the Length field is inconsistent with the length
   specified by the variable length encoding for the Additional Security
   Info field, the datagram is in error.  If the datagram is received in
   which the Additional Security Info Format Code contains a non-
   registered value, the datagram is in error.  Finally, if the
   Additional Security Info field contains data inconsistent with the
   defining RFC for the Additional Security Info Format Code, the
   datagram is in error.  In any of these cases, an ICMP Parameter
   Problem response should be sent as per Section 2.8.1.  Any additional
   error processing rules will be specified in the defining RFC for this
   Additional Security Info Format Code.

   If the additional security information contained in the Extended
   Security Option indicates that the datagram is within range according
   to the security policy of the system, then the datagram should be



Kent                                                           [Page 15]

RFC 1108                U.S. DOD Security Option           November 1991


   accepted for further processing.  Otherwise, the datagram should be
   rejected and the procedure specified in Section 2.8.2 should be
   followed (with the Extended Security Option values set apropos the
   Additional Security Info Format Code port security parameters).

   As with the Basic Security Option, it will not be possible in a
   general internet environment for intermediate systems to provide
   routing control for datagrams based on the labels contained in the
   Extended Security Option until such time as interior and exterior
   gateway routing protocols are enhanced to process such labels.

References

   [DoD 5200.28]  Department of Defense Directive 5200.28, "Security
                  Requirements for Automated Information Systems," 21
                  March 1988.

Security Considerations

   The focus of this RFC is the definition of formats and processing
   conventions to support security labels for data contained in IP
   datagrams, thus a variety of security issues must be considered
   carefully when making use of these options.  It is not possible to
   address all of the security considerations which affect correct
   implementation and use of these options, however the following
   paragraph highglights some of these issues.

   Correct implementation and operation of the software and hardware
   which processes these options is essential to their effective use.
   Means for achieving confidence in such correct implementation and
   operation are outside of the scope of this RFC.  The options
   themselves incorporate no facilities to ensure the integrity of the
   security labels in transit (other than the IP checksum mechanism),
   thus appropriate technology must be employed whenever datagrams
   containing these options transit "hostile" communication
   environments.  Careful, secure management of the configuration
   variables associated with each system making use of these options is
   essential if the options are to provide the intended security
   functionality.












Kent                                                           [Page 16]

RFC 1108                U.S. DOD Security Option           November 1991


Author's Address

   Stephen Kent
   BBN Communications
   150 CambridgePark Drive
   Cambridge, MA  02140

   Phone: [phone]

   Email: [e-mail]









































Kent                                                           [Page 17]