diff options
Diffstat (limited to 'doc/rfc/rfc1108.txt')
| -rw-r--r-- | doc/rfc/rfc1108.txt | 955 |
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc1108.txt b/doc/rfc/rfc1108.txt new file mode 100644 index 0000000..09e7d29 --- /dev/null +++ b/doc/rfc/rfc1108.txt @@ -0,0 +1,955 @@ + + + + + + +Network Working Group S. Kent +Request for Comments: 1108 BBN Communications +Obsoletes: RFC 1038 November 1991 + + + U.S. Department of Defense + Security Options for the Internet Protocol + + +Status of this Memo + + This RFC specifies an IAB standards track protocol for the Internet + community, and requests discussion and suggestions for improvements. + Please refer to the current edition of the "IAB Official Protocol + Standards" for the standardization state and status of this protocol. + Distribution of this memo is unlimited. + +Abstract + + This RFC specifies the U.S. Department of Defense Basic Security + Option and the top-level description of the Extended Security Option + for use with the Internet Protocol. This RFC obsoletes RFC 1038 + "Revised IP Security Option", dated January 1988. + +1. DoD Security Options Defined + + The following two internet protocol options are defined for use on + Department of Defense (DoD) common user data networks: + + CF CLASS # TYPE LENGTH DESCRIPTION + + 1 0 2 130 var. DoD Basic Security: Used to carry the + classification level and protection + authority flags. + + + 1 0 5 133 var. DoD Extended Security: Used to carry + additional security information as + required by registered authorities. + + CF = Copy on Fragmentation + +2. DoD Basic Security Option + + This option identifies the U.S. classification level at which the + datagram is to be protected and the authorities whose protection + rules apply to each datagram. + + + + +Kent [Page 1] + +RFC 1108 U.S. DOD Security Option November 1991 + + + This option is used by end systems and intermediate systems of an + internet to: + + a. Transmit from source to destination in a network standard + representation the common security labels required by computer + security models, + + b. Validate the datagram as appropriate for transmission from + the source and delivery to the destination, + + c. Ensure that the route taken by the datagram is protected to + the level required by all protection authorities indicated on + the datagram. In order to provide this facility in a general + Internet environment, interior and exterior gateway protocols + must be augmented to include security label information in + support of routing control. + + The DoD Basic Security option must be copied on fragmentation. This + option appears at most once in a datagram. Some security systems + require this to be the first option if more than one option is + carried in the IP header, but this is not a generic requirement + levied by this specification. + + The format of the DoD Basic Security option is as follows: + + +------------+------------+------------+-------------//----------+ + | 10000010 | XXXXXXXX | SSSSSSSS | AAAAAAA[1] AAAAAAA0 | + | | | | [0] | + +------------+------------+------------+-------------//----------+ + TYPE = 130 LENGTH CLASSIFICATION PROTECTION + LEVEL AUTHORITY + FLAGS + + FIGURE 1. DoD BASIC SECURITY OPTION FORMAT + +2.1. Type + + The value 130 identifies this as the DoD Basic Security Option. + +2.2. Length + + The length of the option is variable. The minimum length of the + option is 3 octets, including the Type and Length fields (the + Protection Authority field may be absent). A length indication of + less than 3 octets should result in error processing as described in + Section 2.8.1. + + + + + +Kent [Page 2] + +RFC 1108 U.S. DOD Security Option November 1991 + + +2.3. Classification Level + + Field Length: One Octet + + This field specifies the (U.S.) classification level at which the + datagram must be protected. The information in the datagram must be + protected at this level. The field is encoded as shown in Table 1 + and the order of values in this table defines the ordering for + comparison purposes. The bit string values in this table were chosen + to achieve a minimum Hamming distance of four (4) between any two + valid values. This specific assignment of classification level names + to values has been defined for compatibility with security devices + which have already been developed and deployed. + + "Reserved" values in the table must be treated as invalid until such + time they are assigned to named classification levels in a successor + to this document. A datagram containing a value for this field which + is either not in this table or which is listed as "reserved" is in + error and must be processed according to the "out-of-range" + procedures defined in section 2.8.1. + + A classification level value from the Basic Security Option in a + datagram may be checked for equality against any of the (assigned) + values in Table 1 by performing a simple bit string comparison. + However, because of the sparseness of the classification level + encodings, range checks involving a value from this field must not be + performed based solely using arithmetic comparisons (as such + comparisons would encompass invalid and or unassigned values within + the range). The details of how ordered comparisons are performed for + this field within a system is a local matter, subject to the + requirements set forth in this paragraph. + + Table 1. Classification Level Encodings + + Value Name + + 00000001 - (Reserved 4) + 00111101 - Top Secret + 01011010 - Secret + 10010110 - Confidential + 01100110 - (Reserved 3) + 11001100 - (Reserved 2) + 10101011 - Unclassified + 11110001 - (Reserved 1) + + + + + + + +Kent [Page 3] + +RFC 1108 U.S. DOD Security Option November 1991 + + +2.4. Protection Authority Flags + + Field Length: Variable + + This field identifies the National Access Programs or Special Access + Programs which specify protection rules for transmission and + processing of the information contained in the datagram. Note that + protection authority flags do NOT represent accreditation + authorities, though the semantics are superficially similar. In + order to maintain architectural consistency and interoperability + throughout DoD common user data networks, users of these networks + should submit requirements for additional Protection Authority Flags + to DISA DISDB, Washington, D.C. 20305-2000, for review and approval. + Such review and approval should be sought prior to design, + development or deployment of any system which would make use of + additional facilities based on assignment of new protection authority + flags. As additional flags are approved and assigned, they will be + published, along with the values defined above, in the Assigned + Numbers RFC edited by the Internet Assigned Numbers Authority (IANA). + + a. Field Length: This field is variable in length. The low- + order bit (Bit 7) of each octet is encoded as "0" if it is the + final octet in the field or as "1" if there are additional + octets. Initially, only one octet is required for this field + (because there are fewer than seven authorities defined), thus + the final bit of the first octet is encoded as "0". However, + minimally compliant implementations must be capable of + processing a protection authority field consisting of at least 2 + octets (representing up to 14 protection authorities). + Implementations existing prior to the issuance of this RFC, and + which process fewer protection authority than specified here, + will be considered minimally compliant so long as such + implementations process the flags in accordance with the RFC. + This field must be a minimally encoded representation, i.e., no + trailing all-zero octets should be emitted. If the length of + this field as indicated by this extensible encoding is not + consistent with the length field for the option, the datagram is + in error and the procedure described in Section 2.8.1 must be + followed. (Figure 2 illustrates the relative significance of + the bits within an octet). + + 0 1 2 3 4 5 6 7 + +---+---+---+---+---+---+---+---+ + High-order | | | | | | | | | Low-order + +---+---+---+---+---+---+---+---+ + + Figure 2. Significance of Bits + + + + +Kent [Page 4] + +RFC 1108 U.S. DOD Security Option November 1991 + + + b. Source Flags: The first seven bits (Bits 0 through 6) in + each octet are flags. Each flag is associated with an + authority. Protection Authority flags currently assigned are + indicated in Table 2. The bit corresponding to an authority is + "1" if the datagram is to be protected in accordance with the + rules of that authority. More than one flag may be present in a + single instance of this option if the data contained in the + datagram should be protected according to rules established by + multiple authorities. Table 3 identifies a point of contact for + each of the authorities listed in Table 2. No "unassigned" bits + in this or other octets in the Protection Authority Field shall + be considered valid Protection Authority flags until such time + as such bits are assigned and the assignments are published in + the Assigned Numbers RFC. Thus a datagram containing flags for + unassigned bits in this field for this option is in error and + must be processed according to the "out-of-range" procedures + defined in section 2.8.1. + + Two protection authority flag fields can be compared for + equality (=) via simple bit string matching. No relative + ordering between two protection authority flag fields is + defined. Because these flags represent protection authorities, + security models such as Bell-LaPadula do not apply to + interpretation of this field. However, the symbol "=<" refers + to set inclusion when comparing a protection authority flag + field to a set of such fields. Means for effecting these tests + within a system are a local matter, subject to the requirements + set forth in this paragraph. + + Table 2 - Protection Authority Bit Assignments + + BIT + NUMBER AUTHORITY + + 0 GENSER + + 1 SIOP-ESI + + 2 SCI + + 3 NSA + + 4 DOE + + 5, 6 Unassigned + + 7 Field Termination Indicator + + + + +Kent [Page 5] + +RFC 1108 U.S. DOD Security Option November 1991 + + + Table 3 - Protection Authority Points of Contact + + AUTHORITY POINT OF CONTACT + + GENSER Designated Approving Authority + per DOD 5200.28 + + SIOP-ESI Department of Defense + Organization of the + Joint Chiefs of Staff + Attn: J6 + Washington, DC 20318-6000 + + SCI Director of Central Intelligence + Attn: Chairman, Information + Handling Committee, Intelligence + Community Staff + Washington, D.C. 20505 + + NSA National Security Agency + 9800 Savage Road + Attn: T03 + Ft. Meade, MD 20755-6000 + + DOE Department of Energy + Attn: DP343.2 + Washington, DC 20545 + +2.5. System Security Configuration Parameters + + Use of the Basic Security Option (BSO) by an end or intermediate + system requires that the system configuration include the parameters + described below. These parameters are critical to secure processing + of the BSO, and thus must be protected from unauthorized + modification. Note that compliant implementations must allow a + minimum of 14 distinct Protection Authority flags (consistent with + the Protection Authority field size defined in Section 2.4) to be set + independently in any parameter involving Protection Authority flag + fields. + + a. SYSTEM-LEVEL-MAX: This parameter specifies the highest + Classification Level (see Table 1) which may be present in the + classification level field of the Basic Security Option in any + datagram transmitted or received by the system. + + b. SYSTEM-LEVEL-MIN: This parameter specifies the lowest + Classification Level (see Table 1) which may be present in the + classification level field of the Basic Security Option in any + + + +Kent [Page 6] + +RFC 1108 U.S. DOD Security Option November 1991 + + + datagram transmitted by the system. + + c. SYSTEM-AUTHORITY-IN: This parameter is a set, each member of + which is a Protection Authority flag field. The set enumerates + all of the Protection Authority flag fields which may be present + in the Protection Authority field of the Basic Security Option + in any datagram received by this system. A compliant + implementation must be capable of representing at least 256 + distinct Protection Authority flag fields (each field must be + capable of representing 14 distinct Protection Authority flags) + in this set. Each element of the enumerated set may be a + combination of multiple protection authority flags. + + Set elements representing multiple Protection Authorities are + formed by ORing together the flags that represent each + authority. Thus, for example, a set element representing + datagrams to be protected according to NSA and SCI rules might + be represented as "00110000" while an element representing + protection mandated by NSA, DOE and SIOP-ESI might be + represented as "01011000". (These examples illustrate 8-bit set + elements apropos the minimal encodings for currently defined + Protection Authority flags. If additional flags are defined + beyond the first byte of the Protection Authority Field, longer + encodings for set elements may be required.) + + It is essential that implementations of the Internet Protocol + Basic Security Option provide a convenient and compact way for + system security managers to express which combinations of flags + are allowed. The details of such an interface are outside the + scope of this RFC, however, enumeration of bit patterns is NOT a + recommended interface. As an alternative, one might consider a + notation of the form COMB(GENSER,NSA,SCI)+COMB(SIOP-ESI,NSA,SCI) + in which "COMB" means ANY combination of the flags referenced as + parameters of the COMB function are allowed and "+" means "or". + + d. SYSTEM-AUTHORITY-OUT: This parameter is a set, each member + of which is a Protection Authority flag field. The set + enumerates all of the Protection Authority flag fields which may + be present in the Protection Authority field of the Basic + Security Option in any datagram transmitted by this system. A + compliant implementation must be capable of representing at + least 256 distinct Protection Authority flag fields in this set. + Explicit enumeration of all authorized Protection Authority + field flags permits great flexibility, and in particular does + not impose set inclusion restrictions on this parameter. + + The following configuration parameters are defined for each network + port present on the system. The term "port" is used here to refer + + + +Kent [Page 7] + +RFC 1108 U.S. DOD Security Option November 1991 + + + either to a physical device interface (which may represent multiple + IP addresses) or to a single IP address (which may be served via + multiple physical interfaces). In general the former interpretation + will apply and is consistent with the Trusted Network Interpretation + of the Trusted Computer Systems Evaluation Criteria (TNI) concept of + a "communications channel" or "I/O device." However, the latter + interpretation also may be valid depending on local system security + capabilities. Note that some combinations of port parameter values + are appropriate only if the port is "single level," i.e., all data + transmitted or received via the port is accurately characterized by + exactly one Classification Level and Protection Authority Flag field. + + e. PORT-LEVEL-MAX: This parameter specifies the highest + Classification Level (see Table 1) which may be present in the + classification level field of the Basic Security Option in any + datagram transmitted or received by the system via this network + port. + + f. PORT-LEVEL-MIN: This parameter specifies the lowest + Classification Level (see Table 1) which may be present in the + classification level field of the Basic Security Option in any + datagram transmitted by the system via this network port. + + g. PORT-AUTHORITY-IN: This parameter is a set each member of + which is a Protection Authority flag field. The set enumerates + all of the Protection Authority flag fields which may be present + in the Protection Authority field of the Basic Security Option + in any datagram received via this port. A compliant + implementation must be capable of representing at least 256 + distinct Protection Authority flag fields in this set. + + h. PORT-AUTHORITY-OUT: This parameter is a set each member of + which is a Protection Authority flag field. The set enumerates + all of the Protection Authority flag fields which may be present + in the Protection Authority field of the Basic Security Option + in any datagram transmitted via this port. A compliant + implementation must be capable of representing at least 256 + distinct Protection Authority flag fields in this set. + + i. PORT-AUTHORITY-ERROR: This parameter is a single Protection + Authority flag field assigned to transmitted ICMP error messages + (see Section 2.8). The PORT-AUTHORITY-ERROR value is selected + from the set of values which constitute PORT-AUTHORITY-OUT. + Means for selecting the PORT-AUTHORITY-ERROR value within a + system are a local matter subject to local security policies. + + j. PORT-IMPLICIT-LABEL: This parameter specifies a single + Classification Level and a Protection Authority flag field + + + +Kent [Page 8] + +RFC 1108 U.S. DOD Security Option November 1991 + + + (which may be null) to be associated with all unlabelled + datagrams received via the port. This parameter is meaningful + only if PORT-BSO-REQUIRED-RECEIVE = FALSE, otherwise receipt of + an unlabelled datagram results in an error response. + + k. PORT-BSO-REQUIRED-RECEIVE: This parameter is a boolean which + indicates whether all datagrams received via this network port + must contain a Basic Security Option. + + l. PORT-BSO-REQUIRED-TRANSMIT: This parameter is a boolean + which indicates whether all datagrams transmitted via this + network port must contain a Basic Security Option. If this + parameter is set to FALSE, then PORT-BSO-REQUIRED-RECEIVE should + also be set to FALSE (to avoid communication failures resulting + from asymmetric labelling constraints). + + In every intermediate or end system, the following relationship must + hold for these parameters for all network interfaces. The symbol + ">=" is interpreted relative to the linear ordering defined for + security levels specified in Section 2.3 for the "LEVEL" parameters, + and as set inclusion for the "AUTHORITY" parameters. + + SYSTEM-LEVEL-MAX >= PORT-LEVEL-MAX >= + PORT-LEVEL-MIN >= SYSTEM-LEVEL-MIN + + SYSTEM-AUTHORITY-IN >= PORT-AUTHORITY-IN + and + SYSTEM-AUTHORITY-OUT >= PORT-AUTHORITY-OUT + +2.6. Configuration Considerations + + Systems which do not maintain separation for different security + classification levels of data should have only trivial ranges for the + LEVEL parameters, i.e., SYSTEM-LEVEL-MAX = PORT-LEVEL-MAX = PORT- + LEVEL-MIN = SYSTEM-LEVEL-MIN. + + Systems which do maintain separation for different security + classification levels of data may have non-trivial ranges for the + LEVEL parameters, e.g., SYSTEM-LEVEL-MAX >= PORT-LEVEL-MAX >= PORT- + LEVEL-MIN >= SYSTEM-LEVEL-MIN. + +2.7. Processing the Basic Security Option + + For systems implementing the Basic Security Option, the parameters + PORT-BSO-REQUIRED-TRANSMIT and PORT-BSO-REQUIRED-RECEIVE are used to + specify the local security policy with regard to requiring the + presence of this option on transmitted and received datagrams, + respectively, on a per-port basis. Each datagram transmitted or + + + +Kent [Page 9] + +RFC 1108 U.S. DOD Security Option November 1991 + + + received by the system must be processed in accordance with the per- + port and system-wide security parameters configured for the system. + + Systems which process only Unclassified data may or may not be + configured to generate the BSO on transmitted datagrams. Such + systems also may or may not require a BSO to be present on received + datagrams. However, all systems must be capable of accepting + datagrams containing this option, irrespective of whether the option + is processed or not. + + In general, systems which process classified data must generate this + option for transmitted datagrams. The only exception to this rule + arises in (dedicated or system high [DoD 5200.28]) networks where + traffic may be implicitly labelled rather than requiring each + attached system to generate explicit labels. If the local security + policy permits receipt of datagrams without the option, each such + datagram is presumed to be implicitly labelled based on the port via + which the datagram is received. A per-port parameter (PORT- + IMPLICIT-LABEL) specifies the label to be associated with such + datagrams upon receipt. Note that a datagram transmitted in response + to receipt of an implicitly labelled datagram, may, based on local + policy, require an explicit Basic Security Option. + +2.7.1. Handling Unclassified Datagrams + + If an unmarked datagram is received via a network port for which + PORT-BSO-REQUIRED = FALSE and PORT-IMPLICIT-LABEL = UNCLASSIFIED (NO + FLAGS), the datagram shall be processed as though no Protection + Authority Flags were set. Thus there are two distinct, valid + representations for Unclassified datagrams to which no Protection + Authority rules apply (an unmarked datagram as described here and a + datagram containing an explicit BSO with Classification Level set to + Unclassified and with no Protection Authority flags set). Note that + a datagram also may contain a Basic Security Option in which the + Classification Level is Unclassified and one or more Protection + Authority Field Flags are set. Such datagrams are explicitly + distinct from the equivalence class noted above (datagrams marked + Unclassified with no Protection Authority field flags set and + datagrams not containing a Basic Security Option). + +2.7.2. Input Processing + + Upon receipt of any datagram a system compliant with this RFC must + perform the following actions. First, if PORT-BSO-REQUIRED-RECEIVE = + TRUE for this port, then any received datagram must contain a Basic + Security Option and a missing BSO results in an ICMP error response + as specified in Section 2.8.1. A received datagram which contains a + Basic Security Option must be processed as described below. This + + + +Kent [Page 10] + +RFC 1108 U.S. DOD Security Option November 1991 + + + algorithm assumes that the IP header checksum has already been + verified and that, in the course of processing IP options, this + option has been encountered. The value of the Classification Level + field from the option will be designated "DG-LEVEL" and the value of + the Protection Authority Flags field will be designated "DG- + AUTHORITY." + + Step 1. Check that DG-LEVEL is a valid security classification level, + i.e., it must be one of the (non-reserved) values from Table + 1. If this test fails execute the out-of-range procedure in + Section 2.8.1. + + Step 2. Check that PORT-LEVEL-MAX >= DG-LEVEL. If this test fails, + execute out-of-range procedure specified in Section 2.8.2. + + Step 3. Check that DG-AUTHORITY =< PORT-AUTHORITY-IN. If this test + fails, execute out-of-range procedure specified in Section + 2.8.2. + +2.7.3. Output Processing + + Any system which implements the Basic Security Option must adhere to + a fundamental rule with regard to transmission of datagrams, i.e., no + datagram shall be transmitted with a Basic Security Option the value + of which is outside of the range for which the system is configured. + Thus for every datagram transmitted by a system the following must + hold: PORT-LEVEL-MAX >= DG-LEVEL >= PORT-LEVEL-MIN and DG-AUTHORITY + =< PORT-AUTHORITY-OUT. It is a local matter as to what procedures + are followed by a system which detects at attempt to transmit a + datagram for which these relationships do not hold. + + If a port is configured to allow both labelled and unlabelled + datagrams (PORT-BSO-REQUIRED-TRANSMIT = FALSE) to be transmitted, the + question arises as to whether a label should be affixed. In + recognition of the lack of widespread implementation or use of this + option, especially in unclassified networks, this RFC recommends that + the default be transmission of unlabelled datagrams. If the + destination requires all datagrams to be labelled on input, then it + will respond with an ICMP error message (see Section 2.8.1) and the + originator can respond by labelling successive packets transmitted to + this destination. + + To support this mode of operation, a system which allows transmission + of both labelled and unlabelled datagrams must maintain state + information (a cache) so that the system can associate the use of + labels with specific destinations, e.g., in response to receipt of an + ICMP error message as specified in Section 2.8.1. This requirement + for maintaining a per-destination cache is very much analogous to + + + +Kent [Page 11] + +RFC 1108 U.S. DOD Security Option November 1991 + + + that imposed for processing the IP source route option or for + maintaining first hop routing information (RFC 1122). This RFC does + not specify which protocol module must maintain the per-destination + cache (e.g., IP vs. TCP or UDP) but security engineering constraints + may dictate an IP implementation in trusted systems. This RFC also + does not specify a cache maintenance algorithm, though use of a timer + and activity flag may be appropriate. + +2.8. Error Procedures + + Datagrams received with errors in the Basic Security Option or which + are out of range for the network port via which they are received, + should not be delivered to user processes. Local policy will specify + whether logging and/or notification of a system security officer is + required in response to receipt of such datagrams. The following are + the least restrictive actions permitted by this protocol. Individual + 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: (617) 873-3988 + + Email: kent@bbn.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kent [Page 17] +
\ No newline at end of file |