As per Relevance of the word parameter, we have this rfc below:
Network Working Group S.
Request for Comments: 1108 BBN
Obsoletes: RFC 1038 November 1991
U.S. Department of
Security Options for the Internet
Status of this
This RFC specifies an IAB standards track protocol for the
community, and requests discussion and suggestions for improvements
Please refer to the current edition of the "IAB Official
Standards" for the standardization state and status of this protocol
Distribution of this memo is unlimited
This RFC specifies the U.S. Department of Defense Basic
Option and the top-level description of the Extended Security
for use with the Internet Protocol. This RFC obsoletes RFC 1038
"Revised IP Security Option", dated January 1988.
1. DoD Security Options
The following two internet protocol options are defined for use
Department of Defense (DoD) common user data networks
CF CLASS # TYPE LENGTH
1 0 2 130 var. DoD Basic Security: Used to carry
classification level and
authority flags
1 0 5 133 var. DoD Extended Security: Used to
additional security information
required by registered authorities
CF = Copy on
2. DoD Basic Security
This option identifies the U.S. classification level at which
datagram is to be protected and the authorities whose
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
internet to
a. Transmit from source to destination in a network
representation the common security labels required by
security models
b. Validate the datagram as appropriate for transmission
the source and delivery to the destination
c. Ensure that the route taken by the datagram is protected
the level required by all protection authorities indicated
the datagram. In order to provide this facility in a
Internet environment, interior and exterior gateway
must be augmented to include security label information
support of routing control
The DoD Basic Security option must be copied on fragmentation.
option appears at most once in a datagram. Some security
require this to be the first option if more than one option
carried in the IP header, but this is not a generic
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
LEVEL
FIGURE 1. DoD BASIC SECURITY OPTION
2.1.
The value 130 identifies this as the DoD Basic Security Option
2.2.
The length of the option is variable. The minimum length of
option is 3 octets, including the Type and Length fields (
Protection Authority field may be absent). A length indication
less than 3 octets should result in error processing as described
Section 2.8.1.
Kent [Page 2]
RFC 1108 U.S. DOD Security Option November 1991
2.3. Classification
Field Length: One
This field specifies the (U.S.) classification level at which
datagram must be protected. The information in the datagram must
protected at this level. The field is encoded as shown in Table 1
and the order of values in this table defines the ordering
comparison purposes. The bit string values in this table were
to achieve a minimum Hamming distance of four (4) between any
valid values. This specific assignment of classification level
to values has been defined for compatibility with security
which have already been developed and deployed
"Reserved" values in the table must be treated as invalid until
time they are assigned to named classification levels in a
to this document. A datagram containing a value for this field
is either not in this table or which is listed as "reserved" is
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
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
encodings, range checks involving a value from this field must not
performed based solely using arithmetic comparisons (as
comparisons would encompass invalid and or unassigned values
the range). The details of how ordered comparisons are performed
this field within a system is a local matter, subject to
requirements set forth in this paragraph
Table 1. Classification Level
Value
00000001 - (Reserved 4)
00111101 - Top
01011010 -
10010110 -
01100110 - (Reserved 3)
11001100 - (Reserved 2)
10101011 -
11110001 - (Reserved 1)
Kent [Page 3]
RFC 1108 U.S. DOD Security Option November 1991
2.4. Protection Authority
Field Length:
This field identifies the National Access Programs or Special
Programs which specify protection rules for transmission
processing of the information contained in the datagram. Note
protection authority flags do NOT represent
authorities, though the semantics are superficially similar.
order to maintain architectural consistency and
throughout DoD common user data networks, users of these
should submit requirements for additional Protection Authority
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
additional facilities based on assignment of new protection
flags. As additional flags are approved and assigned, they will
published, along with the values defined above, in the
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
final octet in the field or as "1" if there are
octets. Initially, only one octet is required for this
(because there are fewer than seven authorities defined),
the final bit of the first octet is encoded as "0". However
minimally compliant implementations must be capable
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,
which process fewer protection authority than specified here
will be considered minimally compliant so long as
implementations process the flags in accordance with the RFC
This field must be a minimally encoded representation, i.e.,
trailing all-zero octets should be emitted. If the length
this field as indicated by this extensible encoding is
consistent with the length field for the option, the datagram
in error and the procedure described in Section 2.8.1 must
followed. (Figure 2 illustrates the relative significance
the bits within an octet).
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
High-order | | | | | | | | | Low-
+---+---+---+---+---+---+---+---+
Figure 2. Significance of
Kent [Page 4]
RFC 1108 U.S. DOD Security Option November 1991
b. Source Flags: The first seven bits (Bits 0 through 6)
each octet are flags. Each flag is associated with
authority. Protection Authority flags currently assigned
indicated in Table 2. The bit corresponding to an authority
"1" if the datagram is to be protected in accordance with
rules of that authority. More than one flag may be present in
single instance of this option if the data contained in
datagram should be protected according to rules established
multiple authorities. Table 3 identifies a point of contact
each of the authorities listed in Table 2. No "unassigned"
in this or other octets in the Protection Authority Field
be considered valid Protection Authority flags until such
as such bits are assigned and the assignments are published
the Assigned Numbers RFC. Thus a datagram containing flags
unassigned bits in this field for this option is in error
must be processed according to the "out-of-range"
defined in section 2.8.1.
Two protection authority flag fields can be compared
equality (=) via simple bit string matching. No
ordering between two protection authority flag fields
defined. Because these flags represent protection authorities
security models such as Bell-LaPadula do not apply
interpretation of this field. However, the symbol "=<"
to set inclusion when comparing a protection authority
field to a set of such fields. Means for effecting these
within a system are a local matter, subject to the
set forth in this paragraph
Table 2 - Protection Authority Bit
NUMBER
0
1 SIOP-
2
3
4
5, 6
7 Field Termination
Kent [Page 5]
RFC 1108 U.S. DOD Security Option November 1991
Table 3 - Protection Authority Points of
AUTHORITY POINT OF
GENSER Designated Approving
per DOD 5200.28
SIOP-ESI Department of
Organization of
Joint Chiefs of
Attn: J
Washington, DC 20318-6000
SCI Director of Central
Attn: Chairman,
Handling Committee,
Community
Washington, D.C. 20505
NSA National Security
9800 Savage
Attn: T03
Ft. Meade, MD 20755-6000
DOE Department of
Attn: DP343.2
Washington, DC 20545
2.5. System Security Configuration
Use of the Basic Security Option (BSO) by an end or
system requires that the system configuration include the
described below. These parameters are critical to secure
of the BSO, and thus must be protected from
modification. Note that compliant implementations must allow
minimum of 14 distinct Protection Authority flags (consistent
the Protection Authority field size defined in Section 2.4) to be
independently in any parameter involving Protection Authority
fields
a. SYSTEM-LEVEL-MAX: This parameter specifies the
Classification Level (see Table 1) which may be present in
classification level field of the Basic Security Option in
datagram transmitted or received by the system
b. SYSTEM-LEVEL-MIN: This parameter specifies the
Classification Level (see Table 1) which may be present in
classification level field of the Basic Security Option in
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
which is a Protection Authority flag field. The set
all of the Protection Authority flag fields which may be
in the Protection Authority field of the Basic Security
in any datagram received by this system. A
implementation must be capable of representing at least 256
distinct Protection Authority flag fields (each field must
capable of representing 14 distinct Protection Authority flags
in this set. Each element of the enumerated set may be
combination of multiple protection authority flags
Set elements representing multiple Protection Authorities
formed by ORing together the flags that represent
authority. Thus, for example, a set element
datagrams to be protected according to NSA and SCI rules
be represented as "00110000" while an element
protection mandated by NSA, DOE and SIOP-ESI might
represented as "01011000". (These examples illustrate 8-bit
elements apropos the minimal encodings for currently
Protection Authority flags. If additional flags are
beyond the first byte of the Protection Authority Field,
encodings for set elements may be required.)
It is essential that implementations of the Internet
Basic Security Option provide a convenient and compact way
system security managers to express which combinations of
are allowed. The details of such an interface are outside
scope of this RFC, however, enumeration of bit patterns is NOT
recommended interface. As an alternative, one might consider
notation of the form COMB(GENSER,NSA,SCI)+COMB(SIOP-ESI,NSA,SCI
in which "COMB" means ANY combination of the flags referenced
parameters of the COMB function are allowed and "+" means "or".
d. SYSTEM-AUTHORITY-OUT: This parameter is a set, each
of which is a Protection Authority flag field. The
enumerates all of the Protection Authority flag fields which
be present in the Protection Authority field of the
Security Option in any datagram transmitted by this system.
compliant implementation must be capable of representing
least 256 distinct Protection Authority flag fields in this set
Explicit enumeration of all authorized Protection
field flags permits great flexibility, and in particular
not impose set inclusion restrictions on this parameter
The following configuration parameters are defined for each
port present on the system. The term "port" is used here to
Kent [Page 7]
RFC 1108 U.S. DOD Security Option November 1991
either to a physical device interface (which may represent
IP addresses) or to a single IP address (which may be served
multiple physical interfaces). In general the former
will apply and is consistent with the Trusted Network
of the Trusted Computer Systems Evaluation Criteria (TNI) concept
a "communications channel" or "I/O device." However, the
interpretation also may be valid depending on local system
capabilities. Note that some combinations of port parameter
are appropriate only if the port is "single level," i.e., all
transmitted or received via the port is accurately characterized
exactly one Classification Level and Protection Authority Flag field
e. PORT-LEVEL-MAX: This parameter specifies the
Classification Level (see Table 1) which may be present in
classification level field of the Basic Security Option in
datagram transmitted or received by the system via this
port
f. PORT-LEVEL-MIN: This parameter specifies the
Classification Level (see Table 1) which may be present in
classification level field of the Basic Security Option in
datagram transmitted by the system via this network port
g. PORT-AUTHORITY-IN: This parameter is a set each member
which is a Protection Authority flag field. The set
all of the Protection Authority flag fields which may be
in the Protection Authority field of the Basic Security
in any datagram received via this port. A
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
which is a Protection Authority flag field. The set
all of the Protection Authority flag fields which may be
in the Protection Authority field of the Basic Security
in any datagram transmitted via this port. A
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
Authority flag field assigned to transmitted ICMP error
(see Section 2.8). The PORT-AUTHORITY-ERROR value is
from the set of values which constitute PORT-AUTHORITY-OUT
Means for selecting the PORT-AUTHORITY-ERROR value within
system are a local matter subject to local security policies
j. PORT-IMPLICIT-LABEL: This parameter specifies a
Classification Level and a Protection Authority flag
Kent [Page 8]
RFC 1108 U.S. DOD Security Option November 1991
(which may be null) to be associated with all
datagrams received via the port. This parameter is
only if PORT-BSO-REQUIRED-RECEIVE = FALSE, otherwise receipt
an unlabelled datagram results in an error response
k. PORT-BSO-REQUIRED-RECEIVE: This parameter is a boolean
indicates whether all datagrams received via this network
must contain a Basic Security Option
l. PORT-BSO-REQUIRED-TRANSMIT: This parameter is a
which indicates whether all datagrams transmitted via
network port must contain a Basic Security Option. If
parameter is set to FALSE, then PORT-BSO-REQUIRED-RECEIVE
also be set to FALSE (to avoid communication failures
from asymmetric labelling constraints).
In every intermediate or end system, the following relationship
hold for these parameters for all network interfaces. The
">=" is interpreted relative to the linear ordering defined
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-
SYSTEM-AUTHORITY-IN >= PORT-AUTHORITY-
SYSTEM-AUTHORITY-OUT >= PORT-AUTHORITY-
2.6. Configuration
Systems which do not maintain separation for different
classification levels of data should have only trivial ranges for
LEVEL parameters, i.e., SYSTEM-LEVEL-MAX = PORT-LEVEL-MAX = PORT
LEVEL-MIN = SYSTEM-LEVEL-MIN
Systems which do maintain separation for different
classification levels of data may have non-trivial ranges for
LEVEL parameters, e.g., SYSTEM-LEVEL-MAX >= PORT-LEVEL-MAX >= PORT
LEVEL-MIN >= SYSTEM-LEVEL-MIN
2.7. Processing the Basic Security
For systems implementing the Basic Security Option, the
PORT-BSO-REQUIRED-TRANSMIT and PORT-BSO-REQUIRED-RECEIVE are used
specify the local security policy with regard to requiring
presence of this option on transmitted and received datagrams
respectively, on a per-port basis. Each datagram transmitted
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
configured to generate the BSO on transmitted datagrams.
systems also may or may not require a BSO to be present on
datagrams. However, all systems must be capable of
datagrams containing this option, irrespective of whether the
is processed or not
In general, systems which process classified data must generate
option for transmitted datagrams. The only exception to this
arises in (dedicated or system high [DoD 5200.28]) networks
traffic may be implicitly labelled rather than requiring
attached system to generate explicit labels. If the local
policy permits receipt of datagrams without the option, each
datagram is presumed to be implicitly labelled based on the port
which the datagram is received. A per-port parameter (PORT
IMPLICIT-LABEL) specifies the label to be associated with
datagrams upon receipt. Note that a datagram transmitted in
to receipt of an implicitly labelled datagram, may, based on
policy, require an explicit Basic Security Option
2.7.1. Handling Unclassified
If an unmarked datagram is received via a network port for
PORT-BSO-REQUIRED = FALSE and PORT-IMPLICIT-LABEL = UNCLASSIFIED (
FLAGS), the datagram shall be processed as though no
Authority Flags were set. Thus there are two distinct,
representations for Unclassified datagrams to which no
Authority rules apply (an unmarked datagram as described here and
datagram containing an explicit BSO with Classification Level set
Unclassified and with no Protection Authority flags set). Note
a datagram also may contain a Basic Security Option in which
Classification Level is Unclassified and one or more
Authority Field Flags are set. Such datagrams are
distinct from the equivalence class noted above (datagrams
Unclassified with no Protection Authority field flags set
datagrams not containing a Basic Security Option).
2.7.2. Input
Upon receipt of any datagram a system compliant with this RFC
perform the following actions. First, if PORT-BSO-REQUIRED-RECEIVE =
TRUE for this port, then any received datagram must contain a
Security Option and a missing BSO results in an ICMP error
as specified in Section 2.8.1. A received datagram which contains
Basic Security Option must be processed as described below.
Kent [Page 10]
RFC 1108 U.S. DOD Security Option November 1991
algorithm assumes that the IP header checksum has already
verified and that, in the course of processing IP options,
option has been encountered. The value of the Classification
field from the option will be designated "DG-LEVEL" and the value
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
1. If this test fails execute the out-of-range procedure
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
fails, execute out-of-range procedure specified in
2.8.2.
2.7.3. Output
Any system which implements the Basic Security Option must adhere
a fundamental rule with regard to transmission of datagrams, i.e.,
datagram shall be transmitted with a Basic Security Option the
of which is outside of the range for which the system is configured
Thus for every datagram transmitted by a system the following
hold: PORT-LEVEL-MAX >= DG-LEVEL >= PORT-LEVEL-MIN and DG-
=< PORT-AUTHORITY-OUT. It is a local matter as to what
are followed by a system which detects at attempt to transmit
datagram for which these relationships do not hold
If a port is configured to allow both labelled and
datagrams (PORT-BSO-REQUIRED-TRANSMIT = FALSE) to be transmitted,
question arises as to whether a label should be affixed.
recognition of the lack of widespread implementation or use of
option, especially in unclassified networks, this RFC recommends
the default be transmission of unlabelled datagrams. If
destination requires all datagrams to be labelled on input, then
will respond with an ICMP error message (see Section 2.8.1) and
originator can respond by labelling successive packets transmitted
this destination
To support this mode of operation, a system which allows
of both labelled and unlabelled datagrams must maintain
information (a cache) so that the system can associate the use
labels with specific destinations, e.g., in response to receipt of
ICMP error message as specified in Section 2.8.1. This
for maintaining a per-destination cache is very much analogous
Kent [Page 11]
RFC 1108 U.S. DOD Security Option November 1991
that imposed for processing the IP source route option or
maintaining first hop routing information (RFC 1122). This RFC
not specify which protocol module must maintain the per-
cache (e.g., IP vs. TCP or UDP) but security engineering
may dictate an IP implementation in trusted systems. This RFC
does not specify a cache maintenance algorithm, though use of a
and activity flag may be appropriate
2.8. Error
Datagrams received with errors in the Basic Security Option or
are out of range for the network port via which they are received
should not be delivered to user processes. Local policy will
whether logging and/or notification of a system security officer
required in response to receipt of such datagrams. The following
the least restrictive actions permitted by this protocol.
end or intermediate systems, system administrators, or
authorities may impose more stringent restrictions on responses
in some instances may not permit any response at all to a
which is outside the security range of a host or system
In all cases, if the error is triggered by receipt of an ICMP,
ICMP is discarded and no response is permitted (consistent
general ICMP processing rules).
2.8.1.Parameter Problem
If a datagram is received with no Basic Security Option and
system security configuration parameters require the option on
network port via which the datagram was received, an ICMP
Problem Missing Option (Type = 12, Code = 1) message is
in response. The Pointer field of the ICMP should be set to
value "130" to indicate the type of option missing. A Basic
Option is included in the response datagram with Clearance Level
to PORT-LEVEL-MIN and Protection Authority Flags set to PORT
AUTHORITY-ERROR
If a datagram is received in which the Basic Security Option
malformed (e.g., an invalid Classification Level Protection
Flag field), an ICMP Parameter Problem (Type = 12, Code = 0)
is transmitted in response. The pointer field is set to
malformed Basic Security Option. The Basic Security Option
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
If a datagram is received which is out of range for the network
on which it was received, an ICMP Destination
Communication Administratively Prohibited (Type = 3, Code = 9 for
or Code = 10 for host) message is transmitted in response. A
Security Option is included in the response datagram with
Level set to PORT-LEVEL-MIN and Protection Authority Flags set
PORT-AUTHORITY-ERROR
2.9. Trusted Intermediary
Certain devices in an internet may act as intermediaries to
that communications between two hosts are authorized. This
is based on the knowledge of the accredited security levels of
hosts and the values in the DoD Basic Security Option. These
may receive IP datagrams which are in range for the
device, but are not within the accredited range either for the
or for the destination. In the former case, the datagram should
treated as described above for an out-of-range option. In the
case, an ICMP Destination Unreachable Communication
Prohibited (Type = 3, Code = 9 for net or Code = 10 for host
response should be transmitted. The security range of the
interface on which the reply will be sent determines whether a
is allowed and at what level it will be sent
3. DoD Extended Security
This option permits additional security labelling information,
that present in the Basic Security Option, to be supplied in an
datagram to meet the needs of registered authorities. Note
information which is not labelling data or which is meaningful
to the end systems (not intermediate systems) is not appropriate
transmission in the IP layer and thus should not be transported
this option. This option must be copied on fragmentation.
the Basic Option, this option may appear multiple times within
datagram, subject to overall IP header size constraints
This option may be present only in conjunction with the
Security Option, thus all systems which support Extended
Options must also support the Basic Security Option. However,
all systems which support the Basic Security Option need to
Extended Security Options and support for these options may
selective, i.e., a system need not support all Extended
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
SECURITY INFO
FORMAT CODE
FIGURE 3. DoD EXTENDED SECURITY OPTION
3.1.
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
Length: 1
The value of the Additional Security Info Format Code identifies
syntax and semantics for a specific "Additional Security Information
field. For each Additional Security Info Format Code, an RFC will
published to specify the syntax and to provide an
description of the processing required to determine whether
datagram carrying a label specified by this Format Code should
accepted or rejected. This specification must be
detailed to permit vendors to produce interoperable implementations
e.g., it should be comparable to the specification of the
Security Option provided in this RFC. However, the
need not include a mapping from the syntax of the option to
labels if such mapping would cause distribution of the
to be restricted
In order to maintain the architectural consistency of DoD common
data networks, and to maximize interoperability, each activity
submit its plans for the definition and use of an Additional
Info Format Code to DISA DISDB, Washington, D.C. 20305-2000
review and approval. DISA DISDB will forward plans to the
Activities Board for architectural review and, if required, a
committee formed by the IAB will be constituted for the
process. Once approved, the Internet Assigned Number authority
assign an Additional Security Info Format Code to the
activity, concurrent with publication of the corresponding RFC
Note: The bit assignments for the Protection Authority flags of
Kent [Page 14]
RFC 1108 U.S. DOD Security Option November 1991
Basic Security Option have no relationship to the "
Security Info Format Code" of this option
3.4. Additional Security Information
Length:
The Additional Security Info field contains the additional
labelling information specified by the "Additional Security
Format Code" of the Extended Security Option. The syntax
processing requirements for this field are specified by
associated RFC as noted above. The minimum length of this field
zero
3.5. System Security Configuration
Use of the Extended Security Option requires that the intermediate
end system configuration accurately reflect the security
associated with communication via each network port (see Section 2.5
as a guide). Internal representation of the security
implementation dependent. The set of parameters required to
processing of the Extended Security Option is a function of the
of Additional Security Info Format Codes supported by the system
The RFC which specifies syntax and processing rules for a
Additional Security Info Format Code will specify the
system security parameters required for processing an
Security Option relative to that Code
3.6. Processing
Any datagram containing an Extended Security Option must also
a Basic Security Option and receipt of a datagram containing
former absent the latter constitutes an error. If the
specified by the Length field is inconsistent with the
specified by the variable length encoding for the Additional
Info field, the datagram is in error. If the datagram is received
which the Additional Security Info Format Code contains a non
registered value, the datagram is in error. Finally, if
Additional Security Info field contains data inconsistent with
defining RFC for the Additional Security Info Format Code,
datagram is in error. In any of these cases, an ICMP
Problem response should be sent as per Section 2.8.1. Any
error processing rules will be specified in the defining RFC for
Additional Security Info Format Code
If the additional security information contained in the
Security Option indicates that the datagram is within range
to the security policy of the system, then the datagram should
Kent [Page 15]
RFC 1108 U.S. DOD Security Option November 1991
accepted for further processing. Otherwise, the datagram should
rejected and the procedure specified in Section 2.8.2 should
followed (with the Extended Security Option values set apropos
Additional Security Info Format Code port security parameters).
As with the Basic Security Option, it will not be possible in
general internet environment for intermediate systems to
routing control for datagrams based on the labels contained in
Extended Security Option until such time as interior and
gateway routing protocols are enhanced to process such labels
[DoD 5200.28] Department of Defense Directive 5200.28, "
Requirements for Automated Information Systems," 21
March 1988.
Security
The focus of this RFC is the definition of formats and
conventions to support security labels for data contained in
datagrams, thus a variety of security issues must be
carefully when making use of these options. It is not possible
address all of the security considerations which affect
implementation and use of these options, however the
paragraph highglights some of these issues
Correct implementation and operation of the software and
which processes these options is essential to their effective use
Means for achieving confidence in such correct implementation
operation are outside of the scope of this RFC. The
themselves incorporate no facilities to ensure the integrity of
security labels in transit (other than the IP checksum mechanism),
thus appropriate technology must be employed whenever
containing these options transit "hostile"
environments. Careful, secure management of the
variables associated with each system making use of these options
essential if the options are to provide the intended
functionality
Kent [Page 16]
RFC 1108 U.S. DOD Security Option November 1991
Author's
Stephen
BBN
150 CambridgePark
Cambridge, MA 02140
Phone: (617) 873-3988
Email: kent@bbn.
Kent [Page 17]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
