tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6274

 
 
 

Security Assessment of the Internet Protocol Version 4

Part 3 of 5, p. 30 to 47
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 30 
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.

Top      Up      ToC       Page 31 
   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:

Top      Up      ToC       Page 32 
   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.

Top      Up      ToC       Page 33 
   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.

Top      Up      ToC       Page 34 
   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.

Top      Up      ToC       Page 35 
   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.

Top      Up      ToC       Page 36 
   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.

Top      Up      ToC       Page 37 
      [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.

Top      Up      ToC       Page 38 
   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.

Top      Up      ToC       Page 39 
   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:

Top      Up      ToC       Page 40 
                           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:

Top      Up      ToC       Page 41 
   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

Top      Up      ToC       Page 42 
   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:

Top      Up      ToC       Page 43 
                           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:

Top      Up      ToC       Page 44 
                               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.

Top      Up      ToC       Page 45 
   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).

Top      Up      ToC       Page 46 
   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).

Top      Up      ToC       Page 47 
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 RFC Part