RFC 6274
Security Assessment of the Internet Protocol Version 4
3.13. Options
According to RFC 791, IP options must be implemented by all IP modules, both in hosts and gateways (i.e., end-systems and intermediate-systems). This means that the general rules for assembling, parsing, and processing of IP options must be implemented. RFC 791 defines a set of options that "must be understood", but this set has been updated by RFC 1122 [RFC1122], RFC 1812 [RFC1812], and other documents. Section 3.13.2 of this document describes for each option type the current understanding of the implementation requirements. IP systems are required to ignore options they do not implement. It should be noted that while a number of IP options have been specified, they are generally only used for troubleshooting purposes (except for the Router Alert option and the different Security options). There are two cases for the format of an option: o Case 1: A single byte of option-type. o Case 2: An option-type byte, an option-length byte, and the actual option-data bytes. In Case 2, the option-length byte counts the option-type byte and the option-length byte, as well as the actual option-data bytes. All current and future options except End of Option List (Type = 0) and No Operation (Type = 1), are of Class 2. The option-type has three fields: o 1 bit: copied flag.
o 2 bits: option class. o 5 bits: option number. This format allows for the creation of new options for the extension of the Internet Protocol (IP) and their transparent treatment on intermediate-systems that do not "understand" them, under direction of the first three functional parts. The copied flag indicates whether this option should be copied to all fragments in the event the packet carrying it needs to be fragmented: o 0 = not copied. o 1 = copied. The values for the option class are: o 0 = control. o 1 = reserved for future use. o 2 = debugging and measurement. o 3 = reserved for future use. Finally, the option number identifies the syntax of the rest of the option. [IANA_IP_PARAM] contains the list of the currently assigned IP option numbers. It should be noted that IP systems are required to ignore those options they do not implement.3.13.1. General Issues with IP Options
The following subsections discuss security issues that apply to all IP options. The proposed checks should be performed in addition to any option-specific checks proposed in the next sections.3.13.1.1. Processing Requirements
Router manufacturers tend to do IP option processing on the main processor, rather than on line cards. Unless special care is taken, this represents DoS risk, as there is potential for overwhelming the router with option processing. To reduce the impact of these packets on the system performance, a few countermeasures could be implemented:
o Rate-limit the number of packets with IP options that are
processed by the system.
o Enforce a limit on the maximum number of options to be accepted on
a given Internet datagram.
The first check avoids a flow of packets with IP options to overwhelm
the system in question. The second check avoids packets with many IP
options to affect the performance of the system.
3.13.1.2. Processing of the Options by the Upper-Layer Protocol
Section 3.2.1.8 of RFC 1122 [RFC1122] states that all the IP options
received in IP datagrams must be passed to the transport layer (or to
ICMP processing when the datagram is an ICMP message). Therefore,
care in option processing must be taken not only at the Internet
layer but also in every protocol module that may end up processing
the options included in an IP datagram.
3.13.1.3. General Sanity Checks on IP Options
There are a number of sanity checks that should be performed on IP
options before further option processing is done. They help prevent
a number of potential security problems, including buffer overflows.
When these checks fail, the packet carrying the option should be
dropped, and this event should be logged (e.g., a counter could be
incremented to reflect the packet drop).
RFC 1122 [RFC1122] recommends to send an ICMP "Parameter Problem"
message to the originating system when a packet is dropped because of
an invalid value in a field, such as the cases discussed in the
following subsections. Sending such a message might help in
debugging some network problems. However, it would also alert
attackers about the system that is dropping packets because of the
invalid values in the protocol fields.
We advice that systems default to sending an ICMP "Parameter Problem"
error message when a packet is dropped because of an invalid value in
a protocol field (e.g., as a result of dropping a packet due to the
sanity checks described in this section). However, we recommend that
systems provide a system-wide toggle that allows an administrator to
override the default behavior so that packets can be silently dropped
when an invalid value in a protocol field is encountered.
Option length
Section 3.2.1.8 of RFC 1122 explicitly states that the IP layer
must not crash as the result of an option length that is outside
the possible range, and mentions that erroneous option lengths
have been observed to put some IP implementations into infinite
loops.
For options that belong to the "Case 2" described in the previous
section, the following check should be performed:
option-length >= 2
The value "2" accounts for the option-type byte and the option-
length byte.
This check prevents, among other things, loops in option
processing that may arise from incorrect option lengths.
Additionally, while the option-length byte of IP options of
"Case 2" allows for an option length of up to 255 bytes, there is
a limit on legitimate option length imposed by the space available
for options in the IP header.
For all options of "Case 2", the following check should be
enforced:
option-offset + option-length <= IHL * 4
Where option-offset is the offset of the first byte of the option
within the IP header, with the first byte of the IP header being
assigned an offset of 0.
This check assures that the option does not claim to extend beyond
the IP header. If the packet does not pass this check, it should
be dropped, and this event should be logged (e.g., a counter could
be incremented to reflect the packet drop).
The aforementioned check is meant to detect forged option-length
values that might make an option overlap with the IP payload.
This would be particularly dangerous for those IP options that
request the processing systems to write information into the
option-data area (such as the Record Route option), as it would
allow the generation of overflows.
Data types
Many IP options use pointer and length fields. Care must be taken
as to the data type used for these fields in the implementation.
For example, if an 8-bit signed data type were used to hold an
8-bit pointer, then, pointer values larger than 128 might
mistakenly be interpreted as negative numbers, and thus might lead
to unpredictable results.
3.13.2. Issues with Specific Options
3.13.2.1. End of Option List (Type=0)
This option is used to indicate the "end of options" in those cases
in which the end of options would not coincide with the end of the
Internet Protocol header. Octets in the IP header following the "End
of Option List" are to be regarded as padding (they should set to 0
by the originator and must to be ignored by receiving nodes).
However, an originating node could alternatively fill the remaining
space in the Internet header with No Operation options (see
Section 3.13.2.2). The End of Option List option allows slightly
more efficient parsing on receiving nodes and should be preferred by
packet originators. All IP systems are required to understand both
encodings.
3.13.2.2. No Operation (Type=1)
The No Operation option is basically meant to allow the sending
system to align subsequent options in, for example, 32-bit
boundaries, but it can also be used at the end of the options (see
Section 3.13.2.1).
With a single exception (see Section 3.13.2.13), this option is the
only IP option defined so far that can occur in multiple instances in
a single IP packet.
This option does not have security implications.
3.13.2.3. Loose Source and Record Route (LSRR) (Type=131)
This option lets the originating system specify a number of
intermediate-systems a packet must pass through to get to the
destination host. Additionally, the route followed by the packet is
recorded in the option. The receiving host (end-system) must use the
reverse of the path contained in the received LSRR option.
The LSSR option can be of help in debugging some network problems.
Some ISP (Internet Service Provider) peering agreements require
support for this option in the routers within the peer of the ISP.
The LSRR option has well-known security implications. Among other
things, the option can be used to:
o Bypass firewall rules
o Reach otherwise unreachable Internet systems
o Establish TCP connections in a stealthy way
o Learn about the topology of a network
o Perform bandwidth-exhaustion attacks
Of these attack vectors, the one that has probably received the least
attention is the use of the LSRR option to perform bandwidth
exhaustion attacks. The LSRR option can be used as an amplification
method for performing bandwidth-exhaustion attacks, as an attacker
could make a packet bounce multiple times between a number of systems
by carefully crafting an LSRR option.
This is the IPv4-version of the IPv6 amplification attack that was
widely publicized in 2007 [Biondi2007]. The only difference is
that the maximum length of the IPv4 header (and hence the LSRR
option) limits the amplification factor when compared to the IPv6
counterpart.
While the LSSR option may be of help in debugging some network
problems, its security implications outweigh any legitimate use.
All systems should, by default, drop IP packets that contain an LSRR
option, and should log this event (e.g., a counter could be
incremented to reflect the packet drop). However, they should
provide a system-wide toggle to enable support for this option for
those scenarios in which this option is required. Such system-wide
toggle should default to "off" (or "disable").
[OpenBSD1998] is a security advisory about an improper
implementation of such a system-wide toggle in 4.4BSD kernels.
Section 3.3.5 of RFC 1122 [RFC1122] states that a host may be able to
act as an intermediate hop in a source route, forwarding a source-
routed datagram to the next specified hop. We strongly discourage
host software from forwarding source-routed datagrams.
If processing of source-routed datagrams is explicitly enabled in a system, the following sanity checks should be performed. RFC 791 states that this option should appear, at most, once in a given packet. Thus, if a packet contains more than one LSRR option, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop). Additionally, packets containing a combination of LSRR and SSRR options should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop). As all other IP options of "Case 2", the LSSR contains a Length field that indicates the length of the option. Given the format of the option, the Length field should be checked to have a minimum value of three and be 3 (3 + n*4): LSRR.Length % 4 == 3 && LSRR.Length != 0 If the packet does not pass this check, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop). The Pointer is relative to this option. Thus, the minimum legal value is 4. Therefore, the following check should be performed. LSRR.Pointer >= 4 If the packet does not pass this check, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop). Additionally, the Pointer field should be a multiple of 4. Consequently, the following check should be performed: LSRR.Pointer % 4 == 0 If a packet does not pass this check, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop). When a system receives an IP packet with the LSRR option passing the above checks, it should check whether or not the source route is empty. The option is empty if: LSRR.Pointer > LSRR.Length In that case, routing should be based on the Destination Address field, and no further processing should be done on the LSRR option.
[Microsoft1999] is a security advisory about a vulnerability
arising from improper validation of the LSRR.Pointer field.
If the address in the Destination Address field has been reached, and
the option is not empty, the next address in the source route
replaces the address in the Destination Address field, and the IP
address of the interface that will be used to forward this datagram
is recorded in its place in the LSRR.Data field. Then, the
LSRR.Pointer. is incremented by 4.
Note that the sanity checks for the LSRR.Length and the
LSRR.Pointer fields described above ensure that if the option is
not empty, there will be (4*n) octets in the option. That is,
there will be at least one IP address to read and enough room to
record the IP address of the interface that will be used to
forward this datagram.
The LSRR must be copied on fragmentation. This means that if a
packet that carries the LSRR is fragmented, each of the fragments
will have to go through the list of systems specified in the LSRR
option.
3.13.2.4. Strict Source and Record Route (SSRR) (Type=137)
This option allows the originating system to specify a number of
intermediate-systems a packet must pass through to get to the
destination host. Additionally, the route followed by the packet is
recorded in the option, and the destination host (end-system) must
use the reverse of the path contained in the received SSRR option.
This option is similar to the Loose Source and Record Route (LSRR)
option, with the only difference that in the case of SSRR, the route
specified in the option is the exact route the packet must take
(i.e., no other intervening routers are allowed to be in the route).
The SSSR option can be of help in debugging some network problems.
Some ISP (Internet Service Provider) peering agreements require
support for this option in the routers within the peer of the ISP.
The SSRR option has the same security implications as the LSRR
option. Please refer to Section 3.13.2.3 for a discussion of such
security implications.
As with the LSRR, while the SSSR option may be of help in debugging
some network problems, its security implications outweigh any
legitimate use of it.
All systems should, by default, drop IP packets that contain an SSRR
option, and should log this event (e.g., a counter could be
incremented to reflect the packet drop). However, they should
provide a system-wide toggle to enable support for this option for
those scenarios in which this option is required. Such system-wide
toggle should default to "off" (or "disable").
[OpenBSD1998] is a security advisory about an improper
implementation of such a system-wide toggle in 4.4BSD kernels.
In the event processing of the SSRR option were explicitly enabled,
the same sanity checks described for the LSRR option in
Section 3.13.2.3 should be performed on the SSRR option. Namely,
sanity checks should be performed on the option length (SSRR.Length)
and the pointer field (SSRR.Pointer).
If the packet passes the aforementioned sanity checks, the receiving
system should determine whether the Destination Address of the packet
corresponds to one of its IP addresses. If does not, it should be
dropped, and this event should be logged (e.g., a counter could be
incremented to reflect the packet drop).
Contrary to the IP Loose Source and Record Route (LSRR) option,
the SSRR option does not allow in the route other routers than
those contained in the option. If the system implements the weak
end-system model, it is allowed for the system to receive a packet
destined to any of its IP addresses, on any of its interfaces. If
the system implements the strong end-system model, a packet
destined to it can be received only on the interface that
corresponds to the IP address contained in the Destination Address
field [RFC1122].
If the packet passes this check, the receiving system should
determine whether the source route is empty or not. The option is
empty if:
SSRR.Pointer > SSRR.Length
In that case, if the address in the destination field has not been
reached, the packet should be dropped, and this event should be
logged (e.g., a counter could be incremented to reflect the packet
drop).
[Microsoft1999] is a security advisory about a vulnerability
arising from improper validation of the SSRR.Pointer field.
If the option is not empty, and the address in the Destination
Address field has been reached, the next address in the source route
replaces the address in the Destination Address field, and the IP
address of the interface that will be used to forward this datagram
is recorded in its place in the source route (SSRR.Data field).
Then, the SSRR.Pointer is incremented by 4.
Note that the sanity checks for the SSRR.Length and the
SSRR.Pointer fields described above ensure that if the option is
not empty, there will be (4*n) octets in the option. That is,
there will be at least one IP address to read, and enough room to
record the IP address of the interface that will be used to
forward this datagram.
The SSRR option must be copied on fragmentation. This means that if
a packet that carries the SSRR is fragmented, each of the fragments
will have to go through the list of systems specified in the SSRR
option.
3.13.2.5. Record Route (Type=7)
This option provides a means to record the route that a given packet
follows.
The option begins with an 8-bit option code, which is equal to 7.
The second byte is the option length, which includes the option-type
byte, the option-length byte, the pointer byte, and the actual
option-data. The third byte is a pointer into the route data,
indicating the first byte of the area in which to store the next
route data. The pointer is relative to the option start.
RFC 791 states that this option should appear, at most, once in a
given packet. Therefore, if a packet has more than one instance of
this option, it should be dropped, and this event should be logged
(e.g., a counter could be incremented to reflect the packet drop).
The same sanity checks performed for the Length field and the Pointer
field of the LSRR and the SSRR options should be performed on the
Length field (RR.Length) and the Pointer field (RR.Pointer) of the RR
option. As with the LSRR and SSRR options, if the packet does not
pass these checks it should be dropped, and this event should be
logged (e.g., a counter could be incremented to reflect the packet
drop).
When a system receives an IP packet with the Record Route option that
passes the above checks, it should check whether there is space in
the option to store route information. The option is full if:
RR.Pointer > RR.Length
If the option is full, the datagram should be forwarded without
further processing of this option.
If the option is not full (i.e., RR.Pointer <= RR.Length), the IP
address of the interface that will be used to forward this datagram
should be recorded into the area pointed to by the RR.Pointer, and
RR.Pointer should then incremented by 4.
This option is not copied on fragmentation, and thus appears in the
first fragment only. If a fragment other than the one with offset 0
contains the Record Route option, it should be dropped, and this
event should be logged (e.g., a counter could be incremented to
reflect the packet drop).
The Record Route option can be exploited to learn about the topology
of a network. However, the limited space in the IP header limits the
usefulness of this option for that purpose if the target network is
several hops away.
3.13.2.6. Stream Identifier (Type=136)
The Stream Identifier option originally provided a means for the
16-bit SATNET stream Identifier to be carried through networks that
did not support the stream concept.
However, as stated by Section 4.2.2.1 of RFC 1812 [RFC1812], this
option is obsolete. Therefore, it must be ignored by the processing
systems.
In the case of legacy systems still using this option, the length
field of the option should be checked to be 4. If the option does
not pass this check, it should be dropped, and this event should be
logged (e.g., a counter could be incremented to reflect the packet
drop).
RFC 791 states that this option appears at most once in a given
datagram. Therefore, if a packet contains more than one instance of
this option, it should be dropped, and this event should be logged
(e.g., a counter could be incremented to reflect the packet drop).
3.13.2.7. Internet Timestamp (Type=68)
This option provides a means for recording the time at which each
system processed this datagram. The timestamp option has a number of
security implications. Among them are the following:
o It allows an attacker to obtain the current time of the systems
that process the packet, which the attacker may find useful in a
number of scenarios.
o It may be used to map the network topology, in a similar way to
the IP Record Route option.
o It may be used to fingerprint the operating system in use by a
system processing the datagram.
o It may be used to fingerprint physical devices by analyzing the
clock skew.
Therefore, by default, the timestamp option should be ignored.
For those systems that have been explicitly configured to honor this
option, the rest of this subsection describes some sanity checks that
should be enforced on the option before further processing.
The option begins with an option-type byte, which must be equal to
68. The second byte is the option-length, which includes the option-
type byte, the option-length byte, the pointer, and the overflow/flag
byte. The minimum legal value for the option-length byte is 4, which
corresponds to an Internet Timestamp option that is empty (no space
to store timestamps). Therefore, upon receipt of a packet that
contains an Internet Timestamp option, the following check should be
performed:
IT.Length >= 4
If the packet does not pass this check, it should be dropped, and
this event should be logged (e.g., a counter could be incremented to
reflect the packet drop).
The Pointer is an index within this option, counting the option type
octet as octet #1. It points to the first byte of the area in which
the next timestamp data should be stored and thus, the minimum legal
value is 5. Since the only change of the Pointer allowed by RFC 791
is incrementing it by 4 or 8, the following checks should be
performed on the Internet Timestamp option, depending on the Flag
value (see below).
If IT.Flag is equal to 0, the following check should be performed:
IT.Pointer %4 == 1 && IT.Pointer != 1
If the packet does not pass this check, it should be dropped, and
this event should be logged (e.g., a counter could be incremented to
reflect the packet drop).
Otherwise, the following sanity check should be performed on the
option:
IT.Pointer % 8 == 5
If the packet does not pass this check, it should be dropped, and
this event should be logged (e.g., a counter could be incremented to
reflect the packet drop).
The flag field has three possible legal values:
o 0: Record time stamps only, stored in consecutive 32-bit words.
o 1: Record each timestamp preceded with the Internet address of the
registering entity.
o 3: The internet address fields of the option are pre-specified.
An IP module only registers its timestamp if it matches its own
address with the next specified Internet address.
Therefore the following check should be performed:
IT.Flag == 0 || IT.Flag == 1 || IT.Flag == 3
If the packet does not pass this check, it should be dropped, and
this event should be logged (e.g., a counter could be incremented to
reflect the packet drop).
The timestamp field is a right-justified 32-bit timestamp in
milliseconds since UTC. If the time is not available in
milliseconds, or cannot be provided with respect to UTC, then any
time may be inserted as a timestamp, provided the high-order bit of
the timestamp is set, to indicate this non-standard value.
According to RFC 791, the initial contents of the timestamp area must
be initialized to zero, or Internet address/zero pairs. However,
Internet systems should be able to handle non-zero values, possibly
discarding the offending datagram.
When an Internet system receives a packet with an Internet Timestamp
option, it decides whether it should record its timestamp in the
option. If it determines that it should, it should then determine
whether the timestamp data area is full, by means of the following
check:
IT.Pointer > IT.Length
If this condition is true, the timestamp data area is full. If not,
there is room in the timestamp data area.
If the timestamp data area is full, the overflow byte should be
incremented, and the packet should be forwarded without inserting the
timestamp. If the overflow byte itself overflows, the packet should
be dropped, and this event should be logged (e.g., a counter could be
incremented to reflect the packet drop).
If the timestamp data area is not full, then processing continues as
follows (note that the above checks on IT.Pointer ensure that there
is room for another entry in the option):
o If IT.Flag is 0, then the system's 32-bit timestamp is stored into
the area pointed to by the pointer byte and the pointer byte is
incremented by 4.
o If IT.Flag is 1, then the IP address of the system is stored into
the area pointed to by the pointer byte, followed by the 32-bit
system timestamp, and the pointer byte is incremented by 8.
o Otherwise (IT.Flag is 3), if the IP address in the first 4 bytes
pointed to by IT.Pointer matches one of the IP addresses assigned
to an interface of the system, then the system's timestamp is
stored into the area pointed to by IT.Pointer + 4, and the pointer
byte is incremented by 8.
[Kohno2005] describes a technique for fingerprinting devices by
measuring the clock skew. It exploits, among other things, the
timestamps that can be obtained by means of the ICMP timestamp
request messages [RFC0791]. However, the same fingerprinting method
could be implemented with the aid of the Internet Timestamp option.
3.13.2.8. Router Alert (Type=148)
The Router Alert option is defined in RFC 2113 [RFC2113] and later
updates to it have been clarified by RFC 5350 [RFC5350]. It contains
a 16-bit Value governed by an IANA registry (see [RFC5350]). The
Router Alert option has the semantic "routers should examine this
packet more closely, if they participate in the functionality denoted
by the Value of the option".
According to the syntax of the option as defined in RFC 2113, the
following check should be enforced, if the router supports this
option:
RA.Length == 4
If the packet does not pass this check, it should be dropped, and
this event should be logged (e.g., a counter could be incremented to
reflect the packet drop).
A packet that contains a Router Alert option with an option value
corresponding to functionality supported by an active module in the
router will not go through the router's fast-path but will be
processed in the slow path of the router, handing it over for closer
inspection to the modules that has registered the matching option
value. Therefore, this option may impact the performance of the
systems that handle the packet carrying it.
[ROUTER-ALERT] analyzes the security implications of the Router
Alert option, and identifies controlled environments in which the
Router Alert option can be used safely.
As explained in RFC 2113 [RFC2113], hosts should ignore this option.
3.13.2.9. Probe MTU (Type=11) (Obsolete)
This option was defined in RFC 1063 [RFC1063] and originally provided
a mechanism to discover the Path-MTU.
This option is obsolete, and therefore any packet that is received
containing this option should be dropped, and this event should be
logged (e.g., a counter could be incremented to reflect the packet
drop).
3.13.2.10. Reply MTU (Type=12) (Obsolete)
This option is defined in RFC 1063 [RFC1063], and originally provided
a mechanism to discover the Path-MTU.
This option is obsolete, and therefore any packet that is received
containing this option should be dropped, and this event should be
logged (e.g., a counter could be incremented to reflect the packet
drop).
3.13.2.11. Traceroute (Type=82)
This option is defined in RFC 1393 [RFC1393], and originally provided
a mechanism to trace the path to a host.
The Traceroute option was specified as "experimental", and it was never deployed on the public Internet. Therefore, any packet that is received containing this option should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).3.13.2.12. Department of Defense (DoD) Basic Security Option (Type=130)
This option is used by Multi-Level-Secure (MLS) end-systems and intermediate-systems in specific environments to [RFC1108]: o Transmit from source to destination in a network standard representation the common security labels required by computer security models, o Validate the datagram as appropriate for transmission from the source and delivery to the destination, and o Ensure that the route taken by the datagram is protected to the level required by all protection authorities indicated on the datagram. It is specified by RFC 1108 [RFC1108] (which obsoletes RFC 1038 [RFC1038]). RFC 791 [RFC0791] defined the "Security Option" (Type=130), which used the same option type as the DoD Basic Security option discussed in this section. The "Security Option" specified in RFC 791 is considered obsolete by Section 3.2.1.8 of RFC 1122, and therefore the discussion in this section is focused on the DoD Basic Security option specified by RFC 1108 [RFC1108]. Section 4.2.2.1 of RFC 1812 states that routers "SHOULD implement this option". The DoD Basic Security option is currently implemented in a number of operating systems (e.g., [IRIX2008], [SELinux2009], [Solaris2007], and [Cisco2008]), and deployed in a number of high-security networks. Systems that belong to networks in which this option is in use should process the DoD Basic Security option contained in each packet as specified in [RFC1108]. RFC 1108 states that the option should appear at most once in a datagram. Therefore, if more than one DoD Basic Security option (BSO) appears in a given datagram, the corresponding datagram should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
RFC 1108 states that the option Length is variable, with a minimum option Length of 3 bytes. Therefore, the following check should be performed: BSO.Length >= 3 If the packet does not pass this check, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop). Current deployments of the security options described in this section and the two subsequent sections have motivated the specification of a "Common Architecture Label IPv6 Security Option (CALIPSO)" for the IPv6 protocol [RFC5570].3.13.2.13. DoD Extended Security Option (Type=133)
This option permits additional security labeling information, beyond that present in the Basic Security option (Section 3.13.2.13), to be supplied in an IP datagram to meet the needs of registered authorities. It is specified by RFC 1108 [RFC1108]. This option may be present only in conjunction with the DoD Basic Security option. Therefore, if a packet contains a DoD Extended Security option (ESO), but does not contain a DoD Basic Security option, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop). It should be noted that, unlike the DoD Basic Security option, this option may appear multiple times in a single IP header. Systems that belong to networks in which this option is in use, should process the DoD Extended Security option contained in each packet as specified in RFC 1108 [RFC1108]. RFC 1108 states that the option Length is variable, with a minimum option Length of 3 bytes. Therefore, the following check should be performed: ESO.Length >= 3 If the packet does not pass this check, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
3.13.2.14. Commercial IP Security Option (CIPSO) (Type=134)
This option was proposed by the Trusted Systems Interoperability Group (TSIG), with the intent of meeting trusted networking requirements for the commercial trusted systems market place. It is specified in [CIPSO1992] and [FIPS1994]. The TSIG proposal was taken to the Commercial Internet Security Option (CIPSO) Working Group of the IETF [CIPSOWG1994], and an Internet-Draft was produced [CIPSO1992]. The Internet-Draft was never published as an RFC, but the proposal was later standardized by the U.S. National Institute of Standards and Technology (NIST) as "Federal Information Processing Standard Publication 188" [FIPS1994]. It is currently implemented in a number of operating systems (e.g., IRIX [IRIX2008], Security-Enhanced Linux [SELinux2009], and Solaris [Solaris2007]), and deployed in a number of high-security networks. [Zakrzewski2002] and [Haddad2004] provide an overview of a Linux implementation. Systems that belong to networks in which this option is in use should process the CIPSO option contained in each packet as specified in [CIPSO1992]. According to the option syntax specified in [CIPSO1992], the following validation check should be performed: CIPSO.Length >= 6 If a packet does not pass this check, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).3.13.2.15. Sender Directed Multi-Destination Delivery (Type=149)
This option is defined in RFC 1770 [RFC1770] and originally provided unreliable UDP delivery to a set of addresses included in the option. This option is obsolete. If a received packet contains this option, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
(next page on part 4)
